[divtiwari]

Should one learn Rust, lets say after 3-4 years, i.e by mid 2020s, once it becomes more mainstream? The syntax of Rust is a mix of OCaml/C++ and I feel some of the concepts are very esoteric for a normal enterprise Java/C#/JS/Python developer, so it takes a lot of cognitive overload to master it. So is it worth learning now or later?

[nfrmatk]

Personally, I'd say it's worth it now. I've been dabbling in Rust for a few years and while I still don't get to use it at $DAYJOB it's been a huge benefit to me. Those "esoteric" concepts have bled into other languages and my usage of them, making me a better programmer overall. Read a chapter of "The Book" once a month or so over the next 3 years and I wager you'll find yourself in a better place than had you waited 3 years to start.

[Lendal]

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.

[influx]

Sounds like everyone I've known that learned Lisp or Erlang or Haskell.....

[scns]

I can relate, i learned React in tandem with ReasonML. The first job working with TypeScript felt like watching paint dry. Awesome languages can spoil you.

[FractalHQ]

This is my life as a Svelte developer.

[divtiwari]

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

[zozbot234]

> I feel some of the concepts are very esoteric for a normal enterprise Java/C#/JS/Python developer

This notion is common among those who are first considering Rust, but also quite overblown in practice. The only thing that reasonably qualifies as "esoteric" in Rust is borrow checking and lifetimes, and these can be mitigated by using very simple idioms/patterns like cloning objects via .clone() or using copy-on-write via Cow<>.

You can then code with much the same convenience as e.g. Python, Java or C#, but it's also very clear where some potential gains in performance have been left off the table for the sake of rapid development.

[kaba0]

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.

[nicoburns]

For many, learning the low-level aspects of programming is the attraction of learning Rust. They want to be exposed to these concepts. What Rust does well is creating a golden pathway with guard rails through which one can learn these concepts without exposing oneself to the pitfalls of memory safety issues, thread safety issues and undefined behaviour.

[kaba0]

I absolutely agree, this was the line I was arguing with: “You can then code with much the same convenience as e.g. Python, Java or C#”

[nicoburns]

Ah I see. My personal take is that while Rust introduces some inconveniences not present in those languages, those languages also have plenty of inconveniences that are not present in Rust. From my perspective, enums and traits are so much better than classes as abstractions that most of the productivity lost is already made back.

[kaba0]

Rust is a very well designed language no doubt, but I think maintenance is where high level languages have an upper hand in some domains.

Also, there are plenty of high level languages with traits, eg Haskell, but if you prefer one where it is easier to express things optionally with an imperative/OOP mindset, Scala.

[staticassertion]

> but you won’t be able to refactor logic-related parts “without a thought” on memory layout, even ownership, etc

This is sort of true, in that I might take reference where I used to take a value, or vice versa, but it's pretty trivial. It's extremely rare for borrow checking or memory layout to slow me down at all when refactoring.

[jeremychone]

Actually, once you get used to Rust, what you “loose” on one side of the productivity (ownership/lifetime/dispatch) you gain on the other side with the ergonomics (enum, matches, expression, …). So our experience, is that at the end, you still a net positive on the productivity side plus the other benefits.

We started to rewrite some of our smaller js/TS utilities, ~3k LOC, and surprisingly Rust was 10% to 20% smaller. Not that it a relevant metric, but still, we were expecting the opposite.

The missing part compared to other languages is specialization, but other patterns can be used. Still, would be nice if they add a good sound specialization construct (min_specialization seems to come short so far)

The biggest challenge is to train a full team on Rust.

[ufmace]

It varies widely based on the type of app. Most simple apps using standard lib or a few basic crates/packages/gems/etc can indeed be switched over without too much fuss. But if you're using any large frameworks with a ton of dynamic features that dictate the structure of your application, such as Rails or Django, then it's hopeless, it'll need a complete rewrite with major architectural changes.

[moltonel3x]

I actually find Rust easier to refactor Rust code than my other $DAYJOB languages, thanks to its strict type system, its informative function signatures, and its syntax. These are ingredients that make Rust programming "fearless".

[mamcx]

> the concepts are very esoteric for a normal enterprise Java/C#/JS/Python developer

I on this space and found Rust to be a great boost in my ability to ship code with FAR lower debugging (post-deployment) and hosting cost (can pay for half for more than 4x the amount of load, and not even doing a lot for improve things).

Rust is already "mainstream-ish" and the amount of libraries and stuff is becoming better and better. So, I don't see any point on "wait".

Sure, it will be challenging! But the benefits are too nice to pass of, I think.

[JeremyNT]

As somebody who's worked mostly in very high level "loosey goosey" languages (Ruby, JS) for several years, I had a lot of fun learning Rust. I've still only used it for trivial things but it's an eye opener.

When I was in college, they taught C++ as the programming language (dating myself here...). I walked away with enough negative feelings about it that I thought I just hated strongly typed programming languages that lacked garbage collection, and I thought I hated compilers that spewed errors all the time, and so I gravitated towards things like Python and Ruby.

Rust has proven that I was wrong about myself. I really enjoy working with it - rust has many of the same features but dramatically modernized, and it solves so many ergonomic nightmares that I remember from C++.

With rust I find that entire classes of mistakes I can make with Ruby are straight up impossible because the compiler won't let you get away with it.

If you were scarred by C++, give it a shot, and it may erase some of those old battle scars.

[orthoxerox]

Rust is great as a hobby language, as it tickles some previously unutilized brain patterns.

I don't think it's a great replacement for Java/C#. Unless your problem is GC pauses, either language will let you be more productive even when you master the borrow checker simply because their ecosystems are much richer.

I can imagine AAA game engines slowly migrating from C++ to Rust, but enterprise applications are already fast enough in 99.9% of the cases.

[__jem]

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.

[zozbot234]

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

[iudqnolq]

Can be, yes. Seamless, no. In the best case where the api uses very old fashioned c without many pointers it's an extra afternoon at least. (I've written high level bindings for a few small libraries for hobby projects)

[oscargrouch]

There's no "language to rule them all". Java already tried and almost ruled the world, but reality is that with options languages take here and there to whats important to them, they will never expand to a certain level.

Languages compete in their axes, which for me there are mainly 4 big ones:

a) System/Performance/Control: C, C++, Rust, Zig

b) Application: Java, C#, Swift, Go, Kotlin, Nim

c) Script/Casual: Python, Ruby, Lua, Javascript

d) Domain specific: OCAML, Scheme, Haskell, Matlab

I've never seen a language ruling in two axes at the same time (as in you can use it for the same goals), let alone in all four, or at least three.

The a' axis are very hardcore languages with insane amount of control, but they will never be as productive as the b' and c' axis.

Meanwhile the b' axis is the most popular one, as they allow you to create big and complex application while being productive. Their runtime are not far away from the languages on the a' axis.

The c' axis is most productive and easy to pick up, with languages that feels more natural, but they dont have the performance of the a' and b' axis and also its hard to compose big applications on them unlike the a' and b' axis.

Maybe a successor of languages like Rust and Swift might be the on to do this, but i cant hardly see Rust in that position because programming in it have more or less the kind of productivity that C++ gives you.

I relax much more when i can write something in Swift instead of C++ or Rust for instance, and i would mostly choose it given the perfect match to the problem i'm solving.

I think we are going for a more polyglot world, not less, and i mostly use C++, Swift and Python when i can, where you can replace C++ for Rust, Swift for C# and Python with JavaScript according to your personal tastes.

But using something from one axis trying to reach for the goals better served in another axis is mostly a "when all you have is a hammer.." kind of paradox.

[kaba0]

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

[renox]

Sigh, don't take your use case of GCs and apply it as a rule to others.

I work in telecoms on the layer just above the FPGAs/DSP: even a 1ms 'pause' would be totally unacceptable here..

[kaba0]

I think you are way overthinking my comment. I just added a note that for regular, user-space applications there really is no longer a reason to use low-level languages even if latency is important.

Of course embedded will always exist, as well as specialized programs requiring utmost control over the machine.

[dexterlemmer]

I don't see any such note and it's 8 days later. May be you should check your comment again? Also, while games aren't exactly regular applications performance-wise, I think they fall more under that than embedded or utmost control and while a 1ms delay won't be the end of the world, it'll likely hurt.

[dthul]

Whether you should learn it or not I can't answer, but I want to mention that I personally don't feel anything in Rust is very esoteric. Python's metaclasses or JavaScript's prototype object model feel more unusual to me than anything I encountered in Rust. If you have never written in an unmanaged language like C++ though I could see that a lot of Rust feels foreign.

[cgh]

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

[duped]

C++ developers deal with lifetimes all the time (grep for "outlive" in a large codebase, for example). It just isn't baked into the language.

The notion of the "lifetime" is fundamental to systems programming, particularly when dealing with concurrency. It's quite natural to folks who are used to dealing with use-after-free/use-after-move and iterator invalidation bugs, imo.

[jeremychone]

I would say definitely yes. While Rust asks the developer to worry about things they don't in other "memory managed" languages, its ergonomic and expressiveness add to the productivity. Once you get used to Rust, it becomes a net positive from a productivity side; at least this has been our experience, and you get a much more efficient and robust codebase.

However, here are the following caveats: - If you have a client or employer project to do now, and you are not yet familiar with Rust, do it with your language of expertise. Rust has to be learned before starting a new real project with it. - The real challenge is the cost to train an entire team on it. - Obviously, universal languages do not exist, so if you do AI, especially modeling, use Python (for now), web stuff use JS/TS, mobile stuff, Kotlin | Swift | Dart/Flutter. You can do some Rust on mobile and even web with WASM, but those are very niche use cases.

[staticassertion]

I learned rust just before 1.0. Probably one of my best decisions as an engineer. I now run a company where we're using it as the primary language for our services.

[rcxdude]

Many people report that learning rust made them a better C++ programmer (because the kind of habits rust enforces are things which good C++ programmers do to avoid memory problems). I would expect this would work with C as well to some degree. In that sense it may be worth learning even if you never really use it professionally.

[PowerfulWizard]

I've enjoyed learning Rust and there is is a lot I like about it, I've just been doing leetcode problems with it though and not working on large projects. In my view, the biggest advantages and steps forward with Rust the language are:

1. Memory management

2. Typing

I think your listed languages all have Garbage Collection? It will probably take quite a bit of mental effort to get comfortable with memory management in Rust but it is a valuable topic if you want to understand performance and language runtimes.

[eska]

I've started learning it in March when the pandemic hit and I lost my job, so I had free time. I just started by making a side project, a static site generator of course. Now at my current job I was able to use Rust for an IoT data acquisition project, and feel like I'm more productive than I am with C++, which I have 20 years of experience with.

The other day the partner company which is using the output of my software admitted to me that they are chasing some weird heap corruption error in QtCore.dll, and therefore cannot hit a deadline.. I was relieved that this is a thing of the past for me now.

When I run into a memory error now, it's somewhere in the unsafe code blocks I have in the wrapper around the shitty C libraries by other partner companies, that didn't document the conditions of their API properly.

[jvanderbot]

I've enjoyed it, aside from my day job, as a way to learn some of the safety-first paradigms. I do think it will translate back to my work.

[skywal_l]

You can spend the time on it since you will make it up by not having to worry about your awful C++ dependency/build system which is the language targeted by rust to replace (/complement) ;)

[divtiwari]

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

[grumblenum]

If you consider GitHub to be a reasonable metric of industry practice in general, then judging by these charts [https://madnight.github.io/githut/#/pull_requests/2021/1], I would say that going mainstream in a couple years is not very likely at all. Tiobe [https://www.tiobe.com/tiobe-index/] paints a similar picture. The number of Rust-specific jobs advertisements also don't seem to suggest a coming wave that employers are trying to get ahead of[https://www.dice.com/jobs?q=rust&countryCode=US&radius=30&ra...]. I'm not aware of any real success stories with the language, either, unlike Go and the CNCF ecosystem that's the latest fashion right now. There are rewrites of GNU coreutils (ripgrep, bat), a couple components in already commercially successful software (Dropbox, Discord), a couple side-projects within large companies (fuschia OS, FirecrackerVM) and I guess terminal emulators are a big focus. You could say the same of Haskell, which is very cool, but is not going to be an industry standard in the foreseeable future.

One way to think about it is that the big wave of new languages like Go, Rust, Elixir and Kotlin all sprang up around 2010. At that time, C99, C++03, Java 6 or C#2 were probably what you would have been using (honorable mentions to Python 2.7, PHP 5, and Ruby 1.8). The new languages were perceived solutions to the limitations of the mainstream languages; however, today, very many of the new features and the old points of frustration have already been addressed within these same 'boring' mainstream languages. Java 16, C# 8, and C++20 are vastly improved and have (or will soon have [check out Loom for Java!]) almost all the conveniences the new-wave offered without having to throw old programs in the bin and reimplement entire ecosystems. C++ and Rust are also so similar in terms of semantics and memory model, that I really don't see the value proposition of walking away from huge, mature projects like Qt for academically interesting type algebra. There have been some ambitious fresh-takes on things like ECS-based game engines in Rust, but I'm not aware of impending migration to these tools.

[Nullabillity]

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.

[grumblenum]

Not breaking APIs is pretty considerate of your users.

[dexterlemmer]

Agreed. But it can also mean not actually achieving at all what you set out to do. I don't know if that is the case for Loom specifically, but that seems to be what was implied by the parent comment.

[dexterlemmer]

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.

[airhead969]

Don't unless it's to advance a particular career development or personal project goal. I left Go because it became a yuppie slum of trend-seekers riding a wave and leeching rather than contributing: blog hype and too many dumb support requests/questions. Making powerful languages too easy to get started without any understanding results in burdensome, low-signal distractions of maintainers and contributors.

This appears like it may happen with Rust but I hope it doesn't. It's a good thing it won't ever happen with Haskell, which is my warm safety-blanket should any particular language community implode.