Rust sucks because
wiki.theory.org
wiki.theory.org
We’re not quite there yet with defining rigorous semantics for unsafe code (there are still a couple of undefined things at present), but Rust does intend to rigorously define all behaviour. So this is a quibble which is being dealt with.
(Note that there’s still the odd rustc bug involving LLVM doing something it shouldn’t, but those are just bugs. See https://github.com/rust-lang/rust/issues?q=is%3Aopen%20label... for a couple.)
> but you need unsafe code for anything complicated.
… what? Somewhere deep down in your dependencies, maybe, but for most things you really don’t need unsafe code.
----
Most of the rest of the issues are either Rust immaturity (compiler is slow, &c.) or tradeoffs that the language has made (String vs. &str). There are definitely some legitimate criticisms in it.
> … what? Somewhere deep down in your dependencies, maybe, but for most things you really don’t need unsafe code.
If anyone has an account or feels like creating one, that line really should be changed to "unsafe code can't always be avoided" or "fundamental types like Vector are implemented with unsafe" or something similar.
That's kind of the point, though: Vec provides a safe interface over behavior that would otherwise be unsafe. You could as easily complain that C is fundamentally implemented in machine code without any type safety.
i'm of the opposite view here; though, i think i get where this is coming from.
for me, if i look at it from a "broader timeline perspective", the length of keywords (like say "function" in JS) is mildly annoying to me. especially if they're high frequency.
over time, familiarized keywords essentially "fade into the background" and afterward just occupy precious horizontal space, but provide a valuable sort of visual shaping or pattern.
given this, i love the elements of terseness in rust syntax. my identifiers are what i want to be more expressive and descriptive. this combos well: terse keywords and stdlib elements contrast excellently with longer identifiers and make it easier and faster to read (for me).
[1] http://emacsredux.com/blog/2014/08/25/a-peek-at-emacs-24-dot...
Keywords are not really the problem, it's more when people start abbreviating their identifiers.
One I saw in some codebase a while back was xxxxRec and it took me a while to realise it was an abbreviation for Receiver because for whatever reason my initial mental auto-complete was Record and that wasn't making much sense.
And while it will always be obvious to the person writing the code, it might not always be obvious to the person reading the code. Sometimes that's even the same person.
So I agree that Rust feels a little too heavy on abbreviations at times.
In fact, I find myself waffling on generic names as well, T is common, but when you get up to 3 or 4 generics in a function, it starts looking like more expression is needed. Though I still use single or double characters, I do think about changing my mind here.
Naming is hard, naming in generic code is x^y harder.
My thinking has changed. Lately I think the job of the language is just to provide variable assignment, function calls, and a couple other basics. Most programming languages go far above and beyond and they become impossible to use for beginners, which means they can't be used on a diverse team. And worse, they tempt intermediate programmers into using complex control structures instead of doing the design work to figure out which boring-ass array processing functions they actually need to write.
I think the core challenge of programming is to write code that inexperienced people can understand quickly. Partly because your teammates may be inexperienced. Partly because 2 years from now you will be inexperienced with respect to this part of the code. Advanced programming language features are generally antithetical to that. Terseness is antithetical to that.
Instead, we get giant codebases that require full time attention from an expert programmer, in order to have any chance of extending anything.
I want code that uses the most basic possible programming primitives. I names to be as verbose as necessary so you don't have to look a lot of places to see what's happening. And I want the data model to be as simple as possible.
I want to see that the programmer told the rest of the organization "No" over and over, and that the code does very little, and uses childlike tools to do basic things. I am not impressed by wizardry, and trivialities like "function" versus "def" don't matter to me anymore at all. I am impressed when someone makes something small and simple and good.
This is a pipe dream. For anything significantly non-trivial, programming is inherently complex. Designing the language so that code is forced to be "simple" at the lowest scale just pushes that complexity up to larger scale code structures.
Trying to make programs easier to understand by limiting the expressivity of the language is like trying to make quantum physics easier by reformulating it without using complex numbers. Whilst it may well make each individual step of a calculation easier to understand, it doesn't make the whole any easier to comprehend.
I disagree strongly that code in non-trivial systems must be inherently complex. Complex code can be broken into simple pieces, but it takes time to find the abstractions. I spend at least as much time making my abstractions better as I do making things work. Many managers won't let you take that time.
> Whilst it may well make each individual step of a calculation easier to understand, it doesn't make the whole any easier to comprehend
You're used to the notion that programmers must keep entire codebases in their head because that's the norm: leaky abstractions where any part of the codebase could have implications for any other part. That how we in the tech world tend to build things in 2016. You need to understand the whole before you touch any part of it, or you'll likely break things.
But when you find the right abstractions, you don't need to understand the whole codebase to get things done. In fact, that's how you know your abstraction is good. You stop seeing problems that span it.
Rust generally suffers from a Perl-like visual clutter, caused by a proliferation of punctuation (I have a particular hatred for "::") and also the unfortunate choice of snake_case for identifiers. Some of these things work in Ruby and Python because they're otherwise very uncluttered languages, but in Rust they only exacerbate the noisiness. (As a minor aside, it's always bothered me that almost all snakecase languages don't Capitalize_Like_This, so they're not symmetrical here. Oh, well.)
The Rust devs always bite back when I complain about the above. I know they put a lot of thought into it; I just think they could have put in more. The visual aspect of code is almost always underestimated by language designers.
(On a semi-related note, I really like how Facebook's Reason cleans up OCaml's syntax.)
[1] https://whathecode.wordpress.com/2013/02/16/camelcase-vs-und... [2] www.cs.kent.edu/~jmaletic/papers/ICPC2010-CamelCaseUnderScoreClouds.pdf
Those studies seem to look at readability in isolation, but in my opinion the readability problem emergeces when combined with many other sources of "noise". Snakecase works perfectly fine in less noisy languages like Ruby and Python where there's little clutter in the first place. In a noisier language like Rust, camelcase would have helped give it more visual cohesiveness.
That said, I'd love a programming font that could actually align the underscore with the font baseline. In all of today's fonts, the underscore breaks up the identifier into little pieces. Compare the vertical cohesiveness (not perfect, but closer) of:
an⎽underscore⎽identifier
an_underscore_identifier> There's actually a special Haskell search engine to search for anything related to Haskell, because of the funky syntax not playing nice with Google.
Hoogle is so extremely convenient, it's a big plus imho
I completely agree with this. This type of naming convention shouldn't even be a remote possibility in this day and age. I find it extremely difficult to read coming from mainly a C# and Java background.
Rust sucks because it takes several weeks to become proficient in its use.
That's a huge expense for any person or company that wants to use it. It may be worth it long term to switch to Rust, but if you fail in the short term there may be no long term to worry about.
I do not intend this to be advocacy for or against Rust, but your observation is true and also indicative of a profound, self-defeating issue with this industry: Intelligent, educated developers often chose the option that gives the quickest gratification, even if it causes significant long term problems. PHP is an example. So is MongoDB (and indeed many document stores). A lot of shops ended up becoming "Microsoft shops" only because it was easy to install things from the MSDN discs. Etc.
Most projects of significance encompass tens to hundreds of thousands of hours of work. A small cost upfront is usually insignificant.
It really is about tradeoffs. If developers have infinite time and money, I am pretty sure that everyone would ditch those 'ugly' languages. But we are not living in this utopia. There are time and money constraints that developers have little or no control over.
> Most projects of significance encompass tens to hundreds of thousands of hours of work. A small cost upfront is usually insignificant.
Unfortunately, not all those who mandate what stack to use know this
That's the thing though, if spending two or three weeks right now to learn Rust will save you months of technical debt and futzing around with crappy standard libraries and language weaknesses in the future, then the prudent move would be to ditch the weak language in favor of Rust, regardless of its learning curve, since the end result will be a significant net-positive.
I also think this is a copout. Take Java, for instance. It was new and different when it came out in the 90s, but companies all over the map were willing not only to spend weeks learning it, but also months (or years) re-writing all their crap in Java, even though it was a dismal failure in almost every instance (e.g. Java-Netware, Java-WordPerfect, Java-VisualStudio, etc.)
This. There's a really good point on tradeoffs in Rich Hickey's talk on "hammock driven development":
"Most developers use the word 'tradeoff' to describe parts of their software that suck."
If you haven't evaluated the alternatives, it's not a tradeoff. And if you are sacrificing long term maintainability for two weeks of productivity, you most certainly haven't thought it through.
Huh? It takes years before developer starts writing C++ code that does not blow up in production. Even with JavaScript or Go it takes months to start writing reasonable code (as opposed to something that just seems to work). What are you comparing it to?
This probably explains the popularity of interpreted languages.
It doesn't take months to teach oneself JavaScript or Go and actually write code with it. If it did these 2 languages would not be as successful as they are. Rust on the other hand won't compile until the learner respects Rust memory model. These aren't syntax errors or even type errors, these are "ownership errors" which are a whole new level of errors most people don't want to put up with.
Something like Go is much easier and faster to become productive in—but then its ruthlessly constrained design paints it into a corner for some things. (My own experience with it is that Go can be fairly nice for writing applications in, but it’s often quite painful to write libraries in.)
Really, the conclusion of the matter is that Rust isn’t for everyone, and it’s not perfect yet and will take longer to get to a given level of quality than something like Go. (If as much effort was expended on Rust and rustc performance as has been expended on JavaScript performance, whoa, that would be breathtaking.)
The tools used in most other industries change on a time scale of decades, not months. Some of them don't change for centuries.
Pencils, hammers, and frying pans don't become obsolete, while the language/framework/magic thingie of the day is almost guaranteed to do so.
Maybe Rust will take over the world and last as long as C, Lisp, or FORTRAN, but that's certainly not the way to bet.
I would guess the answer is yes. After all the new tool needs to be much better than existing tools to justify weeks of retraining.
In fact, I suspect programmers are willing to put up with a lot more compared to other professionals since we do a lot of our learning in our spare time.
They are probably evaluating: 'So, what do I feel about learning Rust stuff for the next 10 years?'
Weeks? That's nothing. It takes months, if not years, to become proficient in C++, for example.
(I understand that you are talking about the training of the existing employees, but still.)
Also they think knowing to write the code is the same as knowing to code in that language. It's not true at all. It's quick to be able to write C code. Being able to produce something worth being on prod however, takes month.
A few weeks seems like a good trade to me for the safety rust provides for a lot of applications.
If I was building applications where performance is key (such as networking, Kernel, OS libraries etc), Rust would be great for me. But currently Go gives me enough speed and is far easier to make progress in (with the time I have available).
Rust has a great community, that was a key take I tool from my time there as a newcomer.
People claim that they are quickly productive in Golang, one can also be productive in Rust in a similar amount of time. Satisfy the borrow checker with .clone and .copy. The end result will be the same. Using something doesn't mean that you are required to explore the full depth and breadth of it.
"Why Rust Sucks" is at the very end.
https://wiki.theory.org/YourLanguageSucks#C.23_sucks_because
https://wiki.theory.org/YourLanguageSucks#JavaScript_sucks_b...
Here is the issue: A lot of developers actually like the C/C++ freedom they have even if it leads to horrible bugs as they are used to program the way they do.
Others are people that don't care about memory management and are fine with GC, nil errors and race conditions.