lapisnev

Don't squeeze me, I fart

Things that make you go 🤌. Weird computer stuff. Artist and general creative type. Occasionally funny. Gentoo on main. I play rhythm games!

Inkscape Monofur font Cohost PLUS!

You can post SVG files like photos on this website! Spread the word!


SArpnt
@SArpnt

the kind of stuff people say praising rust feels very wrong, smug, and annoying and i don't want to agree with them but i've genuinely never seen an actual situation where something like c, c++, c#, go, or whatever other general purpose compiled language would do better than rust unless it's something about compatibility

any time i see anyone that doesn't like rust they either never actually explain why (maybe giving vague hints about the borrow checker or whatever) or demonstrate they just don't know how to write rust code (as in they tried and failed to do a bad thing, and the way they would do it in their other language isn't good either, probably for the same reason)

please tell me why rust bad go ahead i want good reasons

(also if you mention anything about the rust foundation or trademarks or whatever i don't care about them i'm talking about the actual language and tools)


MxSelfDestruct
@MxSelfDestruct
  • rust syntax is terrible to the point that it's genuinely painful to write. sorry!

  • stdlibs are heavily reliant on themselves - it's hard to only use some of it. C's standard library is a garbage fire but at least you can just pull the one melted hose you want out of the heap.

  • compiler is slow as shit, unreasonably strict, and generates enormous executables. stop bitching at me for my code not being "properly rusty" or whatever and give me fucking automatic type coercion.

  • the borrow checker is a really hamfisted approach to safety that's far more annoying than it's worth. sorry! I know what I'm doing, so kindly step the fuck off.

  • still surprisingly immature for being over 10 years old.

  • going back to the stdlib, Rust has built-in abstraction hell, nearly as bad as C++ but exacerbated by the fact that you need to use damn near all of it. the saving grace of the C++ stdlib is that you can just use some of it. Rust affords you no such luxury.

  • if you need advice on or help with something you will, at some point, need to interact with the Rust community.


You must log in to comment.

in reply to @SArpnt's post:

my only thought of it as someone who has not used rust ever and only used c as far as getting a small toy to compile is rust's syntax looks weird and full of bizarre shorthand that i don't see in other c-languages, so even starting to understand it requires unwinding the shit i learned in lua, php, pretty much everything

useful reply? no

As someone who uses boff C and Rust, there's two situations I prefer C:

  • if I am making a program in python or smthn and I need to make a helper library in a compiled language, it's always going to bee easier to do it in C than in Rust or most other languages, teh interop is simply more robust at this point.

  • If I am making a small utility program that I am going to call in like a bash script or smthn, then I am probably going to make it in C, cuz the rust compiler is way slower and is going to add 200 mb of cruft into my harddrive for little reason, hehe.

Now, if in any of these two situations I need to import a library in a way that is not trivial, I am pivoting away from C immediately, because dependency management in C is absolutely hell, hehe.

(there's a couple other situations when I use C over Rust, but it's mainly because I am in a C mood)

C is awful fur both strings and file handling but I can just deal, hehe. Pretty much I jusf got extremely good and efficient at writing LR parsers thaf it jusf became second nature, and at that algorithmic level teh high-level string functions aren'f really that useful

As fur PyO3, I should take a look, meowf. It would actually bee really useful rn since I am making a discord bot and as it grows more complex I definitely don't wanna make any more of it in neither C or python, hehe

Specialization and GATs can hopefully significantly improve this issue, but it will depend on how far they will go back and improve on already existing abstractions in the standard library.

For example, a lot of boiler plate has to be done currently to get around the fact that you can't have a Iterable trait in rust. A Vec cannot be iterated so you need to convert it into a Iterator via into_iter or whatever, and because that's not the vector itself, it incurs more boiler plate, etc... (e.g. you need to collect it at the end if you want to turn it back into a Vec)

That can be solved with GATs, which are "sorta stable". Other stuff can be solved with specialization. (which is still a bit early I think) Another pain point is how clumsy the match pattern is on non-primitive data-types (still can't match on Strings!!) which could be solved just by a whole whole bunch of syntax sugar but idk, maybe there's a more elegant solution.

But yeh, there's a lot of issues, which "are in the works", but you're right to be put off. Honestly my main one is that rust macros suck balls, hehe. I can't wait to not have to make a whole other crate and have to program whole parsers just to add a little macro in my program.

I'm not sure what the problem with iterators is, tbh...

Vec, for example, can't support next-like API, it just can't. You can't remove the first element from a vec, because it has no state to track that the first element is removed (moving all elements to beginning all the time is a bad solution) (it could support next_back tho, which is pop) (next can be supported with VecDeque but it's significantly more complex than Vec).

You could probably make an interface like Foldable, because then you can track everything and temporary break invariants in the fold function which you have control over. But that interface has its own problems (e.g. it's strict; you have problems with object safety; etc).

IMO iteration requires vastly different data, and this it's only reasonable that we have different types for iteration (which also allows laziness, adaptors, etc).

It's just annoying to use, and the ways it merges with the type system can quickly become unwieldy.

I am not saying to discard iterators themselves, just to increase the situations in which they are more seamless integrated with the language (like how they [mostly] are in for-loops)

less of this please:

let x = vec.into_iter().fold(func).collect::<Vec<_>>();

I get your annoyance, but I'm not sure there any good ways to fix this...

(btw, I'm assuming you've meant .map(func), fold().collect() doesn't make much sense...)

You could add stuff like Vec::map which returns Vec, and with GATs it's possible to make this into a trait, but... It's bad as the basic/"main" operation, it doesn't compose as well as the iterator version, .map().map() is more constly, etc. So I'm not sure if it's the best idea...

I could, however, see stuff like fold, for_each, etc being added to IntoIterator, so you don't have to add .into_iter() for them.

(then again, Vec::map could be more efficient than collecting when size_of::<U>() <= size_of::<T>(), so maybe your unto something....)

It's really just a case of keeping simple operations simple, if you need to chain iterator operations the protocol is warranted, but if you just want single operation it becomes a bit of a cognitive overload.

And yeah, you mentioned Fold and it tripped me up, hehe. As for map().map(), in that case you would compose the functions so u can merge the calls into one, meowf.

I feel like a IntoIterator type could have a method that just takes a list of operations and returns a collected structure of the same collection type. I wanna try experimenting with this, but I fear there's still a couple type system barriers to overcome.

In the cases where mapping can be done in-place I would assume it would be a lot more efficient too, hehe. (T = U)

i like rust a lot but theres definitely places where the borrow check is Not Good at modeling the ownership model. imo, no has a good UI library that is both fast to compile, reasonably good at nontrivial UI, and not an extremely complicated mess of traits. you only can get two of the three it seems. of the GUI libraries i tried (so far: iced, egui, vizia), none of them were able to do all three

abstractly, it would certainly be nice if it was easier to "know how to write rust code"; i agree that it almost always turns out that changing the approach is a good idea and produces better results when there is friction, but that friction is in and of itself a downside for as long as it lasts.

in reply to @MxSelfDestruct's post:

a lot of what you're saying is pretty vague, what makes the syntax bad? what do you mean by immature? what makes the borrow checker annoying? what is abstraction hell? doesn't c++ have a lot more syntax than rust? i'm not even sure what you're thinking of when you mean the rust community, i've only ever been in one unofficial matrix room and the people there seem fine, it's probably not whatever you're talking about.

i do really want to understand this kind of opinion, i just can't figure out what actual situations most of this happens, matters, and isn't the same as some other language.

which language are you even comparing to anyways? you've mentioned both c and c++ and although they're similar i don't think either one actually deals with all of these. from what i remember working on c++ it takes about the same amount of time to compile, and with how difficult it is to actually set up cmake or whatever it would probably be faster to configure cargo a bit to improve compile time or size or whatever it is for your project

what makes the syntax bad?

it feels like there's just a lot more of it than in C/C++, idk how to explain this better.

what do you mean by immature?

I mean that a lot of third-party stuff that should exist for Rust by now simply doesn't. as far as I'm aware, there are no good graphics libraries, save for a few wrappers for C/C++ based ones, there's only one Rust compiler, etc etc.

what makes the borrow checker annoying?

It makes things that should be simple incredibly frustrating. I understand why it's there, I can work with it - I would really prefer not to. I can manage my own memory.

what is abstraction hell?

in Rust's case, it looks like damn near everything being wrapped in a thousand different other things that you have to deal with or else the compiler yells at you.

doesn't C++ have a lot more syntax than Rust?

oh god absolutely, but you can avoid it.

i'm not even sure what you're thinking of when you mean the rust community

I mean the Rust community that says the kind of stuff you talk about in the first part of the OP, and spends seemingly all of its free time circlejerking about how great Rust is and how stupid everyone else is for ever using any other language. in my experience this is about 40% of the online Rust community.

fair enough on most of these things, i'm not sure i can agree with how important they all are but prodding into them would probably require a full essay and it feels like a dumb thing to complain about

the part about the borrow checker still bugs me though, not that it's wrong, but i don't actually see it get in the way of anything, i've only ever had it stop a compile if i do something stupid that wouldn't work well or wouldn't work at all anyways.

i think this page explains it a lot better than i can: https://rust-school.io/writing/overcoming-lifetimes/

about the syntax, i think what might make it seem like more is that you need to learn a lot more of it to start out, and that it looks at first like it has its own stuff in addition to c or c++ stuff, when a lot of the time things are replacements. the migration in general is a lot harder than other things that sound similar, like moving from c to c++ or from c++ to java or c# or things like that. i think to learn rust you'd need to actually set a good amount of time aside and get through the rust book or rustlings or whatever official full tutorial there is, and put up with a lot of it sounding obvious and boring for some time. you'd need to treat learning rust like learning haskell

I can manage my own memory.

Generations of buffer overflow attacks and memory leaks suggest a vast majority of people in fact cannot, to a degree that I am suspicious that anyone can, especially in 2023 when computers are so damn complicated. At the very least, it seems undeniably true that a lot of the people who say this certainly can't, but unfortunately that blindness is why they'll also never switch to a safer solution.