There hasn’t been a single Rust job posting in the entire region of Denmark where I live in 2019, so it’s probably fair to say that almost no one uses it.
The main reason is many companies have a lot of C/C++ devs or other devs learned Rust, so they don't have to hire new Rust programmer. There are many places using Rust, you should check this out: https://www.rust-lang.org/production/users
That is the case here to some extent. Projects have been done in rust, but "rust programmer" isn't what we seek.
Jumping into rust for our major projects doesn't make sense. Existing code is largely C, with some assembly and C++, so rust would just add another language to the requirements.
To somebody who isn't already a rust expert, it isn't even clear that rust is good for the job. We like bitfields as L-values in C, without ugly macros or other wrappers. We like to be able to easily produce a small relocatable blob of binary executable code, such as a firmware image or boot loader. Speed and size matter to us. Sometimes we compile for weird targets such as ARMv4, Coldfire, 80286, and Xtensa.
C certainly isn't perfect. If rust had fewer limitations, that could be convincing. My wishlist is probably zero-priority, but FWIW: I'd like pass-by-value arrays, naked functions, easy ability to get things in place as desired (position independent or fixed) without a PLT or GOT, portable bitfield layout, specified calling conventions, computed goto, and other things that high-level programmers despise.
Rust 1.0 was released in 2015, and before that you'd have breaking changes every month that effectively made it unusable for anything but toy projects. So it's not even 5 years old really.
Besides a big target for Rust is the C and C++ world. On Hacker News in my experience you have a majority of commenters coming from the web world where no news in one year effectively means that the project is dead.
For us in the low level world "stable for 4 years" means "maybe we can start considering using it in production" and the lack of big buzz every other month is more a pro than a con. I'll take boring and reliable over shiny and breaks-every-other-year.
I've just started adding a new feature on a C project started in 2009. If I used Rust I'd want to know that my dev environment will still be usable in 2019. I think the commitment to stability will pay off eventually.
Agreed, Rust's "popularity" in production projects is a topic to be revisited circa 2025-2030.
My personal intuition is that it will have become a strong alternative to C++ by then, and Go will probably eat the other side of that (at the 'upwards' frontier of C++, before/underneath e.g. Python), which given a decade could result in maybe 25-30% of major C++ projects moving or with plans to Rust/Go. That would be a healthy balance of alternatives, a true victory for these mid/low-level contenders.
It's not like the bottom of the stack can be won the likes of Python or Js at 80-90% within a decade. Structurally, it simply cannot.
Though I would argue they are different demographics somewhat. Mobile app and mac developers I would argue keep up with the times much more aggressively compared to c/c++ developers I know.
D is in the same space, but it started off having a GC and that kind of caused it more problems that it was perhaps worth being in an almost system space. Recent work with different allocator patterns and adding the -betterC compiler flag, I think, may help D in the long run. However, I wouldn't be surprised if D never gets much more popular that it already is.
The other major competitors to Rust is Zig and Jai. Of course Jai has the problem of being unreleased at the moment (and its fate is tightly bound to Jon Blow).
There are also a few other languages attempting to make inroads in the space. For example, Odin and Kit.
Here's my take on it though. C and C++ will always have some sort of systemic problem because they are able to do too much. In order to be a system language AND also do everything that people want a system language to do (games, embedded, high performance) you need (I assert) to have rough edges and dangerous pit falls.
Rust will eventually beat C/C++ on making web browsers and similar technologies because that's what it was built to do. However, Rust probably won't be able to beat C/C++ in game development and total OS development (although it can probably be partially used for both). Enter Zig and Jai.
D and Go both compete with C/C++ in a space that was temporarily taken over to Java/C#. But in the long run may end up being ceded to something that's less than a managed language but more than a system language.
Ultimately I predict we'll see C/C++ slowly give way to a family of system languages that all hold different niches before finally becoming a relegated to legacy only. This could still take a few decades to complete. And if you look at newer versions of C++ it's possible that C and C++ may even evolve to hold a different niche than the wide series of domains that they used to hold onto so tightly.
I appreciate that you're trying to frame this as areas where all of these languages can be successful in these spaces, but for Rust in particular, this is an odd take:
"In order to be a system language AND also do everything that people want a system language to do (games, embedded, high performance) you need (I assert) to have rough edges and dangerous pit falls.
"Rust will eventually beat C/C++ on making web browsers and similar technologies because that's what it was built to do. However, Rust probably won't be able to beat C/C++ in game development and total OS development (although it can probably be partially used for both)."
Rust has all the necessary escape hatches (through unsafe) required for these spaces. There are people working in these spaces with Rust successfully, today. So, while, the other languages you mention might find success here as well, there is no reason (from a technical perspective) that Rust will not.
The caveat here is that some correct software architectures require littering so much "unsafe" in the code (due to incompatible safety models, not actual unsafe-ness) that it largely defeats the purpose, and a software architecture that lets you avoid most "unsafe" produces a worse product while requiring more lines of code to accomplish the same thing.
Rust will always leave plenty of room for C++ to the extent that it tacitly encourages suboptimal software architecture for some types of applications, such as database engines, that commonly rely on safety models Rust was not designed to express.
I do see Rust potentially replacing a lot of backend Java, eventually.
That's all or nothing thinking. Enough people do it that what you say will probably happen. Thing is, one can always use multiple tools to achieve their goal. Anything Rust's safety model can't handle might be done with a different model, analyzer, etc. One recommendation I keep at is using "unsafe" Rust, porting it to identical C, throwing every tool we have in C ecosystem at it, and port what passes back to Rust with safe wrappers if possible. Rust couldn't prove it safe, it's externally proven safe (or safe enough), and optionally has protections during interactions via wrappers. You get Rust's benefits on everything else you code in the app plus whatever you include that others manage to get past borrow checker.
I call this general concept Brute-Force Assurance where you just modify the form of a program to fit existing tools to get their benefits. Just throw every sound and/or complete analyzer plus a lot of test generators at it. Also, code in a way that helps those tools wherever possible. If one can't, then use them on a version designed for verification first to get the algorithm right, step it toward optimized version, equivalence tests, repeat, etc.
I'm glad you commented because this is what I wanted to say, but couldn't think of a good way to lead into it.
IIRC while Rust does allow you to switch up allocators, it doesn't let you mix and match your runtime with multiple allocators. (Each artifact can be linked with at most one allocator at a time.) There are applications where you want to have multiple allocation strategies for performance reasons.
Uniqueness is really useful for most applications, but there are times that you want data structures that allow multiple pointers to the same data. Having to do this in Rust is going to be a bigger chore than doing it in a language that doesn't support uniqueness.
It will be possible for Rust to still participate in these areas (especially because you can use Rust for only part of your project, so you can use it where you don't have allocation or nonuniqueness constraints in your problem space). However, other options are going to offer a better programmer experience.
> I do see Rust potentially replacing a lot of backend Java, eventually.
I'm not quite so sure. Rust can be a good fit for services that need to be very optimized for memory or CPU usage. Java brings so many other extremely important benefits like introspection, management, profiling, hot swapping, and being generally more productive due to the fact that it's a GC'd language. Not to mention the huge ecosystem behind it.
> such as database engines, that commonly rely on safety models Rust was not designed to express.
Do you think you could expand on this?
From my experience Rust facilitates all the same operations as either C or C++, and generally without even needing to turn to unsafe. What I've found in my own (not DB, but networking) work, is that Rust generally asks you to restate the problem in a way that will allow it to be best expressed in Rust. This often differs from the down the middle of the road implementations people have grown used to in other languages, but it doesn't in any meaningful way prevent you from solving the problem, in a safe way.
There's one escape hatch that Rust doesn't have: a hatch to escape its complexity. These days I do most of my programming in C++, and my first requirement from the language that will replace it for me is that it be simple rather than a shrine to accidental complexity. So I'm looking at Zig and liking what I see so far. I also think its approach to correctness is ultimately less disappointing than Rust's (as it is now) but that's a whole other discussion. Of course, these are personal preferences rather than some universal claims, although when I bet on a programming language I also care about future popularity, and complex languages tend to never gain more than small niche adoption. Anyway, Rust and Zig have such diametrically opposed design philosophies for low-level (AKA systems) programming, that it will be interesting to see their respective adoption dynamics. If, despite my prediction, Rust ends up being more popular, I'll probably prefer it to C++ and use it.
I'm a huge proponent of static typing systems. However, that being said, I always keep in mind that everything has a cost.
* Just because I'm more comfortable with types doesn't mean that everyone else is.
* Someone may want to do something in a type system which is well typed, but only in a different type system.
* Someone may want to do something in a a type system which is well typed, but which has some bad compilation characteristics for the given type system.
Even if Rust is objectively better, you still have to get used to the things about it that make it objectively better. And you have to keep up with the changes that are made to it. And you have to understand where those better things fail down (for example Non Lexical Lifetimes ... in which case you have to get used to the NLL acronym that people use).
A simpler language, even if objectively worse, can yield better results if it is used with discipline. Discipline that might be easier to hone with less things that need to be considered.
And sometimes better results don't actually matter because the goal isn't the best results tomorrow but reasonably adequate results today.
The syntax of Rust with all the different kind of references looks far too complex, just to get a performance improvement.
Garbage collectors provide memory safety without any special syntax.
Or in Delphi all strings are reference counted. They are mutable, if the ref count is 1, and immutable when it is larger than one. It is memory safe with safe aliasing and needs no special syntax.
A sufficient smart compiler could just optimize the reference counting away, and treat everything as immutable, unless it can prove there is no aliasing. Ideally, a language would only have two kinds of reference, mutable and constant, and everything is figured out by the compiler
Go folks seem pretty persistent in espousing this belief, but I've yet to see many examples of it in action.
Most of the fields where rust is making headway, it is making headway for precisely the things that Go is not known for - lack of a garbage collector, strict and expressive type system, robust generics, etc.
Hmm not really, Go is close to Python / Java / C# / C++, not much for PHP / Ruby, people didn't build backend services outside of the web in those languages.
Imagine one second Kubernetes, Docker or Prometheus those app have nothing to do with PHP / Ruby. It's related to C++ / Java.
Prometheus is the equivalent of what's at Google and it was built in C++. Same for all the DBs outhere in Go: CockroachDB, NATS, etcd ect ... those are C++ applications related.
Facebook, Ebay, Mercedes Benz and a few others[0] don't seem to believe so. Better tell them to use a different language?
I'm on a Discord for Dlang that's quite active honestly. The D community is plenty active. Their forums and IRC. Maybe not as active as other language communities, but it's not made by Mozilla or Google which gets a lot more attention.
Source: I worked at Facebook for four years. My first diff at Facebook was even in D, in a project that was already effectively abandoned by the time I changed it.
It's really a tiny, insignificant minority of actively running code there, possibly zero by now.
>Facebook, Ebay, Mercedes Benz and a few others[0] don't seem to believe so. Better tell them to use a different language?
The already "use a different language" for most of their stuff.
Their D use is tokenish, the way you can find any bizarro, niche language used somewhere big. That doesn't mean the language is in any kind of widespread use, just that some teams in some big company or another adopted it - as outliers.
It is competing for my attention and many others I guess.
> I'd call D a dead language. Can a dead language compete with a growing one?
I'm much more inclined to spend time with D than with a number of other popular languages if I could choose.
I don't know if I'm alone in this, but for what I know kt might become really popular in the future. (Look to Erlang for an example of a language that went unnoticed for a couple of decades or so.)
FWIW Rust is on top of my list of languages I want to master if I should get time.
D practionners aren't really on internet forums, let alone internet forums with a bias for whatever is new and status-enhancing (HN). Because the presumed attacks on D are constant, it's become very tiring to answer that no, it's not dead, and it's growing. The real test is in the trenches, not in a factless debate.
Rust by contrast is 16th and trending upwards year on year. So these D users that are missing from internet forums are also missing from checking in actual code.
You talk about the lack of facts, but I can link you to Stackoverflow's survey, Github's usage, Google Trends, and show you that D isn't doing very well. Where's your facts here? Where is this evidence of a large number of quiet D programmers?
I am not sure that there are any Rust job postings in Sweden either, but I know several people using it on their jobs anyway, e.g. people recruited as C++ developers who work in Rust. I think it is hard to see any trends in smaller languages from job postings since a lot of recruitment is done internally and through contacts.
There hasn’t been a single C++ job posting in the entire region of where I live in 1989, so it’s probably fair to say that almost no one uses it.
To me, Rust "feels" like one of those languages that will stealthily become very important at least in certain segments where security, performance, C ABI compatibility (dll/so/dylib) and zero runtime are required.
My point is that C++, Java, etc. got established long before the hiring patterns and keywords changed. The employers will just suddenly start to expect (language age + 1 year) experience.
I think same will happen to Rust.
> Rust is not very stealthy at all :)
Yet it might appear like that from corporate point of view.
Rust is a pretty niched language trying to replace C++ and similar that are quite slow moving, so it's gonna take time. Most jobs are after all related to web/services where Rust's strong points aren't as relevant.
Is Denmark on the cutting edge of these sorts of things? Many countries have enterprise companies that are heavily invested in Java/C# and maybe 3 startups using a bit of Go/Elixir in some places, but that's about it, it's not specific to Rust.
Denmark is doing pretty well if you look at the history and people of PLT. Probably #1 country in per capita terms. Hejlsberg, Bak, Lerdorf, Naur, Stroustrup, Troels Henriksen etc. (Denmark has less than 2% of the population of USA)
Sure, I am not discounting Denmark has smart computer scientists, nor that the U.S. has better ones, (I'm European myself), just that from my experience the European tech scene is slower on picking up the latest tech, (which is different from educational institutions).
And I know there are at least a few companies using rust to some extend in the capital region, there have been some talks about it at the monthly hacknight https://cph.rs
I don't know about that, Microsoft security analysis is in Rust, Google wrote an OS in rust, Mozilla firefox is mid-rewrite in rust, Linux is accepting rust work