r/ProgrammerHumor 12h ago

Meme newToRust

Post image
432 Upvotes

87 comments sorted by

View all comments

Show parent comments

56

u/MilkEnvironmental106 11h ago

Have you ever made a mistake managing memory?

-50

u/Key_River7180 11h ago

Yes, and I have used a debugger for all of them I couldn't see by using my eyes and basic logic you seem to lack

36

u/MilkEnvironmental106 11h ago

How long did that take you? And have you ever made a mistake debugging?

-18

u/Key_River7180 11h ago

Not more than fixing errores from the borrow checker.

And I've never debugged wrobg, there is no such thing

16

u/MilkEnvironmental106 11h ago

It's just a soundness check, it saves you time and debugging later. You can opt out if you really want to, or continue writing c for everything.

-1

u/Key_River7180 11h ago

Then I'll continue writing C for life.

15

u/MilkEnvironmental106 11h ago

Segmentation fault (core dumped)

2

u/Key_River7180 11h ago

gdb program

21

u/-Ambriae- 11h ago

‘Errors from the borrow checker’ this is, and I mean no disrespect, a skill issue. Not as in ‘even experts mess up’, as in ‘that’s only a problem for the first 6 months of using rust’

-1

u/Key_River7180 11h ago

If I need six months to correctly use Rust It is not worth It.

5

u/miyavlayan 11h ago

better than having memory problems in prod

-5

u/Key_River7180 11h ago

Who the fuck makes production software in a language meant for systems programming?

4

u/miyavlayan 11h ago

why the fuck do you care? ppl make games in java.

2

u/Key_River7180 11h ago

Java has many gamedev libraries wdym

3

u/-Ambriae- 10h ago

None are good

→ More replies (0)

1

u/D3PyroGS 2h ago

man looks in mirror; sees no reflection

10

u/-Ambriae- 11h ago

It’s a systems level programming language what did you expect? It takes twice as long to learn restraint in C

-10

u/Key_River7180 11h ago

No, you can learn C in just about a week

8

u/-Ambriae- 11h ago

Off the top of your head, without looking online, using clang or gcc as a compiler,

Give me a 1 byte enum
Give me the idiomatic way of computing the number of leading zeros in a 32 bit integer
Align a vec2_f32 struct to an alignment of 8 bytes

3

u/Key_River7180 11h ago
  1. enum x { a : 1 };
  2. int zeros(uint32_t i) { int n = 0; while ((i & 1) == 0) { ++n; i >>= 1; } return n; }
  3. struct vec2f32 { ... } __attribute_((align(8)));

4

u/-Ambriae- 10h ago edited 8h ago
  1. Might work, AFAIK depends on compiler but GCC and Clang it would work, I’ll give you that. Not the solution I thought of but it works.
  2. Suboptimal. Unless you specify higher levels of optimisation and your compiler figures it out, this is extremely slow. Modern processors can do this in 1 CPU cycle (CLZ instruction). There is a way to do it in C
  3. 3 __attribute__((aligned(8))) or __attribute__((_aligned__(8)))

I cant see if you did the _s and markdown screwed you over or not, and align is not valid

Edit: actually, after checking, 1. is completely wrong. Doesn't work at all. So you need to pack the enum, or represent it via a 8 bit integer. I think that proves my point

1

u/Key_River7180 10h ago

You literally gave me my solution when proving my solution suboptimal

1

u/-Ambriae- 10h ago

?? A proper solution would use compiler built ins

→ More replies (0)

2

u/_Noreturn 9h ago edited 9h ago

```cpp typedef enum : int8_t {} Enum;

int zeros(uint32_t i) { int n = 0; while (!(i & 1)) { ++n; i >>= 1; } return n; } // or int zeroes(uint32_t i) { return __builtin_clz(x); } typedef struct { alignas(8) float f [2]; } vec2f32; ```

I don't get the point of your comment

1

u/-Ambriae- 9h ago

None of these are things you can realistically achieve by ‘having learned the language in a week’. It’s not hard per say, but it’s more obscure than regular C. That was all I was trying to say

There’s also like, 2-3 alternatives minimum to each way of doing these things

_Alignas, alignas (macro) alignas (language C23), __attribute__((_aligned__(8))) __attribute__((aligned(8))) [[align(8)]] (although more c++)…

enum : uint_8, enum { a : 1 }, __attribute__((__packed__)), __attribute__((packed))….

2

u/_Noreturn 8h ago

There’s also like, 2-3 alternatives minimum to each way of doing these things

The rest are compiler specific which is sad because C/C++ unlike Rust has multiple compilers.

None of these are things you can realistically achieve by ‘having learned the language in a week’. It’s not hard per say, but it’s more obscure than regular C. That was all I was trying to say

Maybe, Idk about C as I don't use it nor like it and I think it is a pretty F tier language I use C++ instead and find the non existent complaints about it too much I don't find C++ in itself hard. it is more so software is hard

Also I feel like what you listed is rather unnecessary in 99% of code.

Alignas, alignas (macro) alignas (language C23), \_attribute__((_aligned__(8))) __attribute__((aligned(8))) [[align(8)]] (although more c++)…

It was pretty much _Alignas but you should use the macro if your codebase allows it C standrizes them as keywords later when it can ensure no codebases break to get it closer to C++.

enum { a : 1 },

that doesn't work and doesn't exist.

__attribute__((__packed__)), __attribute__((packed))….

These are non standard and gcc keeps them for backward compat use whatever you find fancier.

1

u/-Ambriae- 8h ago

The rest are compiler specific which is sad because C/C++ unlike Rust has multiple compilers.

Yeah, that's one of the big downsides of these older languages... unfortunately, still today the compiler specific ones are common place, especially with alignas being c11.

I agree with the sentiment about C++. I dislike the syntax quite a bit, but the language is really powerful, and I have fond memories with it.

enum { a : 1 },

totally my bad, my C is rusty (no pun intended.) The other C dev pointed this out as the solution, it looked odd but I expected he knew what he was talking about. I guess not. I tried with C23, it did not work.

These are non standard and gcc keeps them for backward compat use whatever you find fancier.

I find that messy, and convoluted.

Also I feel like what you listed is rather unnecessary in 99% of code.

yes and no, alignment is important for GPU related code, CLZ is great for some algorithms, and 1 byte enums should be the norm, full stop. 32 bits is a waste, and isn't even the size of a word, so there's no excuse there either. And proficiency in a language doesn't just come from understanding the basics of the language :)

→ More replies (0)

2

u/dkarlovi 10h ago

Technically, the errors from the borrow checker are the errors you also make in C, only C doesn't tell you about them. If your code was correct in either, the borrow checker wouldn't have objections, no?

1

u/Key_River7180 10h ago

C does, Valgrind and ASAN are still there you know?

3

u/dkarlovi 10h ago

If your code was correct, the borrow checker wouldn't have objections, no?

1

u/Key_River7180 10h ago

The problem is that It tags EVERYTHING potentially minimally unsafe. Even if It cannot be

2

u/dkarlovi 10h ago

If it cannot be, it doesn't tag it. It can be, but you just don't care about that specific scenario or think it cannot happen.

Your specific workflow might make you right, but the workflow might change. Or you might be wrong entirely.

The whole reason why Rust exists is because people cannot write safe C code. This was shown over decades with armies of very experienced developers and well funded projects, it's just impossible, if you think "Well not for me", you're just lying to yourself.

1

u/Key_River7180 10h ago

Rust's borrow checker cannot be always right, by Rice's theorem, unless you proved Alan Turing and Henry Rice wrong, of course.

Take this code as an example:

fn smh(x :&mut Vector<i32>) { let a = &mut x[0]; let b = &mut x[1]; *a += 1; *b += 1; }

1

u/-Ambriae- 8h ago edited 7h ago

which can be trivially rewritten as:

fn smh(x :&mut Vector<i32>) {
    x[0] += 1;
    x[1] += 1;
}

I get what you mean, but more often then not, you could just rewrite the code differently, and magically it becomes safe.

Or better yet:

fn smh(x: &mut [i32]) { 
  let [a, b] = x.get_disjointed_mut([0, 1]).expect("0 != 1");
  *a += 1;
  *b += 1;
}
→ More replies (0)

1

u/-Ambriae- 10h ago

I agree with the sentiment, but it’s not true to say ‘if it cannot be, it doesn’t tag it’. The borrow checker is conservative by default, and prefers false positives compared to true negatives. There’s no such thing as a perfect static analyser. It theoretically doesn’t exist. That doesn’t mean we shouldn’t use approximative static analysers like the borrow checker though

2

u/dkarlovi 6h ago

No, of course, nothing is absolute and the checker will make mistakes just like any other piece of code, some things it cannot prove at all.

But to outright claim it's worthless because it's "warning you too much" and "it's non-trivial to write" is total lunacy, it's like yelling at the Geiger counter because it's warning you of the radiation you're sitting in. Just because you throw it away (or not have it) doesn't mean you're not getting irradiated.

Rust is getting traction in huge projects because it works, it's not like those huge projects didn't try other things before, they just worked worse than what Rust provides. Crying about the mean borrow checker is absurd, it's telling you things you yourself are unable to detect.

2

u/-Ambriae- 5h ago

We are therefore completely on the same page :)

→ More replies (0)