There are many MCUs that run Linux but definitely are incapable of compiling it.
IIRC most of the build time of a rust program is spent not in the rust compilation proper but in LLVM doing code generation and optimization. I hope both LLVM will become more efficient with time, and rust will learn to pass it such IR that it can process faster. There are obvious incentives for both of these things.
But of course it would be sad if the minimum requirements to compile the kernel grew again, and now excluded older RPis.
I find it would be very difficult to convince anyone to use any other OS than the currently mainstream ones. You should instead see this as an accomplishment of what Rust can achieve.
I also think you are undermining Redox OS developers efforts, which is kinda sad.
>Rust code is guaranteed to be fast and guaranteed to be bug free
Nobody claimed this, what people claim is that it can be as fast as C, and it has some safety guarantees. You can still have bugs.
>Rust is for writing blog posts...
What's so wrong about people being excited about something? Personally I find it awesome that a programming language can bring so much enthusiasm to people. In my opinion, what you are seeing here is people being excited about progress being made.
>the compiler authors so wonderful and smart
I sense some envy here, people achieved a great thing through effort and collaboration, we should celebrate this.
My full time job is writing Rust for large-scale production systems. The language is great - and as an organization we're doubling down on our investment in Rust this year.
As for purpose, there’s this blog post [0]:
> At this point, Discord is using Rust in many places across its software stack. We use it for the game SDK, video capturing and encoding for Go Live, Elixir NIFs, several backend services, and more.
[0]: https://blog.discord.com/why-discord-is-switching-from-go-to...
So you would rather believe in a ridiculous conspiracy than admit that large companies might just be choosing Rust for some valid reasons. Got it.
A small company that has become a success based on a whole XYZ stack may count for something, depending on how ambitious the company was, how hard it was to do, and how much competition they face. Lots of companies could succeed equally well with Rust, JS, Java, C#, Kotlin, Python, Ruby, Erlang, or Perl; those successes don't count. Lots more potter along, neither succeeding nor failing, exactly. Those don't count either, unless you want to give Rust credit for their not exactly failing.
And, many fail. We are never told about those. They might well count, but there are a lot of ways to fail.
It is ridiculous to believe in a Google conspiracy to outcompete Linux by getting it to incorporate Rust, because a conspiracy requires a crime, and that would not be one. But anyway Google doesn't have that much influence.
Secondly, there is a huge difference between a language being used in general and a language being used for serious, visible projects within a company. Think: writing a small utility in Zig at company X vs. rewriting the backend of a core product in Zig and pointing to measurable gains in performance and reliability.
> It is ridiculous to believe in a Google conspiracy to outcompete Linux by getting it to incorporate Rust [..]
Great, but you should be telling that to the user I was replying to.
Similarly: you then agree that "BigCo uses XYZ" is, in fact, not compelling. A big company betting its future on XYZ would count, but no big company does that. Betting a substantial new business unit on XYZ could count, but that is not cited as "BigCo uses XYZ", that is "BigCo relies on XYZ for UnitX to succeed", a possibly stronger statement, according as how important UnitX is to BigCo.
Calling a claim ridiculous needs reasons why it is ridiculous, which I supplied, and you did not.
It's like surfing. Some people want to see hundreds of surfers on the wave before they start paddling out. That's fine. There's nothing wrong with that. But I personally believe that a better way to surf, especially when it comes to technology which tends to have short cycles, is to learn how to spot the wave as it builds, while it's still a swell, before it breaks. I've seen time and again that there's incredible value to be had if you can learn how to do that.
One of the best examples of this value being that you're able to hire really talented people, because they form the critical mass at the beginning of a successful wave. Once the larger corporates come in, this advantage disappears.
I definitely agree with the notion that the early adopter group is more often than not more talented than average. But, I'm sure companies also take this into account when deciding whether or not to pick a new technology.
"If the definition ends up aligning with what large companies look for when adopting a new technology, then the signal ends up being the same."
And even then, the signal is only the same, but it's not worse. Whereas if large companies don't always optimize for quality, but have other incentives at play, or if they are less nimble, or less efficient, then looking for what large companies look for might actually end up setting you back with worse signal. So there's no upside I think.
A notable project choosing it and succeeding is signal. But there is a lot of noise. An individual judgment about the value is noise unless that individual has demonstrated a pattern of picking winners early and correctly.
Early adopters are often smarter than the average bear, but are also much more likely to jump ship the moment the next fad breaches. That might be OK if you only need them for a short time.
It's the foundation for Fargate and Lambda, so a <<ton>> of AWS customer code runs on top of it.
Considering Microsoft, Google, basically every big company backs it now, I'm sure there are other infra projects using it. They're just not all very visible because these companies only open source a small percentage of their infra.