I understand your perspective. I like to view niche languages as a medium for learning. For instance, I enjoy using Rust in my personal projects—even if many of these projects may never be released—because the lessons on immutability, functional programming constructs, and trait-oriented programming significantly enhance my day-to-day work. Therefore, I believe that learning niche languages, even in the absence of a robust job market, is worthwhile.
I'm not sure I'd call Rust a "niche language" any more (perhaps in ~2018) - it's in common use across many big technology companies.
It is extremely niche outside of this bubble.
According to Stack Overflow developer survey [0] Rust is at 12.5%, roughly a half of C# or Java and a quarter of Python. Also more than twice Ruby. So definitely not niche.
[0] https://survey.stackoverflow.co/2024/technology#most-popular...
To be clear, that developer survey asked:
> Which programming, scripting, and markup languages have you done extensive development work in over the past year, and which do you want to work in over the next year?
Also, in the same results, just above Rust, I see:
> PowerShell 13.8%
Powershell is probably more popular, it's used a lot for IT stuff so we never hear about it but it's there.
In my mind not niche means having jobs, and Rust has no jobs, not in any meaningful amount at least, and none at all in most countries. That puts it deep in the niche category for me.
It's popular in the "let's rewrite X in Rust" community which are very actively posting on HN, Reddit and wherever they can. That gives the impression it is not niche.
But the moment you search Rust on LinkedIn, you can see the truth.
> According to Stack Overflow developer survey [0] Rust is at 12.5%, ... So definitely not niche.
The annual survey is very popular in the Rust community. Its results are often used for advocacy. Participation by Rust developers is very high. So what you have is a classic case of a selection bias.
MS is starting to use Rust pretty extensively internally. That's a lot of developers outside the "bubble."
F# will likely remain niche forever. It’s likely that Rust will not given its growing and accelerating adoption by Microsoft, Google and the Linux Kernel.
It just takes time to defeat the 40+ years of c and c++ dominance.
Personally I will always prefer C's simplicity to Rust's complexity. Could be just me.
I find Rust vastly simpler than C. If the code compiles, it's probably a valid expression of the business logic I encoded. I might've screwed up that logic, of course, and no language can prevent me from messing that up. I know! Many have tried, and I've defeated them with my ability to misrepresent my ideas! But at least with Rust, I'm reasonably confident that the code will actually do the thing I asked it to do. I'm never confident like that with C until I've run it a few hundred times without crashing.
(Yes, I'm familiar with the rich ecosystem around helping devs not write crummy C. I worked at Coverity at one point. If anything, that gave me enormous fear and respect of the hoops you have to jump through to be reasonably sure C code isn't completely broken.)
This seems...a very contrarian sentiment. Imho while C might lead you to create slightly fragile code once in a while, Rust is something like two orders of magnitude more complex.
Rust is like two orders of magnitude more simple (if you're not going to delve into its darker corners).
You have a single line serialization into/from absolutely anything. You have logging, tracing, cli libraries, error handling - most of those are one liners.
You have enums. Enums are business logic. Enums are often the way the world works.
You press enter and it builds, no pre setups, sub modules, cmake files and whatnot.
No I know what he’s saying. C is not “slightly fragile code once in a while”. When you up the complexity of the code and the amount of code and the people working on the code the fragility becomes pervasive.
That's a huge part of it. If I stumble across random Rust code, I can assume that it's using typed data correctly, that it's not accessing freed memory, that it's not allocating but never freeing, that length checks are being enforced, etc. If they weren't, it wouldn't even compile (and the compiler would explain why).
Glancing at random C code tells you nothing about what happens with the data flowing into and out of it.
In my experience with it, rustc has been insistent on making me write code that's actually correct. I could translate that code back to C and have better C code than I would likely have written on my own. If there were something similar to `gcc -Werror -Weverything-rust-would-complain-about` — and if that thing were even possible — I very well might stick with C. Oh, and something as fast and ergonomic and informative as rust-analyzer would be hugely welcome.
Rust like any language can be as simple or as complex as you want it to be. The complexity raises with the performance of the code you write but that’s also true of C. Unlike C that complexity is combined with guarantees that your code won’t crash in weird and unpredictable ways.
I will take C, C++ or Zig over Rust any day. For some people, like me, the Rust way of doing things isn't a good fit. It's not a model I enjoy working with.
I like F#, Haskell, Elixir but not Rust.
Just look at the job market. There are far more jobs for Go programmers and Go isn't particularly huge.
Compared with C/C++, Java, C#, Javascript, Python, Typescript, PHP, all the rest can be considered niche.