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