Google backs Go.
Apple backs Swift.
Amazon is trying to back Rust.
Edit : What I am trying to say is that Financial Backing and adoption by FAANG companies can really improve ecosystem of Programming language. I am not here to tell that it will be product of certain company.
Swift is an Apple product that came out of Apple.
Rust was incubated in Mozilla, and this support was essential to getting it going and for its early years (until 1.0 plus or minus a year or so, I’ll suggest), but it was never tied to any one company in the same way: it always had a distinct identity, with others welcome to join that (as distinct from joining Mozilla if they wanted to effect change). Now, various large companies are steadily working on helping support it in this sort of way—Microsoft, Amazon, Facebook, and more.
Sure Go is near exclusively "incubated" by Google, they employ much of the core development team, but there is nothing preventing any organization from contributing to it. Go and Rust are both open languages - they can be used with no commercial licenses and the source is available.
The differences are in their major supporting companies, and the perspective which some choose to use as a deciding factor in the platforms they choose.
Neither is a product. They may be used to create products, but they do not directly generate revenue.
I searched for “rust programming language governance”, and immediately found https://www.rust-lang.org/governance. Nice and clear description of how it all works, how changes are made and who makes decisions, making it very clear that Rust is its own thing and not the property of or beholden to any one company, and that it’s very deliberately an open project, not merely open source.
I searched for “go programming language governance”, “golang governance” and a few other things, but I can’t find anything at all. When I look through their website, it’s Google this Google that, supported by Google, in order to contribute you must accept Google’s contributor license agreement, that kind of thing. I’ve found mention of “Go maintainers” in about two locations, as being those that can approve changes, but I can’t find any mention of who they might be (search terms included “{go programming language,golang} {maintainers,core team}”). Go is absolutely a Google open source project, as they say in a few places.
I imagine Go is a good deal more open to non-Google contributions than Swift is to non-Apple contributions, but it’s still very firmly Google controlling Go, setting its direction, and managing the project, in a way that was never the case for Rust.
Except if the majority of the expertise is held by Google employees it's extremely difficult to do anything without their support. What if Google decides to drop Go tomorrow? A lot of the expertise disappears with that decision and replacing it would require another company to step up and dump gobs of money into the project.
The community can fork the code and continue.
If that did not happen, or the community does not believe that is viable, then the languages is not viable.
Google’s theoretical abandonment of the language does not seem to bother the multiple successful projects based on it. Nor does the lack of apparent focus in Rust’s founder affect its growing user base.
This is very good imo. Rust needs dedicated developers that get paid for their work. And with the upcoming Rust Foundation it feels like Rust is about to really take off to the next level.
https://www.youtube.com/watch?v=MNkFSCRUk6E&feature=youtu.be...
Google is also listed as a sponsor here: https://www.rust-lang.org/sponsors
They might not be as invested as other companies, but I bet they'll eventually ramp up their involvement.
[0] https://www.chromium.org/Home/chromium-security/memory-safet...
* Google github repo ( 30 results for repositories written in Rust )
The fact that both Microsoft and Amazon, Google's major competitors, are investing in Rust means that Google would be quite foolish to not be looking as well.
Apologies if I misunderstand your post, in which case you can disregard my entire post, but -- I assume you mean as in adversarial backing?
These companies use practically all of these languages but to a different extent, for different uses, and for good reasons.
I currently get paid to write C and Go but I dabble in most things, and I'm certainly the happiest when I get to write Rust and ReasonML/ReScript. Having said that, I personally think it's fair to guess that Swift will continue to shine mainly as Apple ecosystem language, Go will continue to shine mainly as network server language and Rust (and whatever follows it) will continue to grow for network servers but will also slowly seep into our shared foundational layer of software. Slowly, slowly, libraries, kernel modules, runtimes, stdlibs for other languages, frameworks, etc. This a good thing, because it slowly rids us of old C and C++ code bases that may not have kept up with the times
Yes, all of these languages are being used to write excellent CLI tools, graphical applications, etc and that's wonderful (I use many of them), but none of these languages are realistically competing to kill any of the other in any definitive way.
Now if only Go would give me sum types (ADTs), my life would be even easier :)
+1 to that, that is also the reason why although I am critical of Go's design approaches, I am at the same time quite supportive of projects using it.
I don't know. Amazon doesn't really back any languages TBH, teams in Amazon chooses their own stack if it justifies itself. Rust is apparently great language for critical low-level programming, and AWS crazes for safety and security.
I won't attribute too much significance to this hiring.
Additionally from the 5 existing vendors, only Ada Core bothers to keep a link with the FOSS community and somehow approachable prices for commercial licenses, which doesn't help to move beyond the existing perceptions about Ada.
'Tainted' how?
> only Ada Core bothers to keep a link with the FOSS community and somehow approachable prices for commercial licenses
There's an Ada compiler as part of the GNU compiler suite.
Library authors keep finding out the actual meaning of going with MIT like licenses instead of dual licensing, specially when their libraries get picked up by the likes of Amazon.
Just get a few rust standards out of iso, one for the core language and another for some standard libraries, and get it over with.
I'm not a C++ programmer but when I read C++ programmers discussing their language standard committee, "free and unconstrained by corporate interests" is usually not how they characterize it.
The Rust development and specification happens all in the open on GitHub.
There is no single company controlling its future or direction.
But more generally, I think you’re approaching this from the wrong angle, perceiving a problem that doesn’t exist—Rust is already not tied to a single corporate interest. But have patience, there are rustlings of independent implementations in a few places, and their fullness will come in a few years’ time.
C was still mostly K&R C when the process started, and in C++ all we had was the C++ARM book.
And no, I don't trust the Rust propaganda machine. When Mozilla announced they were getting rid of Rust teams, all we heard from said Rust devs was that this doesn't spell the end for Rust. My impression was that they were mainly motivated by advancing their language rather than, you know, implementing a browser.
And to this date, I haven't really read a critical post-mortem addressing claims that Rust can actually replace C or C++ in the areas where these languages are essential. Apart from kernels and drivers (where Rust seems an outright no-go), C is traditionally used for higher-level language runtimes and compilers/interpreters/VMs. But Rust's borrow checker is a bad fit for just about any text book algorithm and technique in that space. Hell, even Rust devs themselves say implementing a DOM is about the worst use case for Rust.
How exactly is having one compiler defining what is okay and what is not worse than "what we have now"? The multiple implementations of C++ are all incompatible with each other in various subtle ways, produce code which works differently and at the end of the day everyone just takes one and says "we write C++ which works with <compiler>" and that's it.
> When Mozilla announced they were getting rid of Rust teams, all we heard from said Rust devs was that this doesn't spell the end for Rust. My impression was that they were mainly motivated by advancing their language rather than, you know, implementing a browser.
Why exactly is it a problem that the core team of a language is interested in the language? Or do you want to imply that the rust devs working on Firefox weren't interested in it? All the progress Firefox made in the last few years tells a very different story (yes, not all of it is due to rust, but a relevant part is).
> And to this date, I haven't really read a critical post-mortem addressing claims that Rust can actually replace C or C++ in the areas where these languages are essential. Apart from kernels and drivers (where Rust seems an outright no-go), C is traditionally used for higher-level language runtimes and compilers/interpreters/VMs. But Rust's borrow checker is a bad fit for just about any text book algorithm and technique in that space. Hell, even Rust devs themselves say implementing a DOM is about the worst use case for Rust.
If you haven't read any critical postmortem about Rusts difficulties in these spaces you haven't looked around very much. This is an impression I generally get from your post. You don't like Rust (for some reason, it's not very clear what it is) and seem to have an axe to grind with it. Which is .. okay? No one forces you to like a language, but doesn't make for a very interesting conversation.
This compiler is on the other hand naturally not available on all platforms and is not appropriate for all contexts. Alternate implementations could have filled these gaps, but they're not there.
The fact that the compiler defines the language and vice-versa enables additional flexibility in changing the language/compiler and development speed at the cost of instability. Different projects may tolerate different amounts of instability and for those that are more conservative Rust may not be an appropriate investment.
With C++ one can code for a specific compiler or in a standard way. One can pick C++98 or 17 or anything in between. All of these are supported options and they give C++ its massive breadth and offer the most flexibility to teams. There's obviously disadvantages associated with all that, but claiming that diversity is a weakness is not generally true.
There are already alternative compilers, though most of them are WIP, e.g. mrustc[1], rust front-end for gcc[2][3], or using cranelift[4] for the back-end.
[1] https://github.com/thepowersgang/mrustc
[2] https://github.com/sapir/gcc-rust/tree/rust
It would be interesting for example to see if e.g. the 2015 edition will still be usable/used 9 years later (like C++11) or even ~20 years later (like C++98) but we have some way to go before we can find that out.
On the other hand, there's something exciting about being on the bleeding edge. Right now I'm using C++17 and would probably jump on C++20 when it becomes widely available. But having the knowledge that I have the rock-solid C++11 at my disposal and knowing that it will likely be there for decades gives me a feeling of security that's hard to beat.
Lib A compiled with edition 2018, talking callbacks to functions implemented in Lib B with edition 2020, Lib C edition 2030 importing Lib D edition 2025.
Naturally, I am also assuming that for pleasing the commercial users of binary libraries, typical in C and C++ universe, all those crates are only available as binary libraries being pulled into a multi-edition final executable.
This is a double standard. C was created in 1972 and standardized in 1989. A major C compiler (MSVC) doesn't even fully implement C99 from 21 years ago.
C++ itself was created in 1985 and standardised in 1998. Yet it was adopted.
Yes, things have changed and the bar has been raised. But people don't seem to have followed your reasoning even for C and C++.
> Apart from kernels and drivers (where Rust seems an outright no-go)
Why? From what I've read Rust can actually help with managing hardware resources through its semantics. What blocks it from being used?
It enables experts in different areas from different countries to come and work together under a set of specific rules that are much stronger that words written in wikis or repos. It also makes it clear that the language is designed for the long term and is not under the control of a single party (as was the concern about e.g. Mozilla which the Rust community tried so hard to dispel).
It avoids embarrassing transitions like Python's 2->3 or one corporation taking control of a language like Oracle did with Java by simply buying it. It avoids having to watch a language go extinct because its corporate sponsor wishes it so (Objective-C, VB 6) and many other such unpleasantness.
This is partly why this AWS focus is strange to say the least. I would have thought that it's obvious for the Rust community that having one large sponsor is not healthy. This tells me that Rust was never really as independent from Mozilla as claimed and Mozilla refocusing away from it seriously hurt the language.
Not many people care about standardization, it seems.
I know that it's been renamed, but I think you agree that it's still a very complex and powerful language.
But it's there for those that really need it and personally I like it because it shows what we can achieve when a massive group of experts from all over the planet gets together and they nurture a project over many decades which has to work for such a broad set of use cases under the most strict and diverse of requirements, from avionics to mobile apps, physics simulations to cutting edge video games, medical devices to smartwatches and so on.
These two languages have contributed so much to what we have achieved and they're part of our digital heritage. Maybe that's another reason that they had to be standardized, so that they belong to everyone. :-)
Where is this coming from? I’m also worried about AWS over-representation in the Rust community but they’re far from the only significant corporate sponsors at this point.
As long as a language only has a single implementation or "reference compiler" (like Rust), standardization only adds needless bureaucratic overhead.
The "after 20 years" remark is totally irrelevant because just because the C community was extremely slow it doesn't mean everyone is supposed to repeat the same mistakes.
The only relevant point in your remark is that a standard is required when there are at least two implementations that need to interoperate. That's the only relevant point. A standard is the only way to ensure that interop is possible, and that implementations are reliable.
It is true that the folks working on Rust are focused on "advancing the language," yes. I don't see why it would be any other way?
> Apart from kernels and drivers (where Rust seems an outright no-go),
Rust works great in these scenarios. We'll see about some higher profile examples, like Linux. Work there is ongoing. Only one way to find out.
> C is traditionally used for higher-level language runtimes and compilers/interpreters/VMs. But Rust's borrow checker is a bad fit for just about any text book algorithm and technique in that space.
There are a ton of projects in this space. After all, the Rust compiler, for example, is one of the two OG massive Rust codebases. But there's also tons and tons of projects here.
> Hell, even Rust devs themselves say implementing a DOM is about the worst use case for Rust.
Sort of, but also not really. Implementing a DOM would be easier if Rust had inheritance, is usually what is claimed. Yet, Servo was still built, and nobody would suggest that the DOM was a hard blocker here.
That wasn't the argument. What's problematic is that Rust developers are focused on their language above anything else, to the detriment of the primary product they're developing. When the product - a web browser to stand against Chrome - is much more important than yet another programming language. It's about obsessing on your tools and being in love with a programming language; I call it "thinking with your fingers".
I guess this is the core of it. It is hard for me to understand why you'd think people working on a language would have "the primary product" be something other than the language. There isn't even a single coherent other project to be associated with. Why would "a browser" be special here? It’s even in the name: the Rust developers. We develop Rust.
Do you fault the C standards body for working on C? Or the Ruby core team for working on Ruby? What language do the developers of the language consider something other than the language as their primary product?
Now, of course, as a tool maker, you have to make sure the tool is fit for purpose. You want to enable the people who are working on projects like a browser to be able to do their job. But that's their job, not our job. It seems like you're suggesting that the primary job of Rust developers is to improve Firefox, and it's very confusing to me why you'd say that, when nobody would say that about any other language. Or at least, I've never come across that sentiment before.
> The Servo Project is excited to announce that it has found a new home with the Linux Foundation. Servo was incubated inside Mozilla, and served as the proof that important web components such as CSS and rendering could be implemented in Rust, with all its safety, concurrency and speed.
This is clearly written by someone who sees Servo as a showcase for Rust above anything else rather than what tf it is, such as a state-of-the-art rendering engine. But the developers addressed as readers, such as me, care about the state and coverage of the actual layout engine, CSS parsing/matching, rendering and rendering targets, font handling, and the like.
I'm not the only one bringing this up; when the announcement was discussed [1], there were similar sentiments. For me, a programming language is a means to an end for creating machine code, not an end in itself. This focus (and Mozilla and developers walking away from it) also hints at Servo not being all that useful (or incomplete?) for actual rendering; we don't really know. Anyway, the take away for me is that diving into Servo and Rust is probably not worth my time investment.
You're the best judge of your time, but making a claim about Servo and then, in the last sentence of your post, broadening it to all of Rust, is a bit odd. Servo's not even in production, unlike plenty of other Rust code.
I think the issue here is that this post makes sense to me, but it's about Servo and/or Mozilla. But your initial post was complaining about "the Rust developers." These are two (or three) effectively disjoint sets of people. I think that's where we got off the rails.
If you had said "Mozilla" in your post, I would still disagree, but for completely different reasons. Complaining about a "focus" on a team of ~20ish people in an organization of 1500 people doesn't make a ton of sense to me.
And I'm still not clear why you're drawing conclusions about Rust generally from one single project, that's not even its most popular or widely used exemplar project.
It's not possible for open source project to do such certifications by themselves. In C/C++ world there are companies that implement certified compilers. Usually, these are pretty shitty compilers that implement only previous standards like C++14.
And here is the problem for Rust. If there is no standard for the language and library, how such companies could implement an alternative compiler? Current Rust editions is not an option because they feel like a bottom line and don't answer the question to what extent the compiler has to be implemented to be called "compliant with Rust 2015".
And those fields aren't small. Usually hundreds of million lines of C/C++ power modern vehicle.
I find it's pretty funny that language, which positions itself as safe replacement for C/C++, can't be used in safety critical applications.
"fields" is a bit too broad. Not all applications in those fields require a standard or certification. That being said, you're absolutely right that in some cases, it is required.
> In C/C++ world there are companies that implement certified compilers.
That is true. In Rust, this is what we're seeing too; the first certification effort is being led by a company, in concert with the language team itself. This is still ongoing.
> I find it's pretty funny that language, which positions itself as safe replacement for C/C++, can't be used in safety critical applications.
This is overloading the word "safe." Rust has been about memory safety. Not about every possible meaning of the word "safe." Yes, Rust is not yet mature enough for industries with those kinds of requirements. Yes, they are not small fields. They are still smaller than the sum of all fields that do not require them. Rust doesn't have to be applicable for every possible use at the earliest stages of its life to matter.
We'll see how it goes.
And I find that highly problematic. If anything, Ada would be a much better choice for these safety-critical applications.
That assertion makes no sense at all. If an implementation exists and is already used in production then it's behavior is already relied upon and thus it can already be described. Just write down how it behaves and specify how it is expected to behave. That's it. That's how the whole software world has been for almost half a century.
And no, it makes no difference if a reference implementation decides to implement something that breaks that behavior. That just means it doesn't comply with the standard. That's it.
Why have these basic lessons been forgotten?
I don't know how to describe it differently as GP, but I'll give it a try. Until a formalised model is built, there is no way to describe it's behaviour that wouldn't come down to writing down the implementation that's currently in the compiler (apart from specifying it by example, which would be even more expansive).
It _might_ (don't quote me on this) be possible to more easily formalize and standardize borrow checking if you leave out non-lexical lifetimes (which were added rather recently), but that's a bad idea because you would lose a lot of functionality, and an alternative compiler with an incompatible implementation of NLLs could split the ecosystem, which obviously nobody wants.
That is the point some seem to fail to understand: said model is absolutely irrelevant if we already have production releases of an implementation of Rust.
A standard is not supposed to be academically rigorous. A standard is a specification of the current behavior so that multiple implementations can meet the current requirements, and thus ensure interoperability and compatibility.
It makes absolutely no sense to talk about "a formalized model" because rust is already used in production without said formalized model. The absence of said formalization is irrelevant. The only thing that matters is that the current behavior is specified and set in stone so that it serves as a target set in stone that anyone in the world can target and expect to interoperate.
It's terribly simple: if a rust v1.25 exists then it's behavior and interfaces can be described. Obviously. That description is what a standard is: an implementation target set in stone that others can use as a reference.
If all you have as a reference is a bunch of test cases without any underlying reasoning as to why input A leads to output B, then that's not really a useful target to implement against. At that point you can just go the direct route, not bother with any standard and just implement directly against the Rust compiler.
Suppose you’re a cave man and you’re just figuring out how to double numbers. So far, you’ve figured out how to double each number from 0 to 100. Someone asks you to write down your fancy rule so they can do something with it. Do you really want to be teaching everyone that the way to double a number is: “if the number is zero, the answer is zero; if one, then two, 2 ⇒ 4, 3 ⇒ 6, 4 ⇒ 8, &c. ad tedium”? Even if it covers all the required cases without error, it’s a mess. It’ll do for the moment for your own personal use, but you don’t want to be teaching it to other people until you figure out that you can say “to double a number, add the number to itself”.
Until we have a sound model, any attempt at specifying Rust would, for these key areas, be simply importing the current implementation of the compiler. That’s not a good sort of a specification.
> there are rustlings of independent implementations
was a deliberate choice or just fortuitous, but "rustlings" would be a fantastic term for embryonic new Rust implementations.
C because when UNIX started to get widespread, that was the way to settle difference across multiple language implementations.
And C++ because Bjarne eventually settled on ISO as means to settle out the differences across the various C++ implementations that sprung off.
https://www.stroustrup.com/hopl-almost-final.pdf
However this is also a reason why nice tools like package managers and IDEs are ages behind, because when one vendor comes up with nice toys (C++Builder, vcpkg, CUDA), they don't land on ISO and you are stuck in one eco-system anyway.
For Rust, so far there is one (main) implementation, which is open source. Very different scenario.
Let a, b, c be integers. Consider this statement in a language:
a = b % c
There are three ways I might go about determining that.
1. I could write some test cases and run them. That will tell me what the deal is for that particular compiler on the particular OS and architecture I am compiling on/for. It doesn't tell me if I can count on that anywhere else. It could be that the compiler doesn't care, and I'm simply seeing the way the underlying machine division or mod instruction works on my particular CPU.
If I care, then, I have to specifically write code myself to make it work the way I want, or make sure to only run my code on CPUs that work the way I want.
2. I could look at the source for the compiler. Suppose I see in there that it compiles it so that it will be consistent regardless of how the underlying CPU works, and it is even doing it the way I want.
Great, now I don't need to write extra code. I can just use "a = b % c" and be done with it, right.
Nope. Maybe in the next release of the compiler they change this to just do whatever the underlying CPU does because that enables some optimization that they could not make when they forced one particular option for this. Then my code breaks.
3. I can read the language specification and see what it says about signs and modulus. If it says it will always work one specific way, I can code to that and be done with it.
Without a specification for language X, you cannot really write X code. You can just write code for the incompletely documented X-like language implemented by specific releases of specific X-like langauge compilers, possibly also limited to specific CPUs.
In other words, it's sufficient if the semantics are publicly documented with adequate precision, and the developers of the reference implementation consider any deviation from this specification a bug.
Is that true though? I mean the spec is so "loose" that most compilers don't even work with the same code if it has any level of serious complexity. Normally that's put under the rug of 'undefined behaviour' but imo it's a "vendored version" of the language, the most common variants being MSVC, GCC and CLANG, and even projects which make efforts to be agnostic or have many eyes (linux) can't support GCC _and_ CLANG easily.
Thankfully we can still use independent languages like Nim, Python, C, C++
Here's an example of an AWS open source project, written in Go and hosted on GitHub: https://github.com/kubernetes-sigs/aws-load-balancer-control...
Rust the project is resilient because although it was significantly shepherded by Mozilla, it's been years since it relied on any single company or even individual for advancing (although there are many people whose contributions are very important).
Rust the language is stable, if "incomplete", as there are many language "features" that are still needed (by "features" I don't necessarily mean "adding new things" as some might be worried about, but rather "making existing features work in more places" which although they complicate the implementation of the language simplify the usage of the language).
Rust the ecosystem has advanced by leaps and bounds in the past couple of years but is still green, particularly if you want to use anything outside of the beaten path trail blazed by hobbyists and early adopters. Writing new crates people might want or bringing existing crates up to production quality requires resources: people, money and time. Amazon, Microsoft, Facebook and Google are four large companies that are providing some of those resources. Lots of other companies and individuals are as well. I see these developments as a good thing.
Too many people forget or are not aware that good C/C++ compilers used to be commercial and expensive, they were independent in idea only and evolved today to be independent of any commercial entity. If I wanted to develop performant executables I may have had to purchase an expensive compiler, and abide by its license. If anything, languages are far more independent today than they were.
Trust the language not to be driven by corporate interests, for example by bending it out of shape in future when it suits some needs, or drop it suddenly...
...as it happened a million times with languages and other projects from Google, Oracle, Microsoft.
All evidence indicates that projects that are not tied to a single corporation are more likely to keep their soul and their direction and avoid marketing-based decisions.
The Linux kernel is a good example.
Paranoia. Java and .NET are strong despite their corporate keepers. Open versions of both exist.
Languages are not product, and this is something people seem to have a very difficult time accepting.