Here's a story: I once did a hackathon with a few acquaintances for a few hours where our goal was to write a simple Matrix bot. Given that we were always chatting about Rust, a couple chose it for their bot. I chose Python.<p>My basic bot was done in about an hour. One of the guys took about an hour to try and compile an outdated, abandoned crate for interacting with the Matrix API. I recall he then had to write his own using async/futures. It took him about 6 hours and he was working well into the early morning after we'd already left. The resulting code was hideous - a slurry of nested closures, ?s, unwrap()s everywhere. The compiler was throwing demonicly complex compile errors at him and he was doing whatever he could to get it just to compile. Bearing in mind he was not new to the language.<p>No, I'm not arguing that Python is better, these languages clearly have a different purpose. I'm arguing that if it takes a really smart guy like him more than 6 hours to produce something of that quality in Rust then... it's not for me. I've already tried it and development with it is just slow and I don't like several syntax decisions. Not to mention the crate ecosystem which is primed to be the new npm disaster.
> I predict that garbage collectors will become popular in Rust eventually.<p>Not having a GC and not freeing memory by hand is one of the features that makes Rust special. What would be the point of this?<p>> I feel like Rust is self-defined as a “systems” language, but it’s being used to write web apps and command-line tools and all sorts of things. This is a little disappointing<p>Why would using the language for non-system programming be disappointing?<p>I have a feeeling that it has become popular lately to criticize Rust for whatever reason, I guess that's what happens when more people use the language
Rust is a good language overall, but it has some serious flaws that it seems those in control of Rust have no interest in fixing.<p>For example, it is possible to make the borrow checker accept self-referential structures, but nobody has done the immovable type etc work required for that. Which means, for non-trivial data structures, you need to either reach for unsafe or Rc/Arc. I write a lot of very multithreaded code, so for me it's almost always Arc, which means paying for atomics. And since the Drop trait takes an exclusive &mut reference, you must use fugly nested structs to prevent UB if you have shared mutable pointers you need deleted automatically.<p>I'd recommend learning Rust, but I'd also strongly recommend that you willfully push the limits of the language. Rust needs to be stretched out to accommodate more contemporary programming constructs, and you can help with that. Also, stay away from the core team and organization, they're poisonous as hell. I'd recommend donating to gccrs to help alternate implementations.<p>On the positive side, you do still end up with an awful lot of zero-cost safe code, and Rust is pretty nice to work in once you actually understand it.
> The Rewrite Fallacy<p>This is a good general point that isn't even about Rust. It crops up a lot in the always ongoing database wars where people keep swearing that one database is fast or slow or new or old.<p>There needs to be without a thoughtful acknowledgement that there are design trade-offs involved and that appropriateness for the situation is more important than the raw technology. A rewrite making code fast always raises questions about why the rewrite was necessary, what battle-hardened error cases might have been lost along the way and whether the speed-up is attributable to the tech or the skill and intent of the programmer.
Rust does not bind well with C for this reason it can not become a system level programming <a href="https://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-in-c.html" rel="nofollow">https://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-...</a>
However, there is another programming language that does not need bindings. It is called Zig and here it explains how it solves the same problem <a href="https://youtube.com/watch?v=mwrA5IRGpfU&feature=share" rel="nofollow">https://youtube.com/watch?v=mwrA5IRGpfU&feature=share</a>
> it’s being used to write web apps and command-line tools and all sorts of things.<p>Yes because crates are great IMHO. Warp for low-level web apps with filters is flexible. Rocket for high-level web apps has batteries included. CLAP for command line argument parsing is easy. Serde is superb for serialization/deserialization. Diesel and sqlx make data access efficient.<p>Is there a learning curve? Yes for sure. It can be hard for new teammates coming from JavaScript/Python/Ruby to learn about Box, Arc, Rc, From/Into, etc. The borrow checker is like a pro coach-- when you work with it, then it makes the coding process much better.
Very good point in there about the effect investment has on objectivity.<p>Proponents conflate a specific approach for memory "correctness" checking with some judgment of what is "correct", or not if it doesn't fit in the checker model.<p>I get a lot of juice out of a solid linked list abstraction in C, it has many benefits such as modest footprint leading to naturally extensible and composable object lists everywhere instead of fixed arrays that have to overallocate and break when it's not enough for some usecase. The lifecycle of the allocations that bind to the list can be opaque, but in it's not opaque to valgrind and leaks are visible without additional in-code instrumentation.<p>If the valuable uses of that abstraction cannot be handled by the borrow checker, it just means that is a restriction imposed by that checker implementation, it is not telling us that this architecture is not "correct".
Some of those are good points. But the author mentioned multiple times how Rust should have a GC, which makes me think they're missing the point of the language: a systems language as fast as C++ and with no runtime
It seems like this should have been titled "My views on Rust" as overall, the negatives don't really outweigh the positives.<p>Good job for making the front page of HN, but I honestly struggle to know why. (Maybe you're famous?)
><i>but it’s being used to write web apps and command-line tools and all sorts of things.</i><p>Are people writing webapps in Rust? When I look at trending Rust projects and Github what I tend to see are databases and crypto.
I'd like to see a Rust without Rust's main proposition (and main hurdle).<p>That is, a language that has most of the surface syntax and semantics of Rust, except anything related to the borrow checker - instead, it's all handled by a runtime GC. So there is pattern matches, immutability, traits, and so on, in Rust style, but no lifetimes and related syntax.<p>Let's call it WD-40.<p>Bonus points if this WD-40 language can also trivially call regular Rust libraries.<p>P.S. After I've written this, I read the rest of the comments, and half of them are about the same kind of idea...
On the other hand I think Rust is the future.I started using it for side projects and it's been nothing but a pleasurable experience.<p>Any place to find Rust jobs for experienced dev but new to the language?
This is a very good insight:<p>> The worst kind of compile error is the one where the compiler is complaining about something that it generated for you, rather than something you explicitly wrote.<p>> This can be compared with Haskell’s use of monads, that provide syntactic sugar. The more magic you introduce, the harder it is for newbies to learn and to talk about.<p>I agree. Too much magic (or in the wrong places - especially when it's a crutch to some language quirk) makes things awful.
Given some of the responses to this article, I'd like to note that the guidelines explicitly ask <i>Please don't post shallow dismissals, especially of other people's work.</i><p>Let us know what the article gets wrong.<p><a href="https://news.ycombinator.com/newsguidelines.html" rel="nofollow">https://news.ycombinator.com/newsguidelines.html</a>
> This is a little disappointing, but also predictable: the more successful your language, the more people will use your language for things it wasn’t intended for.<p>I thinks that one part of it. More worryingly, I’ve heard the Core Rust committee has a hard time saying “no” to new features which leads to bloat in the language.
A question for devs experienced with asynchronous/concurrent programming: what's your take on coloured vs non-coloured functions (ie., stackless vs stackfull coroutines)?
I feel Nim has the better approach towards memory management among new languages. You can pick between a few memory management schemes, use a garbage collector when needed, use manual memory management when needed or not have memory management at all if it suits your use case better.
TLDR:<p>- I see 'unsafe' everywhere;<p>- Async is problematic, colored functions!<p>- Community is nice, but it won't be forever, RIIR people are annoying;<p>Conclusion: I prefer GCed languages with default async runtimes.
Another 'I don't like Rust - I don't use it - but I like writing blog posts about it' article.<p>I wonder if there are more lines written about liking and disliking Rust in the world than actual Rust code at this point.