From a language architecture standpoint and not an ecosystem standpoint, what might be some things where you’d really not want to use Rust, either because of some limitation that prevents it from doing it or just because it’d be massively annoying to write to the point of significantly reduced productivity? What about Rust makes it unsuitable, and what language paradigms are the best for it?
I hear a lot about how the things that Rust is not good for, JIT compilation with a garbage collector is usually the best solution, and vice versa. How true is this?
On the garbage collector point: I used to do java professionally, and it made me never want to use any garbage collected language ever again.
I have some nightmare stories… one giant monolithic program was so bad on memory, that after running for a few days, it would take up all the memory of a 24 GB machine, and one of our devs had to manually write a ton of code to garbage collect certain things just to keep the thing alive.
Even small programs in GC languages have that problem: they can never really be smart enough to know which data can be scrapped, and do the safest thing, which is to keep it all in memory. Even a simple java program I wrote a few years ago grows to fill up the memory of the 1gb box I have it on, after it runs for a few weeks.
Rust doesn’t have that problem, as it forces you to think about borrowing, stack and heap from the very beginning. When you realize its not that much more work to do so, you can see why go and java will never beat rust on memory performance.
Rust doesn’t have that problem
That’s a bit generalized you can leak memory in rust e.g. by keeping around old Weak pointers, also std::collections::* don’t shrink by themselves.
I feel like Rust isn’t good for anything that has unsafe in it, or anything that needs to call in C++ code (like the extended LLVM API).
Why is rust bad for unsafe? Isn’t that like a superpower to be able to “override” the borrow checker on a specific line instead of having a whole unsafe codebase?
Removed by mod
Yeah, GUIs in general are messy, almost by necessity. And Rust has a strong focus on correctness, which does not mesh well with messy.
As an example, it happens that you don’t yet have a certain value that’s supposed to be shown in the GUI, but it also doesn’t matter, because that GUI element isn’t actually visible yet.
In many typical frontend languages, you would set that tonulland be done with it. Rust doesn’t havenulland while you can make everything anOption-type, that’s relatively clunky, for how commonly you need such a workaround.Obviously, though, constantly throwing around
nullisn’t great either. The compiler cannot help you at all anymore.
So, I am still hoping that a new paradigm emerges out of all of this, which is better for GUIs in any language. Basically put more thought into actually resolving the issue, rather than standardizing on the dirtiest workaround.Removed by mod
Option is rust’s null. And matches are everywhere because of it.
And if let’s - so what?
C++ makes working with null pointers so beautiful.
How? You still have to check wether it’s NULL or not.
Businesses want reliable software
No they want quick turnaround, so they can make more profit. Thats the opposite of reliable software. Thats why most commercial software is such a buggy mess.
How? You still have to check wether it’s NULL or not.
I think that’s the parent’s point: in C/C++ you don’t have to deal with null. You can just pass it around and potentially start unintended/undefined behavior. While in Rust, it’s a compile-time error if you don’t unwrap the option somehow (eg.
if let Some(content) = optional_content).So yes it’s more concise and “beautiful”, but you’ll probably bite your own hand at some point playing this game
How is it more beautiful? You have to deal with null pointers when you want to use the pointer anyway, if you don’t you will get a runtime error, or worse, your program will keep running in an unintended state.
yes, that was exactly my point. You can just use a pointer without checking it, which is aesthetically more pleasing, but will produce garbage :)
Rust does not like undefined behavior.
Can you elaborate this? Is it like when your program wants an integer between 1 and 5 and it gets -420?
I’ve just finished watching some great talks on undefined behaviour in C/Cpp:
And Rust’s own list of undefined behaviour is here, almost entirely do to with humans using
unsafebut not taking the necessary care with it: https://doc.rust-lang.org/reference/behavior-considered-undefined.htmlCan you elaborate this? Is it like when your program wants an integer between 1 and 5 and it gets -420?
This is a matter of correctness: does your program behave as expected? (Rust can help with this with eg. types to prevent integer overflow)
What we mean with undefined behavior is it’s actually undefined. There’s quite a lot of constructs you can use in C which will get compiled to different instructions by the compiler and behave in unexpected ways. Or even when compilers agree on a certain way to do it, use-after-free and other patterns can lead your program to taking unpredictable turns.
So, just because your program doesn’t have undefined behavior doesn’t mean it’s correct. But if it’s correct, it can’t have any undefined behavior. If you’ve ever noticed how most programs written in C/C++ seem to have hard-to-reproduce bugs (eg. desktop environments) you’re very likely to have encountered undefined behavior in the wild.
Rust kinda sucks for writting windows guis.
Of course it sucks, as rusts borrow cheker is intrusive and programmatic, whilst in C references to entities are mxied (i.e. sometimes caller owns, sometime framework etc.) and conventional (i.e. you have to read docs in API to know what you can/should do with a reference).
I consider rusts intrusivness is a weak point, and it’s programmatic checking of ownership is strong point.
So, if you have a mixture of two worlds (C and Rust), it might be a pain to have such an achitecture. For simple cases, of course, there are no big issues, but things like GUI are not simple things, that’s why Rust is still not here, IMHO.
Rust is really bad with global side-effects from one object to another. In some regards, Rust is a really good object-oriented language (in the “original” definition) because it has strong typing guarantees, first-class interfaces (traits) and the best (de)serialization library i’ve ever encountered [0].
But Rust being parallel-friendly by default will prevent you from all sorts of patterns common in dynamic languages (JS, Python, PHP), where all objects hold mutable references to any other object (without clear hierarchy/interface) and anything can be mutated from any part of the program. In single-threaded programming, this kind of object tinkering can lead to unexpected behavior (not undefined behavior) where one tiny function somewhere will have crazy side-effects that will break some other part of the program. But in parallel programming, it’s certain to cause all sorts of quirks due to race conditions (two threads accessing/modifying the same data).
In that sense, Rust takes some inspiration from functional programming, and side-effects are declared with mutable pointers (
&mut Type). So it’s still technically possible to do everything you do in a dynamic language in Rust, but the language doesn’t make it especially easy. I personally think it’s a very good trade-off. Although i’m sometimes bored to write more boilerplate, i can’t stress enough how relaxing it is to have your code working expectedly as soon as it compiles. It feels like a superpower.[0] serde. Seriously, serde is so powerful and standard across the Rust ecosystem that writing serialization code in golang/python feels very clunky after trying that out.
warning: very confusing comment, this is a complicated topic
Rust, in a vacuum, can do anything basically perfectly (yes, even unsafe code, at least it’s clearly marked as so). However, the vast majority of people aren’t writing rust in a vacuum, they are using the “rust ecosystem”, and, for better or worse, the “rust ecosystem” is mainly useful for two things: making back-end servers and standalone libraries (look into rust’s history and you’ll see why)
I hear a lot about how the things that Rust is not good for, JIT compilation with a garbage collector is usually the best solution, and vice versa. How true is this?
JIT compilation is good for embedded programming languages, rust isn’t one so they don’t support it (although JIT compilation is a very complex topic, especially when talking about use cases)
Garbage collecting is a simple way to ensure memory safety without the whole complex memory layout of rust, rust doesn’t have it because it does not need it
Programming languages are just tools, use the right one for the job.
It’s pretty lousy for exploratory programming, where you load your current application to memory, then start adding a new function onto it, hot reloading on every change and testing your changes in the REPL. Rust’s best approach to this seems to be evcxr, which is quite janky.
Examples of language implementations that are good at this: python (especially with ipython), most common lisp implementations.
