SArpnt

SArpnt

@SArpnt

trust me i do programming and music i just don't make great posts about it or complete most of it

log inask
git
git.disroot.org/sarpnt
bad git
github.com/sarpnt
botb
battleofthebits.com/barracks/Profile/SArpnt/
scratch
scratch.mit.edu/users/DerpyHead0/
fedi
fe.disroot.org/@SArpnt
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)

You must log in to comment.

in reply to @SArpnt's post:

xkeeper
@xkeeper

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

login to reply
phi
@phi

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)

login to reply
phi
@phi

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

login to reply
phi
@phi

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.

login to reply
wffl
@wffl

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).

login to reply
phi
@phi

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<_>>();
login to reply
wffl
@wffl

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....)

login to reply
phi
@phi

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)

login to reply
gnar
@gnar

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

login to reply
widr
@widr

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.

login to reply