I just find Rust to be very clumsy and high-friction. This isn't a technical criticism, merely a matter of personal taste. But I dislike Rust enough that I've decided that I won't take a job that requires me to use it.
Rather than risk getting into an online argument about Rust, though, I'd prefer to focus on the idea that we should have more than one "memory-safe" language.
> I'd prefer to focus on the idea that we should have more than one "memory-safe" language.
The very very large majority of code written today is done so in a memory-safe language. C/C++ is the only mainstream exception.
The reasons we associate the phrase "memory-safe" with rust is 1) memory safety has been a solved problems for decades for most programming languages, so we forgot about it, and 2) it was _not_ a solved problem for "systems" languages like C/C++ that rust is directly trying to steal market share from.
There are an awful lot of memory safe languages. For example Python, Java, JavaScript, and the safe subset of C#. Rust just happens to achieve memory safety with a relatively low runtime overhead.
Java and C# have been AOT compiled from yearly days as well, the difference to today was for Java AOT compilers were only available in commercial JDKs, and NGEN only supported dynamic linking, while being designed for fast startup times only.
I have a similar opinion. What puts me off about the language is it's horrendously ugly syntax and toxic, cult-like community (maybe these types are a minority, but they are awfully loud).
It's like someone took C, Python, and Perl, extracted the worst parts of all three and jammed them into one hellish language. There's not one thing about rust syntax that I enjoy. It's probably the worst out of any language I've tried, including Perl.
I would rather read someone else's Perl script than Rust.
It's very much one of these new-age languages that feel the need to reinvent every wheel and invent entirely new syntactical idioms just so they can be different.
And yeah, the "just use rust, pleb" attitude is also super offputting. I'm not interested in dealing with people like that when I'm learning a language. I have plenty of much, much less terrible options.
Sure, "let foo = bar" is one of the worst things any language can do.
Let is redundant, that's what the = is for. Unless it's meant to be equivalent to 'var' or 'auto', in which case it's even worse.
Let contains no information, it's pointless clutter that replaced something that did contain vital information. Let tells you the next symbol is a variable. What type? Who knows and who cares, it's a variable, deal with it. C marks a symbol as a variable by using its type name.
I mean, this was a very large part of why Perl is so miserable. I will never understand why people choose to implement this in modern languages.
Anyway, variables and parameters without explicit, visible type information is a hard no for me. I took a sniff of a couple rust projects, saw this mess, and decided that rust is not for me. I don't care about all the other magical benefits that cure all my ails, this feature is a dealbreaker, full stop.
`let` defines a new binding, as opposed to changing the value of an existing binding. You can't remove `let` to keep only `=` because it has a different use case.
Not indicating the type is idiomatic in Rust, but you can annotate it:
let commit_message: String = repo.head().peel_to_commit().ok()?.message()?.into();
Here this is useful to specify the type `into` should convert to. However, if rewritten as:
let commit_message = repo.head().peel_to_commit().ok()?.message()?.to_string();
Then it is useless because we're already specifying the type of the variable by using `to_string`.
Note that IDEs are displaying type hints anyway (without you having to type them), so you don't have to suffer if walking through a codebase where people are annotating their types too little for comfort
I can’t take anyone who says the syntax of Rust is worse than Perl.
What new syntactical idioms did Rust invent? It’s pretty plain and easy to read, anyone who has looked at C, C++, Python, C#, Java or anything modern will grok it pretty easily.
lifetimes, async, the myriads of pointer types, that poor-person's monad '?' for a single type..
Sure, you need to give the compiler a lot of hints to achieve what Rust is doing, but it does not look pretty or elegant.
Lifetimes are indeed unique, but hardly take up much syntactical space.
? operator is fine, especially if you’re used to JS or C#, and hardly take up much space.
Pointer types are what, & and * ? Fine if you’re coming from c, c++ and don’t take up much space.
.async is the weirdest for sure, but again hardly strange or disgusting.
What about any of this is worse than if I smashed my face into my keyboard but hit only the $*%#•¥$><~.,!=&@£.?!’ characters, aka writing Perl? Or anything as totally alien as Haskell?
Most Rust I read or write, if I squint, looks like Python with a few extra braces and semicolons.
I was thinking of things like Box, Rc, Arc, Cell, Refcell. Then there is also the macro language, which integrates Scheme concepts. Like C++, it is a huge language, with extra wrinkles for every new corner case. Again, maybe this all is unavoidable if one wants to have zero cost abstractions. Hopefully, language designers will learn from Rust and come up with something more elegant.
Out of those, Box is the only one that is, and the way that it is is not syntax: it has one exception, and that’s that you can move the contents out of it via a dereference. That’s making existing syntax semantically valid, not introducing new syntax.
In terms of syntax, you create a box with Box::new just like you might any other struct.
EDIT: anyway I'm not saying that means that your underlying issue isn't real, just that I think describing it as "syntax" makes the issue confusing to understand. It sounds to me like maybe you think Rust programs are too verbose?
This seems like a meaningless trivialization, because you completely remove the meaning and purpose of the thing. All the code you write gets converted into machine code. Why not write machine code then? If you write it long enough it'll seem normal.
Not sure why either why the article just gives Rust as an example. Whilst there are some performance demanding use cases where Rust/C/C++ are really the appropriate choices, >99% of applications that have been written and are out there are not really worried about shaving the nanoseconds off or GC-pauses and are working just fine and memory-safe on Java/C#/Go/Python/Javascript/Ruby/PHP etc...
Memory safety in a general sense of "just" computing things and getting an answer has been solved for a long while by using either garbage collection or static, bounds-checked, allocation with handles and liveness checks. It's the intermediate space where you can allocate byte buffers and make pointer structures willy-nilly that is troublesome, and idiomatic C sends you in that direction like flypaper.
Rust is useful in addressing that specific space - with qualification, since of course it concedes to pragmatism and lets you do an "unsafe" where you want to break the rules.
But I believe the future of low-level is more in the realm of original open-hardware designs, because you CAN design a computer that builds in the kinds of runtime checks that are currently done in software. It just isn't the focus of companies that want to sell a lot of bells-and-whistles silicon.
The debt amount is so surreal that you mixed up the units (it's 33 trillion not 33 billion) and also you missed an entire trillion dollars (it's 34 trillion not 33 trillion) or maybe it just went up by a trillion since you wrote that message.
They are make believe. The number isn't real. Because if they default, so what? Nothing truly dire will happen, because they still have the ability to project a fantastic amount of force anywhere on earth.
Of course its very different than normal entities being in debt, since the government is ostensibly an arm of the people, who's income comes from taxing the populace.
But it _is_ still debt right? It is still money owed. It is still money that was spent by the government by taking loans and promising to pay back those loans, again on behalf of the people.
Once in a while, might be worth questioning who they borrowed the money from, what they spent it on, and who they chose to spend it with. Rather than just blindly repeat the pithy line, "but its not the same as regulars people's debt".
The fact the gov can go 34 trillion in debt and a normal Joes Garage can't is actually pretty obvious to people already.
Actually, people who give out loans tend to give them out to people who they think can pay them back. You or I can't just stack loans for decades.
Fundamentally due to interest - you have to pay back people more than they gave you. So just stacking loans to pay loans isn't sustainable. And the US observably does way more with the "loans" they take out than just pay back other loans.
Put another way - if you buy a T-Bill (or other US-backed security aka a source of this debt), what is your confidence that you will get paid on time? I'm assuming very high. But if the US's debt was unsustainable, at some point the house of cards has to come crashing down, right?
Note that Rust isn't brought up in the video being discussed, and I've not actually found the source being referenced when the article says
> The White House Office of the National Cyber Director (ONCD) urged tech companies today to switch to memory-safe programming languages, such as Rust,
Happy to have missed it, but this seems to be a Rust fan injecting bias?
The report being referenced in Dec 2023 recommends these languages:
> Recommended memory safe programming languages mentioned in the CSI include C#, Go, Java, Python, Rust, and Swift. Software manufacturers should evaluate multiple memory safe programming languages before integrating them into their workflows.
Could the White House do a bit more, like requiring ALL government contractors/projects to exclusively use memory-safe programming languages? I know they are already big on Ada, but I don't know if that is still a thing for new developments.
My understanding is that Ada was mostly a DoD phenomenon. In my experience in the civilian side you’re going to find lots of things which are already memory-safe (Java, PHP, Python, JavaScript, etc.) so while I’d like to see strong support for it there I’d also look for other measures like ease of patching, good use of modern isolation primitives, etc.
Or use a C++ linter that disallows raw pointers, non-const references etc. There’s more, but, it’s mostly a subset of the language, although I admit some common syntax can get bloated this way.
You can have a use after free by taking a const reference to a stack allocated value and returning it. You can happily have buffer overruns on data structures like std::vector. You can have use after frees through misuse of smart pointers. You can have all sorts of fun problems through invalid casts.
The rules to actually subset c++ in a way that is safe by construction are actually way more harsh than commonly presented and Bjarne's proposal is, in my opinion, nowhere near strong enough to actually achieve it.
as a javascript developer, I want to know what is the main difference between Rust and JavaScript regarding memory safety.
- javascript utilizes a form of automatic memory management known as garbage collection (GC). The purpose of a garbage collector is to monitor memory allocation and determine when a block of allocated memory is no longer needed and reclaim it.
Rust is fairly unique in that it uses a "Borrow Checker" to verify memory safety at compile time. Garbage collection has a definite performance cost, which Rust avoids.
Rust relies on static memory safety. In general you want both static and dynamic, but you can take a static type safe language and run it in processes with isolated address spaces.
GC is largely orthogonal to memory safety, although it is really hard to implement GC in languages that don't have static type safety (although not impossible).
64 comments
[ 2.6 ms ] story [ 45.1 ms ] threadWhat about other languages would you rather see?
Rather than risk getting into an online argument about Rust, though, I'd prefer to focus on the idea that we should have more than one "memory-safe" language.
The very very large majority of code written today is done so in a memory-safe language. C/C++ is the only mainstream exception.
The reasons we associate the phrase "memory-safe" with rust is 1) memory safety has been a solved problems for decades for most programming languages, so we forgot about it, and 2) it was _not_ a solved problem for "systems" languages like C/C++ that rust is directly trying to steal market share from.
https://media.defense.gov/2023/Apr/27/2003210083/-1/-1/0/CSI...
https://www.whitehouse.gov/wp-content/uploads/2024/02/Final-...
The excerpt of the section on memory safety and space that I read seemed to be more concerned with deterministic timing.
Did they address memory corruption?
https://media.defense.gov/2023/Apr/27/2003210083/-1/-1/0/CSI...
I would rather read someone else's Perl script than Rust.
It's very much one of these new-age languages that feel the need to reinvent every wheel and invent entirely new syntactical idioms just so they can be different.
And yeah, the "just use rust, pleb" attitude is also super offputting. I'm not interested in dealing with people like that when I'm learning a language. I have plenty of much, much less terrible options.
Let is redundant, that's what the = is for. Unless it's meant to be equivalent to 'var' or 'auto', in which case it's even worse.
Let contains no information, it's pointless clutter that replaced something that did contain vital information. Let tells you the next symbol is a variable. What type? Who knows and who cares, it's a variable, deal with it. C marks a symbol as a variable by using its type name.
I mean, this was a very large part of why Perl is so miserable. I will never understand why people choose to implement this in modern languages.
Anyway, variables and parameters without explicit, visible type information is a hard no for me. I took a sniff of a couple rust projects, saw this mess, and decided that rust is not for me. I don't care about all the other magical benefits that cure all my ails, this feature is a dealbreaker, full stop.
Not indicating the type is idiomatic in Rust, but you can annotate it:
Here this is useful to specify the type `into` should convert to. However, if rewritten as: Then it is useless because we're already specifying the type of the variable by using `to_string`.Note that IDEs are displaying type hints anyway (without you having to type them), so you don't have to suffer if walking through a codebase where people are annotating their types too little for comfort
What new syntactical idioms did Rust invent? It’s pretty plain and easy to read, anyone who has looked at C, C++, Python, C#, Java or anything modern will grok it pretty easily.
? operator is fine, especially if you’re used to JS or C#, and hardly take up much space.
Pointer types are what, & and * ? Fine if you’re coming from c, c++ and don’t take up much space.
.async is the weirdest for sure, but again hardly strange or disgusting.
What about any of this is worse than if I smashed my face into my keyboard but hit only the $*%#•¥$><~.,!=&@£.?!’ characters, aka writing Perl? Or anything as totally alien as Haskell?
Most Rust I read or write, if I squint, looks like Python with a few extra braces and semicolons.
No disagreement about Perl's ugliness..
Macros are syntax though.
In terms of syntax, you create a box with Box::new just like you might any other struct.
EDIT: anyway I'm not saying that means that your underlying issue isn't real, just that I think describing it as "syntax" makes the issue confusing to understand. It sounds to me like maybe you think Rust programs are too verbose?
Rust is useful in addressing that specific space - with qualification, since of course it concedes to pragmatism and lets you do an "unsafe" where you want to break the rules.
But I believe the future of low-level is more in the realm of original open-hardware designs, because you CAN design a computer that builds in the kinds of runtime checks that are currently done in software. It just isn't the focus of companies that want to sell a lot of bells-and-whistles silicon.
But it _is_ still debt right? It is still money owed. It is still money that was spent by the government by taking loans and promising to pay back those loans, again on behalf of the people.
Once in a while, might be worth questioning who they borrowed the money from, what they spent it on, and who they chose to spend it with. Rather than just blindly repeat the pithy line, "but its not the same as regulars people's debt".
The fact the gov can go 34 trillion in debt and a normal Joes Garage can't is actually pretty obvious to people already.
Fundamentally due to interest - you have to pay back people more than they gave you. So just stacking loans to pay loans isn't sustainable. And the US observably does way more with the "loans" they take out than just pay back other loans.
Put another way - if you buy a T-Bill (or other US-backed security aka a source of this debt), what is your confidence that you will get paid on time? I'm assuming very high. But if the US's debt was unsustainable, at some point the house of cards has to come crashing down, right?
And the US does more than just pay loans back by taking out other loans.
> The White House Office of the National Cyber Director (ONCD) urged tech companies today to switch to memory-safe programming languages, such as Rust,
Happy to have missed it, but this seems to be a Rust fan injecting bias?
The report being referenced in Dec 2023 recommends these languages:
> Recommended memory safe programming languages mentioned in the CSI include C#, Go, Java, Python, Rust, and Swift. Software manufacturers should evaluate multiple memory safe programming languages before integrating them into their workflows.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p27...
You can have a use after free by taking a const reference to a stack allocated value and returning it. You can happily have buffer overruns on data structures like std::vector. You can have use after frees through misuse of smart pointers. You can have all sorts of fun problems through invalid casts.
The rules to actually subset c++ in a way that is safe by construction are actually way more harsh than commonly presented and Bjarne's proposal is, in my opinion, nowhere near strong enough to actually achieve it.
what about Rust?
GC is largely orthogonal to memory safety, although it is really hard to implement GC in languages that don't have static type safety (although not impossible).