Hacker News Reader

Comment by dragosmocrii | Hacker News Reader

I'm curious what people think about Rust as a long-term investment from an employment/job perspective. Is it going to pay the bills for the next 10 years? I've been using PHP for the past 10 years, and I've never run out of work. I can't say the same about Elixir, which I very much like, but the job market proved to be scarce. Just wondering what Rust's future looks like. Thanks for your opinions

A note(since I notice my comment is getting downvoted): I've actually been spending time regularly for the past few weeks reading multiple tutorials, and getting familiar with Rust's concepts, and I really like the language and I can see that a lot of work has been put into developing it. But my concern is that there are other languages as well that have a solid background (OCaml, Haskell, to name a few), but that are still niche languages and suffer from the same scarce job market opportunities. Which proves that adoption does not always depend on how good a language is.

View on HN

Disclaimer: Embedded dev here, working with 8, 16 and 32 Bit microcontrollers. Almost exclusively C.

In Europe (and especially in Germany where I live) I don't see myself writing Rust in my day job for years to come (already twenty years in). Not because it's technically impossible or Rust is inferior, but simply because it seems to take decades for european/german companies to accept or at least try new ways of doing things.

Mind you, I'm not talking about startups (we don't have THAT many in Europe/Germany in the first place). Also, those are (mostly) web stuff companies.

Warning, unpopular opinion following.

I think HN is not the right place to ask this question. You will find a dev crowd here that is nothing like the big, quiet dev community out there in the real world. Most people here love trying new things (languages, frameworks, you name it I've tried it).

So don't base your conclusions on those answers alone. Talk to regular devs (those who say "Hackers News? Never heard of it."). Because those people set what will be used in companies.

EDIT: Corrected spelling of quiet.

> (those who say "Hackers News? Never heard of it.")

"learn to administer microsoft tools, like active directory and exchange."

Or SAP and any other ERP, or Salesforce and any other CRM, or any other kind of enterprise or banking software (Java, .NET, C++), VBA and "small" internal applications.

Probably 60-80%+ of the software developers and sysadmins out there :-)

I'm leading the software team at Northvolt Systems AB. Half the team is composed of embedded software engineers. We are currently using C to develop our battery management system. But I definitely think Rust as a bright future for that kind of application. The reason why is because functional safety is a major concern in battery systems. And it's really hard to achieve this in C, for the same reasons it's hard to write secure C code. The main obstacle to Rust adoption in embedded systems with functional safety requirements is that the toolchain is not qualified according to the functional safety standards we have to follow. If we could have something like the Arm Compiler for Functional Safety, but for Rust, then I think we could start using it. I'd be really interested to investigate this, in collaboration with other teams sharing that interest.

https://developer.arm.com/tools-and-software/embedded/arm-co...

Someone is already working on this apparently: https://ferrous-systems.com/ferrocene/

Also, since it was raised above: this company is based in Berlin :)

I can only fully agree on this.

In my specific case it would already be enough if the the two big ones (Keil & IAR) would provide a compiler.

If this obstacle vanished, the situation would be totally different here.

ARM should jump on the opportunity and support Rust in their qualified toolchain. (Since LLVM can target ARM)

A friend of mine uses Rust at Alstom. He wasn't the one who pushed for it.

I am not sure about what you said. Big companies are risk-averse, but that could play in Rust's favor. Some employees who are a few years short of retirement might push back on it, though.

Peek & Cloppenburg was looking for C++ devs with Rust being a plus point for their NRW sites, a couple of months ago,

So at least some German companies are slowly looking into it.

However I fully agree with your post.

I've been "a rust dev" for 4 years, and I honestly can't see Rust not becoming a majorly used language. It's just so _nice_ to use. And I don't mean just "write" also mean "refactor" and "read" which honestly have been some of the hardest things to do in C (the last major language I, I dunno, specialized in(?)). Between the compiler pointing out when you're too sleep deprived to be writing what you're writing or the general "write what you mean, even if it takes a few more keystrokes and the compiler yelling at you a time or two" attitude that seems to pervade the rust community, it's just a nice language to continue to develop in.

Which, again, this is maybe self-serving, but it really feels like a incredibly good long-term investment to learn. Even if you don't end up using it professionally (somehow) the compiler teaches you how to write better low level code.

I just got done cowboy coding 2500 lines of unchecked input validation code in Rust. While I didn’t particularly enjoy writing Rust — the syntax has taken some getting used to — I also don’t expect to enjoy writing anything in the domain of C or C++. What I did enjoy was correcting the hundreds of errors which had accumulated over the course of several days without checking the code at all, thanks in large part to rust-analyzer and VSCode.

On the cmdline, rustc displays gorgeous error messages — easily the best compiler error messages I’ve seen from any programming language — and Cargo is a dependency manager and build tool without equal. The Rust ecosystem in general is already quite large. Although I’m a neophyte at coding Rust, I haven’t run into an error message yet that StackOverflow or Reddit didn’t end up resolving.

On paper, Rust saves companies money by eliminating the memory safety bugs which would otherwise show up in C/C++ code. At the same time, Rust’s developer tooling ends up being so ergonomic to work with, and the language sufficiently expressive and flexible, that I can see Rust competing in areas beyond those reserved for C/C++.

IMO Rust is basically OCaml for the 21st century. My bet is on Rust usurping C/C++, and I expect Rust’s rise will be nothing short of meteoric over the coming years. The involvement of Facebook, Amazon, Microsoft and Google in the Rust Foundation bodes particularly well for this, as do informal surveys of developers which consistently show tremendous grassroots enthusiasm for the language. Just my 2c: but bet on Rust, bet heavily on Rust, and bet on Rust immediately, without delay.

It still misses the OCaml compile times, though.

I've never thought of myself as a C++ dev (or a PHP dev, or Rust dev, or Haskell dev).

I write computer programs. I don't "invest" in a language and only take jobs that use that language.

Learning more languages is almost always good. Not because you're learning more languages, but because you're learning more modes of thinking which will apply to any future language you learn.

I agree but many job postings contain stuff like "3+ years of professional experience in language x".

Yes but with time you gain experience in one or more languages and you can choose a job with the ones you like (or tolerate more). You don't need to pick or specialize one to apply for this kind of postings.

Honestly as someone (on the team) hiring for a job where someone else wrote the job posting, ignore the number. Just read that as "do you think you enjoy maintaining a codebase written in X".

Job postings are the fucking worst.

I've never actually found that to be enforced. None of my jobs have shared a tech stack, all of them have included such language. YMMV of course.

They don't enforce the number of years, but they could ask you quite deep questions about the language.

Even if you're a senior Python/Javascript developer, with experience in C# in the past, etc., if they start grilling you about Ruby, you probably won't prove that you're as equally productive as a similarly smart dev that is an actual senior Ruby dev.

I think your statement implies that you and I do not agree at a very fundamental level.

I'm saying that the world is a big place.

I agree in the abstract, but Rust is a step-function improvement compared to most other mainstream languages. It is hard to go back to writing, say, C or C++ once you have a few years of Rust experience—not because you've lost competence in them but because Rust offloads most of the complexity onto the compiler in a way that's simply not possible with older languages. You really start leaning on the affine types, the compile-time mutability xor aliasing checks, the pervasive checking of thread-safety...

> It is hard to go back to writing, say, C or C++ once you have a few years of Rust experience ... You really start leaning on the affine types, the compile-time mutability xor aliasing checks, the pervasive checking of thread-safety...

C++ has semi-official Core Guidelines issued by prominent members of the ISO-WG21 standard committee, that describe how to express these things idiomatically. Of course Rust can actually check these things automatically and achieve something close to actual memory safety, but there are ways to at least make a meaningful effort in C++.

The Core Guidelines are great, but don’t attempt to go as far as Rust.

Microsoft and Google are taking care it does.

I would watch the upcoming VC++ static analysis talk regarding its progress.

https://visualstudio.microsoft.com/de/pure-virtual-cpp-event...

I have been following such efforts (esp. of MS) in C++ for years - progress is so slow. Feels like a slug that halfs it's speed regularly and thus will never arrive at the finish line

Me too, however I am the opinion that I rather having something that improves the status quo than nothing at all, specially because there are millions of C and C++ lines of code that no matter what will never be rewritten.

I will consider Microsoft is fully into Rust when Azure Sphere supports Rust instead of being a C only SDK, despite its security marketing.

https://techcommunity.microsoft.com/t5/internet-of-things/de...

The first step in reducing those 70% is to actually use the tools that exist, but unfortunelly the macho attitute is still quite prevalent.

https://isocpp.org/files/papers/CppDevSurvey-2021-04-summary...

Those that are open to embrace Rust, are most likely already using static analyzers.

I don’t know what specifically you mean by “it does” but if you mean “goes as far as Rust,” that’s simply not true. It’s never even been a goal of the project.

Indeed, the goal has been to be as close as possible to Rust, given the constraints of C++ semantics.

Note I mean the work being done by Microsoft and Google on top of Core Guidelines on their syntac analysers, which on Microsoft's case are active by default as background process that validate your code as you type.

It will never be as good as Rust is able to, but in some domains a "worse is better" solution will already be better than nothing, because they aren't going to port their code to something else.

The key part is "Rust offloads most of the complexity onto the compiler".

Yes you can make a meaningful effort in C++, but one of the great benefits of Rust is that effort is handled by the compiler instead.

The burden isn't all that great, as most good C++ code ends up looking like how you'd write the Rust code anyways.

New C++ code that your team has written, sure. What about all the libraries that you integrate with, that all have different models for allocating/using/freeing buffers? Or system APIs? (At best for those you can build a wrapper layer, and the wrapper layer is subject to the same errors as C/C++ classically is.)

One of the things that struck me as a major advantage about Java and garbage collected languages is that you can simply combine code from different libraries without worrying about what's freeing the objects, because that's the GC's job. With Rust, the memory management model takes over this responsibility without runtime cost (or minimal cost -- perhaps freeing something from the heap, if you allocated it there, but definitely not GC).

With C++, unless the library that you're using is using the same smart point library as you, from the same language version, then aren't you stuck writing wrappers around the libs you want to use?

Types like std::async seem to have changed in every recent revision of C++ version (11, 17, 20). Can you reliably find multiple open source libraries that you could integrate into a codebase that uses futures and async/await?

(It's been a long time since I've done much C++ professionally. I'm asking skeptically but genuinely.)

While true, I don't need to rewrite those libraries and can just use them rigth away, and this is why C++ keeps being my to-go language for native libraries, despite some of its flaws.

I can spend all my development budget on the problem instead sacrificing part of it to building an ecosystem.

Yeah, but that's a losing race. Considering how much investment is happening with Rust right now (when Amazon, Facebook, Google, Microsoft, a ton of smaller companies are investing), Rust will become "good enough™" at some point.

I'd imagine that we're at most 3 years away from it having mature libraries for 99% of tasks you'd want to do as a professional developer.

C++ has hardly replaced C in some domains after 40 years trying, and it is mostly compatible with C at source level, build exactly to fit into existing C toolchains.

Some of those companies, like Google, Microsoft and NVidia, are heavily invested into C++, ISO C++ and selling C++ based products.

To use a common example that one puts against any technology that Microsoft touches, when will Office use Rust on its foundation and extension APIs?

Are you aware that Apple has rather created their own safe C dialect for iBoot firmware instead of using Rust?

A big company can push forward on many fronts in parallel :-)

Indeed, as long as it makes sense in the long run.

If we can have Singularity/Midori back, with a microkernel in Rust, it would be quite nice, but yeah, I guess that is more of wishful thinking.

Sure, they end up looking similar, but the point is that with C++ the developer carries the burden of making sure everything is correct and doesn't prevent you or other developers from breaking outside the bounds of what is "good" - either on purpose, or accidentally, e.g. when refactoring.

With Rust, the burden of checking all of that is shifted to the compiler, and that reduces cognitive load for the developer.

While Rust is a big help regarding memory corruption errors, you still need to watch out for the remaining 30%.

Rust is not a panacea for all bugs, but making memory problems and data races a compile time problem rather than a runtime problem is a significant benefit.

Indeed, and if that is what makes the industry rediscover Ada and Modula-2, more the better, however care need to be taken how it is sold, and also be understood this is going to take several decades.

Anyone that cares about memory safety for userspace applications has already moved on into other languages, the problem is the foundation and those that resist no matter what.

Also the data races prevented by Rust type system only apply to multihreaded code accessing in-memory data structures, there plenty of other data races in multiprocessing scenarios.

Your “only” clause captures the entire definition of data race - compared to the broader category of race conditions [0]

Safe rust prevents data races at compile time. It doesn’t prevent other race conditions.

And “only” preventing data races, is still a non-trivial achievement!

0: https://blog.regehr.org/archives/490

No need for the exclamation point.

Yes it is a non-trivial achievement, just I get the feeling that the advocacy for it tends to forget about the other ones.

By the way, John Regehr's example won't work if the transferXXX functions are using SQL statements without transactions across threads each with its own connection, instead of in-memory variables.

> Learning more languages is almost always good

Learning for the sake of learning and betting on it for employment and professional use are very different beasts.

Learning a language in depth along with its extensive standard library can buy you months or even years of expertise. This is especially true in languages like C++ (a language with massive depth, such as template metaprogramming) or C# (a language with a massive set of libraries, ASP.NET alone can take years to truly master).

This is what companies are paying big bucks for, immediate competency and productivity.

The extensive standard library and the big libraries or frameworks that are the gold standards for their niches, in that language's ecosystem.

For example Hibernate for Java ORM, Spring as the big Java "LEGO brick bucket", Rail for Ruby web development, etc.

If you ever need to work with PHP, use PHP/Hack developed by Facebook: https://hacklang.org/

It's a compiled language built partially in Rust, being rewritten entirely in Rust, JIT compiled using HHVM: https://hhvm.com/

I don't believe it's compatible with existing PHP codebases, but you could probably convert one over, catching safety issues while you did it.

Hack a modern and highly productive language that's in many ways as nearly sophisticated as Rust. (How many other languages have both opaque and transparent type aliases, for example? https://docs.hhvm.com/hack/types/type-aliases ). It has a mature async/await system, for another example. One feature it's missing is the macro system that Rust has, though.

Rust has been picked up at Amazon, Google, Facebook and Microsoft. I think that gravitational pull is going to keep Rust a going concern for a long time.

That being said, it's an investment in the future mostly. There aren't anywhere near as many Rust jobs as PHP, Java, or Python jobs.

Rust at Google is in a bit of an awkward state. There's a bunch of teams/projects that have used it, but we haven't yet staffed a team to manage an internal Rust toolchain/ecosystem.

The most recent one was Kotlin, in large part because our Android ecosystem was increasingly having to play catch up, so we'll see if/when a Rust team gets staffed.

While it has been picked at Microsoft, its relevance on the Windows developer eco-system is quite tiny.

It remains to be seen when it will even have a place on VS installer.

Rust has been adopted by multiple teams at Palantir. The bootstrap launcher for Palantir's ancient government software was rewritten in Rust to avoid having to ship Java 6. And some small piece of the custom software that Palantir wrote for BP to manage oil wells was written in Rust, because the single dev on the project was also a maintainer of some Rust crates and could get away with it.

As a long term investment, I think it'll be great. I expect it'll be another 5-10 years before it's as employable as C++, but it'll last at least another 20 beyond that.

Once/if it reaches that point, and considering its main niche (systems software), it will outlive roaches.

I don't personally write Rust for a living, but it's a chicken and egg problem.

The industry wants to start using it but can't find dev with commercial x years experience to have the confidence to invest in it and the developers can't get professional experience because they can't find a job in rustland yet.

This doesn't happen in PHP due to the age and spread of the language (for better or worse).

So I think it's a timing issue. If the language is solid and solves a problem uniquely and is well received where it is used (and not just some freak example in a company somewhere with a blog post "we use this and it's the best!") - it will pierce through after X years.

I believe that Rust is positioned to be the Next Big Language for server-side and application programming, taking over for C/C++/Java.

I'm not sure if there's a .NET-compatible implementation or interop but it'd likely take over C# as well if so, if Microsoft decides to invest in it. They have pretty good languages like F# already but Rust is designed around zero-cost abstractions and avoids the garbage collection penalty that comes with running on the JVM or .NET.

Rust offers performance, type safety, memory safety, and metaprogramming that are provided by few other (largely academic) languages, while permitting multiple programming styles and escapes from those restrictions when you need them.

On the other hand, I don't think the Web-oriented languages will go away unless someone develops a variant of Rust or Rust framework intended for building websites. However, for everything else that's not running inside a web page or supplying the content in a web server, I think we'll see a gradual transition to Rust; the web server will be in Rust; the JavaScript compiler will be in Rust; the browser will eventually be in Rust; and so on.

I've been feeling this way as well. I think it all comes down to whether the ecosystem can be built up enough where your average developer can be productive without feeling like they're fighting the language or trying to figure out which smart pointer they need to use in which situation. Obviously those issues will still exist but could likely be mitigated if enough work is put into the ecosystem

So what will be the security flaws we will see in Rust-based software in the future? Seems like there are still many kinds of flaws that no language can prevent.

It won't replace JVM/CLR. Rust community is pretty against GC and even though lifetimes are wayyyy better than C memory management they're not nearly as convenient as GC.

If Rust ever gets a good GC it might very well replace VM languages. But even if they started now, it would take years.

Rust also has long compile times. Java and C# projects, even huge ones, build in a couple seconds because compilation is done in JIT. Go is AOT but sacrifices some performance for fast compilation too. It's important for a general purpose language where performance is not #1 concern but maybe #2 or #3. Same story as GC. Sacrifice a small amount of performance for convenience. That's not what Rust is designed for.

Rust is positioned as a systems language to replace C dialects and it that I think it will be wildly successful

From a long term perspective I'm not worried but short to mid term it might cause some issues because currently there aren't that many Rust jobs yet. It's kind of a niche still, jobs wise.

Thank you, this is reassuring!

I think outside the domains of kernel and driver programming, eventually game development, it doesn't make much sense switching to Rust for userspace application development.

That domain is already more than coverered with languages offering AOT/JIT compilers, managed memory (in whatever form), very nice tooling and ecosystems with libraries for about anything.

It’s a big pivot from php in terms of the level of the stack it’s targeting. That’s not necessarily a bad thing but keep in mind that there’s a bunch of associated skills, knowledge, and even culture that differ in web dev vs. for example distributed systems.

Probably depends on what you want to be doing

Do you want to work in systems, embedded, etc? Rust is almost certainly (at least a large part of) the future

Web servers (at the application level)/native apps/games? It's gotten some traction, but the jury is still out

Rust is rather painful compared to alternative choices for web servers today. I’ve had to write 10x the code in some circumstances for the same result and I find it becomes hard to reason when you have several async types.

However, it has attributes that match it extremely well with function as a service where memory usage, cold start times, consistent execution, and compute costs are major factors.

It’s extremely well suited to that environment. I expect to see it thrive here once some aspects of rust settle down further.

Yeah, the web framework situation is also just fairly early right now. Rocket looks promising but it's not at 1.0 yet, and the current release still requires the nightly compiler. It does a whole lot to improve the ergonomics, but even then it's not as easy as Python or Go. So it depends on the usecase.

The good news is that the microservices trend makes it easy to optimize the "hot services" with a different language than what you use to throw together all your normal services.

I wouldn't call it as "easy" as Python or Go but I've been writing production services off the Rocket master branch (all async and compiles on stable rust but the API itself is rather unstable) for the last few months and it's been easily as productive as Django (sans ORM & django-admin integration). 80-90% of my logic is in request guard implementations and diesel types/helpers which get reused all over the place, making the controller logic trivially simple. Reimplementing most of the bells and whistles took less time than trying to decipher Django's magic anytime it goes wrong.

Rocket's DI and middleware layer with serde, validator, Rust's error handling, etc really take the pain out of the whole affair. That said I wouldn't recommend it until the ecosystem matures and stabilizes unless you really like updating lifetimes all over rocket libraries every few months.

>Rust is almost certainly (at least a large part of) the future

Can you name any design wins for Rust in a product's embedded SW, embedded OS, or device drivers? I've never seen it in the wild. How does Rust deal with hard RT?

I'd be interested to see what people had to say.

I have very little direct experience with embedded but I've heard several people talk about having a good experience using Rust for it. It's not hard for me to imagine memory safety without a runtime being pretty useful in that context, if nothing else. That said, I know embedded moves slower than a lot of other areas so maybe "the future" is farther out in that case.

I haven't written anything in rust, but RTIC seems like it might be roughly equivalent to a project like FreeRTOS https://crates.io/crates/cortex-m-rtic

There does seem to be a lot of people who are very excited about the potential for Rust as a replacement for C/C++ in the embedded space.

There is "Working Group" dedicated to the domain: https://www.rust-lang.org/what/embedded & https://blog.rust-embedded.org/newsletter-28/

Toward the bottom of the page there's a "Production use" section with some quotes from people @ companies using it.

There's also an Embedded Rust "book": https://docs.rust-embedded.org/book/

In addition to the language itself, the surrounding tooling (e.g. for package management) contributes to the potential wins available from to moving to Rust.

My impression is that there are still areas where there isn't yet an idiomatic solution as to how _best_ to represent certain embedded SW concepts in a way that allows Rust's guarantees to be maintained. So I think there's some churn around that as people experiment/learn. (Primarily in relation to some of the physical constraints of the hardware.)

One of the companies prominent in the Rust embedded space is Ferrous Systems: https://ferrous-systems.com/

While it's still early days, relatively speaking, I think a lot of people see a move to Rust as a "once in a generation" opportunity to finally move on from an embedded ecosystem built on substandard vendor C toolchains & also gain from the robustness/safety that Rust offers.

In a lot of ways the embedded domain stands to gain even more from what Rust offers because unlike, say, the desktop/server space there isn't another higher level language that's really an option.

I'm fairly early in my Rust learning journey but have played a bit with it on an STM32F7 dev board. But so far have spent more time on non-embedded side of things.

(Although one of the appealing aspects of Rust for me is that I can use the language on platforms ranging from embedded to server/desktop to the browser (via WebAssembly). And the knowledge is transferable & even a lot of the library support too--thanks to "no_std" packages/crates that have reduced overhead.)

As an aside, while learning off & on over an extended period of time, I've found this post really helpful for (re-)learning how to read Rust: https://fasterthanli.me/articles/a-half-hour-to-learn-rust

The post aims to go "through as many Rust snippets as I can, and explain what the keywords and symbols they contain mean" which I've found a useful approach.

Also, this post has some useful feedback on experience/lessons from using Rust in production in the embedded space: https://old.reddit.com/r/rust/comments/hkjn6f/rust_in_embedd...

With niche programming languages, I think the thing is to embrace the niche rather than try to go the traditional way.

We could be an outlier, but if there are enough D jobs going around (Often very well compensated), you shouldn't have a problem with Rust.

If you get proficient in a technology, you'll be employable regardless of the market size or niche. There's always demand for specialists.

On the other hand if you're more of a generalist, I'd say stay with popular technologies such as Python, JVM and .NET. You can't go wrong with any of these for the next 20 years.

PHP has been making strides lately with JIT, Laravel and proposals for generics. So staying on it shouldn't prove a bad choice either. But if you're looking for greener pastures while maintaining great employability, my personal bet for the next decades is .NET/C#. And it tends to pay more than PHP on average.

As someone that's forced to write C occasionally Rust is a godsend. I prefer high level languages but when I need the performance it's nice to have something that doesn't feel like it's from the 80's.

C is extremely painful. C++ is a shitshow. Rust is glorious in comparison.

Rust, or something like it, will definitely replace C/C++ someday. And rust has way more traction than anything else

Yes and no.

If Rust got a much larger adaption, then there will be many more people learning it then Rust skill is hardly a special thing.

If not, a less-adapted language will never pay you with the top market rate since it is not used by most people.

So what really matter is the size of total programmer market.

> I'm curious what people think about Rust as a long-term investment from an employment/job perspective. Is it going to pay the bills for the next 10 years?

The answer is almost certainly: no.

From a career standpoint, you would be better off learning C/C++ in much more detail before investing time in Rust.

If you want the "canary in the coal mine", watch what the game developers use for the game engines (they mostly use C++ right now). When Rust starts becoming common among game developers, it's got enough momentum for a job ("career" is probably a bit much).

However, even when Rust hits critical mass, it's unlikely to be a "career choice" programming language--you will have to know Rust AND <something else more important>. The world has changed, and "One Language To Rule Them All" is no longer a thing.

C, Java, Python, C++, Javascript, C# are going to hold the top 5 of programming languages for the conceivable future. Not matter how good Rust is it is not going to displace C and C++ on any reasonable timescale--inertia is a thing. Swift and Visual Basic have their niche and nothing is going to blast them out of it.

After that, it's pretty much a free-for-all in terms of language popularity, but everything is tiny at that point.

> If you want the "canary in the coal mine", watch what the game developers use for the game engines (they mostly use C++ right now). When Rust starts becoming common among game developers, it's got enough momentum for a job ("career" is probably a bit much).

I don't see why the entertainment industry would be any more important to pay attention to than any other tech-adjacent industry, such as finance, health care, transportation, etc. If anything, the short-term focus on the next title means that the games industry tends to be relatively late adopters of experimental core tech: witness how more quickly tech companies adopted C++11 as compared to game studios, for example. (This is not to criticize entertainment's conservatism with technology choices: it's a tough business and they are understandably risk-averse.)

game programming is performance heavy, while other tech-adjacent industry may be requirements-driven. Also, C++ has existed for what? 30 years? t

Finance is performance critical too, just to name one. Games are just one small part of the high performance systems space.

Finance is performance heavy in very, very, very narrow points--and NO programming language cuts it in that spot. Those firms use custom silicon.

The vast majority of "programming" in finance is finding something to model that is relevant. And that's Python, R, Julia, etc.--all the exploratory tools. Nobody in that space has even heard of Rust.

There's a lot of C++ in financial/trading: custom silicon is only used for the most rudimentary/simple/rote part of the system (think like packet parsing or templating your messages you send to the exchange).

Many people are very interested in Rust right now for HFT: C++ is nothing but pain and causes tons of problems.

> I don't see why the entertainment industry would be any more important to pay attention to than any other tech-adjacent industry, such as finance, health care, transportation, etc. If anything, the short-term focus on the next title means that the games industry tends to be relatively late adopters of experimental core tech

Um, precisely?

Game programming is hardware-bound and short-term focused. Consequently, if Rust is generally superior to C/C++, it will spread very quickly. This would be especially true in games that have a much higher networking component (where the memory and security guarantees start to matter more than just the raw engine performance).

Rust is a systems programming language. It is meant to extract efficiency/performance out of hardware. If that isn't your raison d'être, then using a systems programming language of any flavor is counterproductive.

So, the problem is that Rust doesn't really compete in "general programming"--it competes mostly in "systems programming". And it has to displace competitors that are mostly "good enough". And it can be done piecemeal so that you don't have to port entire codebases all at once.

None of that is a recipe for fast change. And THAT'S PERFECTLY OKAY.

Now, all that having been said, the wildcard in all of this is WASM. Rust support for WASM has been stellar when everybody else's has been hot garbage. WASM could be the thing that lets Rust break out of just the "systems programming" niche. That's a big hypothetical, though.

> the wildcard in all of this is WASM.

On a related note, Embark Studios who I mentioned above, just announced they've joined the Bytecode Alliance, an WebAssembly-focused non-profit: https://twitter.com/repi/status/1387393289847025669

The announcement mentioned the use of WASM to help build "...a future of software & creative game worlds that are not limited walled gardens where only we / the devs can add new capabilities or features, want to build an open ecosystem of interconnected software & game components that anyone can use & create with".

Essentially, Rust+WASM as a future for player-driven modding/customisation.

This is an area I've been exploring in my "WebAssembly Calling Card" project which enables people to create cross-platform personalized dynamic image avatars implemented in any language which can compile to WASM: https://wacc.rancidbacon.com

I've integrated WACC with the Godot game engine, Rust GUI viewers and the browser--they all use the same avatar ".wasm" file (with examples currently written in C & Rust).

Neat!

I'm happy to see all of this, but, again, the question was about career in/for 10 years. And Rust just isn't going to be that.

Rust is, for example, far behind in terms of market penetration where Python was at a comparable age. This is unsurprising. First, Rust is nowhere near as broad spectrum as Python--so it's domain of applicability is much more constrained. Second, Rust is coming into a full ecosystem that Python didn't have to contend with.

Python was basically the only respectable person at the scripting language job interview in the late 1990s--Tcl and Perl both decided to start huffing glue in the middle of the DotBomb era while Sun tried to jam Java everywhere it didn't belong and left a lot of greenfield areas to Python. Rust doesn't have the "advantage" of that level of incompetence in its competitors/alternatives.

And, while I'm fully aware that Python and Rust aren't really in the same space, I simply chose Python because it's one of the only popular languages that is relatively "new" (if you can call something from somewhere in 1989-1994 "new") and didn't come upon its popularity as a mandated parasite attached to a much bigger host (looking at you: Swift/C#/Javascript).

> If you want the "canary in the coal mine", watch what the game developers use for the game engines

On this front two relevant data points are:

* Embark Studios: https://medium.com/embarkstudios/inside-rust-at-embark-b82c0...

* Ready at Dawn Founder/CTO: https://twitter.com/AndreaPessino/status/1021532074153394176

Also, there is a specific Rust GameDev Working Group: https://www.rust-lang.org/governance/wgs/gamedev

How relevant are these data points though? Embark Studios e.g. appears to be some small company in Sweden (?), doing 3-4 different things (aside from games) to get by.

You can find all kinds of languages in game shops, including custom Lisps and the like, so finding Rust too is a given.

But I think the spirit of the parent was to check what game studios start adopting "en masse", not whether this or that studio has adopted a language.

> How relevant are these data points though?

Depends on who you are I guess. :)

> appears to be some small company in Sweden

According to[0] they're currently around 200 employees and the founding team includes former CEO of DICE (+ex-EA) & other experienced industry people.

They're funded in the large tens of millions range: https://www.pcgamesinsider.biz/news/69461/nexon-increases-st...

So, basically, they're a bunch of experienced game industry veterans funded with a bunch of money & a clean slate to choose their technologies--and have made Rust as one of their prime choices. (Although I note they're using Unreal for their 1st game, so not sure how much of the Unreal-related dev they'll be doing in Rust.)

> doing 3-4 different things (aside from games) to get by.

Curious what gave you that impression?

[0] https://medium.com/embarkstudios/our-continued-journey-89dad...

Take a look at the Embark jobs.

C++, C++, C++, C++, C++, C++, Rust (for security), (Go, JavaScript, Python and Rust).

The Rust stuff is all confined to the back end where security matters--no engine stuff.

Ready At Dawn got bought, so it would be interesting to know if that still holds as they are owned by Facebook who is Rust-positive.

Reply on news.ycombinator.com