Rust 1.53 (opens in new tab)

After doing a couple of projects with it, I have found that learning Rust is an exercise in futility. I wish I had never heard of Rust. What will happen is you'll immediately recognize it as the greatest language ever invented and you'll want everyone else to know about it. You will try to convey what it is about Rust that makes all other languages obsolete, but they will look at you like you're a crazy person. You will be ostracized and considered a lunatic. You will lose all your friends. They will say you are part of a cult now and you will eat your lunch at a separate table. You have seen nirvana and will never be satisfied again with doing your old Python or JavaScript job. After doing a few projects in Rust, yet unable to convince your non-programmer managers why they should convert to it, doing your old job no longer brings the joy it once did. You will stop shaving and grow a long beard. Because using non-Rust languages is basically the same as living in the past. The world has lost all its color. The future is Rust, and yet the business world is too conservative, or too afraid, or too incurious to make the leap. This is how I feel about learning Rust right now.

Nice advice!! Would definitely start learning it from this year itself.

Disagree - a low level language can’t really mask itself as high level, the abstraction will always leak. Don’t get me wrong, Rust is a really great language and it is a very welcome addition to the for a long time seemingly stagnant low level world, but you won’t be able to refactor logic-related parts “without a thought” on memory layout, even ownership, etc —- something trivially done in high level languages. C++ tried the same thing, without luck.

So for a typical CRUD app, just use one of the litany of high level language frameworks and be done with it.

Enterprise applications are already fast enough, but memory footprint can still be a real pain. Monitoring and deploying the JVM isn't easy, and I think there is absolutely room in the future for lower footprint deployments in the enterprise space. Golang has already seem some limited adoption, but has a limited type system that doesn't easily allow expressing complex business logic. Rust has the possibility to really shine here, even if it doesn't eat the enterprise world.

> their ecosystems are much richer.

The Rust "ecosystem" can seamlessly expand to include any language with a C ABI and FFI. Solutions are also being developed to ease interop with managed platforms like Java/C#.

Contrast this with something like Go, where even interoperability with C does not come out-of-the-box and requires compromising the most desirable features in the language itself.

Nitpick, but GC pauses are basically no longer a problem with low-latency GCs like ZGC or Shenandoah in the JVM.

Lifetimes qualify as esoteric, I think. They seem unique to Rust (please correct me if wrong) and are not immediately intuitive.

Do you recommend it for those developers not working in the C/C++ space?

Loom is a great example of the Java designers still not getting it. Taking on a lot of JVM complexity in order to reuse the same broken API.

I could never figure out Githut2.0. Githut1.0 had a much nicer interface and although Rust looked bad on first impression, just moving it left a set period of time (or vice versa moving Go right a set period) showed that Rust actually grew at a very similar rate as Go... until Rust started accelerating by around 2018. I suspect something similar may be the case on Githut2.0 but just too hard to tell. Linear graphs comparing exponential growths can be very deceiving.

In my experience TIOBE is very noisy and bad at predicting long-term trends for languages outside the top-ten or so. And it seems even worse recently due to Covid. Heck Julia recently jumped into the top-20 for a single motnh earlier this year before falling back to the mid 30's. And that isn't even all that uncommon for TIOBE. I think I see a trend of Rust slowly climbing, but it is hard to tell through the noise.

PYPL says Rust has respectable growth and that its growth is remarkably consistent (i.e. it is growing at a near constant expeonential rate until 2018, then slowing down a bit in 2018 and then continuing at a very constant and this time faster exponential growth rate.

Redmonk calls Rust the tortoise language (from the hare and the tortoise story). It's growth is never impressive, but its steadiness in growing is very impressive.

You actually do mention some success stories. Also, Amazon is using Rust for a lot more than Firecracker. A lot of their critical infra is in Rust. Also, rustls is pretty big, IMO. Finally an actually secure implementation of SSH. ;-) (And fast to boot.) The Ferrocene project project is fully open source, paid for in full by donations despite the considerable expense because some of the (very big) high integrity industry really want to use Rust The Linux kernel is seriously considering including Rust and Linus said something like Rust in the kernel is inevitable. The Linux kernel team (and Linus specifically) are notorious for their previously adamant hostility towards any language other than C in the kernel. They are starting carefully with just drivers but that's already way more than for example C++ ever managed. On the CNCF, we have TiKV and Linkerd2 in Rust. These aren't small or unimportant projects although, no, they don't quite match k8s.

Over all. Rust is trying to replace C/C++. That is a very tall order. No previous language have ever come close to where Rust currently is already in that task. But it is not going to happen over night. It is a huuuuuuge task that will take a lot of time and a lot of resources and a lot of mindshifts.

Regarding improvements in the other languages. Sure, but C++20_0000_000 will not come close to some of the advantages Rust already had by 1.0 unless they are willing to break backward compatibility to the point where you can just as well rewrite in Rust. All those languages are fundamentally broken or limited in ways that cannot be fixed or worked around. Rust also have historical baggage already. But it starts from a much better starting point with a lot of lessons learned.

How have unsafety been addressed in C/C++? C++20 is exactly as unsafe as C. It has much better what I call "safeness", but that's like saying by going from 1 to 10 I made progress towards infinity. It reduces some classes of errors, if you know what you are doing and apply considerable discipline. It doesn't eliminate any errors. C++20 is sill based on the C abstract machine, which is to say a DEC11. It is still very hard to do some optimizations that are easy or even trivial in Rust and some that would've been trivial if LLVM didn't miscompile perfectly correct code. C++20 still doesn't have a borrow checker and will never have one remotely as capable as Rust's. C++/Java/C#/Python/... are still OOP with inheritance which is fundamentally at odds with really capable composition which is fundamentally superior in expressive power and fits a lot of domains a lot better. Yes. Those languages can close the gap. They can never catch up. Can they get close enough to reduce the value proposition of the newer languages to the point where the newer languages (or some others even newer than these) won't take and hold a considerable fraction of their market share? I doubt that. But taking the market share of the incumbents will take very long. The network effect is brutal. But sometimes a disruptive technology is too good to stop it from -- eventually -- overcoming that effect. Of course, again exponential growth means what starts slow can quite suddenly explode. Also, when sufficient barriers are overcome or a language gets the rigth killer app it can again explode. May be for Rust that'll be high integrity or the Linux kernel. Consider that Redleaf is already vastly superior (better security, better performance, more features, more portable) and vastly cheaper to develop and verify than sel4 for one impressive achievement. Of course, until we can actually compile Redleaf on a certified rust compiler (probably by next year), Redleaf will remain an academic curiosity. But once we can? I'm no high integrity developer, but it seems the sky's the limit.

Yikes! That was a lot of words! Sorry, but I'm too tired to edit.

Your statement here has so many qualifiers that it's hard to treat it as a general rule.

"English speaking world"

"untypeable"

"public API"

Even then you exempt Greek symbols. I suppose you might be willing to accept ¢ or €. Of course, "untypeable" is very ambiguous.

Still, not all code is "public API" and not all code is intended for the English speaking world. So I think it's great to support non-ASCII symbols.

よろしく

There's lots of non-english codebases out there, supporting symbols for their languages is a big deal.

In a way, it's in part a job for the dev tools. Autocomplete engines should be able to complete these symbols from an ascii-only hint. 'a' should offer "α" as one of the completion options, and 'bla' should offer "BLÅHAJ".

I like to use the poop emoji in the names of methods that are dangerous hacks that we want to (eventually) get rid of.

Being harder to type is part of the point.

It's really not hard at all to make them typeable, it just requires some minor setup (use an IME). Still doesn't necessarily mean it's a good idea, but it's not a total blocker.

They're hard to type if you're a Windows user. Other OSes have better input systems.

> Maybe, and this is a fat maybe, Greek symbols could make the odd write-once math or scientific code easier to read.

The Julia community has been trying really hard to convince people that this is a good idea and I'm still not on board with it.

I tried doing this once, but it's not worth the pain of having to switch keyboards or copy-paste symbols