Why Discord Is Switching From Go To Rust 256
RoccamOccam writes: The developers at Discord have seen success with Rust on their video encoding pipeline for Go Live and on their Elixir NIFs' server. Recently, they penned a post explaining how they have drastically improved the performance of a service by switching its implementation from Go to Rust.
From the post, "Remarkably, we had only put very basic thought into optimization as the Rust version was written. Even with just basic optimization, Rust was able to outperform the hyper hand-tuned Go version. This is a huge testament to how easy it is to write efficient programs with Rust compared to the deep dive we had to do with Go."
From the post, "Remarkably, we had only put very basic thought into optimization as the Rust version was written. Even with just basic optimization, Rust was able to outperform the hyper hand-tuned Go version. This is a huge testament to how easy it is to write efficient programs with Rust compared to the deep dive we had to do with Go."
Spoiler (Score:4, Insightful)
No GC with rust.
Re: (Score:2)
Re: Spoiler (Score:2)
Re: Spoiler (Score:5, Informative)
Why would the speed of a compiled language change as the language matures?
Significant implementation changes. The original compiler of Go was based on the Plan 9 C compiler with very simple optimizations (from contemporary POV). Then they went to an SSA-based pure Go compiler, which is where they are now. But they still don't have the level of optimization that Rust uses in form of LLVM because they like their short compile times. It's a trade-off -- a reasonable one, but different people tend to prefer different trade-offs.
Re: Spoiler (Score:4, Insightful)
Not a very reasonable trade-off really. Most code spends FAR more time being executed than compiled
Re: (Score:2)
Not a very reasonable trade-off really. Most code spends FAR more time being executed than compiled
This is true but compile time affects project time and long testing cycles. Eventually, long compile times mean failed projects.
Re: Spoiler (Score:4, Informative)
Re: (Score:3)
Re: (Score:2)
Re:Spoiler (Score:5, Informative)
using at that time a years-old version of Go
That's the same song and dance we always hear about GC languages; "but you're using the old version and the new version fixes everything!!11". Except it never actually does, does it? The closest you ever get is maybe 50% of the performance of a C et al., no matter how many decades the runtime has to mature and optimize.
Rust 1.0 is three years younger than Go 1.0, and Rust performance stomps Go flat every time someone does a non-trivial side-by-side comparison. That's because GC has a high cost, and no new version of Go will ever zero out that cost. Java never delivered low cost GC. .NET/CLR never delivered low cost GC. Go will never deliver low cost GC.
And I like Go; I use it daily.
Re:Spoiler (Score:4, Informative)
And I like Go; I use it daily.
Then you know of the massive improvements in some performance metrics between the versions [twitter.com], surely.
Re:Spoiler (Score:4, Informative)
Of course. Just updated to 1.16.0 on Monday. Go is great. It's a fun, powerful language with nice libraries and a fast compiler. My secret hope is that it kills Python, and I think that's actually possible. Nothing in any of that fixes the high cost of GC, however, and it never will.
Re: (Score:3, Interesting)
Of course. Just updated to 1.16.0 on Monday. Go is great. It's a fun, powerful language with nice libraries and a fast compiler. My secret hope is that it kills Python, and I think that's actually possible. Nothing in any of that fixes the high cost of GC, however, and it never will.
For systems programming it might kill Python -- I am unqualified to judge that. But it is hard to see Go matching the parts of Python that make it so convenient for data science.
I recall taking a look at Go, seeing the treatment of numeric arrays, and running the other way.
Julia. Now, Julia has a chance. We just need a whole bunch of folks to create a lot of "batteries".
Re: (Score:2)
How good is Julia at handling matices?
Re: (Score:2)
Re: (Score:3)
Re: (Score:3)
You are right about the frameworks changing and lacking in consistency, but that's actually likely to contribute to Python's continued dominance, rather than its eventual replacement.
If the language kinda-sorta doesn't matter for the frameworks, then people will continue to gravitate to a language that already has all the "other stuff" that data scientists need but don't want to create (SQL database interfaces, web sockets, grammar of graphics, IDEs and so on).
In that sense, I feel like Julia is in the runn
Go does have a modern GC (Score:2)
It is still mark and sweep. It cannot move things like a modern GC does. That is because it is C oriented, and C cannot move things around.
This is why Java is much more efficient on large memory intensive applications.
Without a GC, you are programming in the 1970s. There are some specialist use cases, but for most development it is archaic.
There are no good reasons Go, C or Rust should be faster than Java or .Net. There are plenty of bad reasons though, like Java using UTF-16 strings.
BTW many Java/Go be
Re: (Score:2)
It is still mark and sweep. It cannot move things like a modern GC does.
Moving memory is really overrated for memory management.
Re: (Score:2)
BTW many Java/Go benchmarks do not run long enough to allow for the JIT compile.
And many compile-time language benchmarks don't use enough of the compiler's profile-guided optimization.
Re: (Score:2)
That is because it is C oriented, and C cannot move things around.
Can you elaborate?
I've been writing C for 31 years, from bare hardware, through to higher level kernel goodies, to base systems software, all the way to full fledged applications engineering.
And I have literally no idea what the fuck you are talking about.
Modern GCs MOVE things in memory (Score:4, Informative)
In C if I go
X = malloc(123);
malloc chooses a location and assigns that address (1234, say) to X. Having done that, the X will never point to any other address than 1234, and that assumption is built deeply into the language.
In a modern, not Go GS language
X = new Foo();
might also allocate an object to 1234. But then the Garbage Collector can, at a later stage, decide to move it to location 5678. This requires extreme cleverness in being able to adjust all the other pointers from 1234 to 5678. It also requires a language that enables the GC to know where the pointers are, i.e. real arrays, no (void *)s.
Moving things enables long lived objects to be colocated and compacted in memory. The trick is then to make some pages read-only. When code tries to write to those objects, the trap is caught, the page marked dirty, unprotected, and the program continues. It turns out that for many applications many pages remain read only for a long time. So then the garbage collector using more cleverness can do less work figuring out what needs to be marked as in use.
These algorithms were developed mainly by the Lisp community in the 1980s.
Long ago I used a Lisp system (Kyoto Common Lisp) that compiled via a C compiler. It did a crude mark and sweep by assuming pointers were aligned on the stack, and that anything that looked like a pointer was a pointer, being a conservative strategy. But it was messy, and C was the weakest link.
Re: (Score:3)
Nope. You are thinking like a C programmer.
Of course he is. That's because as a C programmer, he actually understands the material and the machine he is working on.
You should be trying to learn from him, not correct him with incorrect information.
Modern GC languages move things around WITHOUT using handles. Handles would be inefficient for every access. They move things by updating all the pointers that used to point to the old address. Like I said, very clever.
Even old ones do this.
Even GCs written for C, in C, do this.
You are still making the same mistake: You understand the difficulties a GC must deal with, but you can't think of any solutions.
This is why people who are more versed in CS than you wrote the GCs.
You could not do that in C.
Yes, you can.
To claim otherwise is flat out wr
Re: (Score:2)
Re: (Score:3)
As any C programmer has certainly "moved things around"
The topic was not C programmers moving things around but C moving things around. Ergo, the things that you don't write in your application's code.
What kind of nonsense problem is this? Keep track of your damn pointers.
You can't if the language implementation is moving things around. The language implementation has to keep track of your damn pointers in that case. Except it can't in C, hence the BDW GC implementation because it can't distinguish pointers from integers, so live data has to stay in place.
How are you even remotely qualified to opine on this matter?
By understanding the problem, apparently. You should try it.
Re: Spoiler (Score:2)
Old Go runtime set a very low bar for GC performance. Partly because they picked some unusual architectural requirements for their GC to meet and spent a lot of time iterating on the design.
I use Go daily. It's nice for what I do, and easier to learn than Rust.
Re: (Score:3)
Java never delivered low cost GC.
BTW...you don't consider Zing "low cost GC"? Because some people apparently do. [medium.com]
Re: (Score:2)
Falcon:[4] An LLVM-based JIT compiler that delivers dynamically and heavily optimized application code at runtime
So, like all JVMs, it is ultimately a C++ program. Funny how that works.
Re: (Score:2)
So, like all JVMs, it is ultimately a C++ program.
1) Not all JVMs are "ultimately a C++ program". See, e.g., Jikes RVM or GraalVM.
2) Falcon is a compiler, not a memory manager. What does it have to do with JVM's memory management?
3) So you ARE admitting that GC in a program is perfectly fine even for severe requirements, as long as it's a C++ program with GC? Cool.
Re: (Score:2)
2) The blog post you linked to wasn't just talking about memory management.
3) Tell me which realtime systems are running GC languages. Also, like all Java programmers, you neglect to consider that you have to lug around a whole JVM (and in Zing's case, all the saved JIT code) just to run a program. Don't know about you, but even on my desktops and laptops, JVMs don't meet my severe requirements for memory usage.
Re:Spoiler (Score:5, Informative)
More likely the rather basic Go compiler, actually.
Nope. TFA makes it clear that the problem was GC.
The Go implementation was not slower than Rust overall but had "spikey" latency problems every few minutes. They investigated, and sure enough, the problem was GC (duh).
If you want steady, reliable performance, then don't use a language with GC.
Re:Spoiler (Score:4, Interesting)
The Java ecosystem has several GC implementations which are efficient and have very low pause times. It's a shame that no one seems to have have figured out how to create a general-purpose GC library that can be easy integrated into different languages. Ideally, it should look a lot like what we have with "malloc" -- many different designs which can easily be plugged in anywhere.
Re: (Score:3)
It all depends on the GC design.
GC is always going to give you some level of latency.
Rust gives you memory safety with no GC at all.
Any GC language will be inappropriate for some real-time applications. The garbage collector will also add bloat, so you can't run GC code on limited devices such as microcontrollers. Go is never going to run on an Arduino, while Rust and C++ do.
Disclaimer: Yes, Tinygo will run on an Arduino, but it is different enough from Go that it really isn't the same language.
Re: (Score:2)
GC is always going to give you some level of latency.
What level of latency does C4 GC give you?
Re: (Score:2)
What level of latency does C4 GC give you?
Hundreds of microseconds. That is WAY too long for many real-time applications.
Sure, Go is "good enough" for most people doing most things. But there are also many applications where it doesn't work.
Rust can "do it all". So unless there is some other reason to prefer Go over Rust, I just don't see the point of adding yet another language to an organization's list of required skill-sets.
If you were starting a new project from scratch, which strategy do you think makes more sense:
1. "Let's do it in Rust."
2
Re: (Score:2)
So unless there is some other reason to prefer Go over Rust, I just don't see the point of adding yet another language to an organization's list of required skill-sets.
For me, the main reason would be that in Rust, you basically need to plan out all of your data structures up front so that it is in the form of a directed graph to support lifetime management. This is often not the most obvious or easy task, depending on what kind of problem you're working on. If you guess wrong before implementing a bunch of code, reorganizing the directed graph can be a major rewrite.
GC memory management is usually much easier because it lets the machine sort out lifetimes. So I would ten
Re: (Score:2)
If you don't know the ownership graph of your allocations you can stop looking for the reason your performance sucks.
Writing code that runs fast requires a planning<-->analysis feedback loop.
Re: (Score:2)
Re: (Score:2)
I didn't say that my performance sucks.
As I said, you should only do all that work if you *need* the performance. At least 95% of the code in this world doesn't.
Using Rust to start developing most of that code would count as a premature optimization.
Re: (Score:2)
Re: Spoiler (Score:2)
Whoever paid for the database.
Duh.
Re: (Score:2)
Re: (Score:2)
What about data persistence? The database is it's own separate process (apart from in-memory databases).
Re: (Score:2)
Re: (Score:2)
Re:Spoiler (Score:4, Interesting)
If you are referring to Knuth's complete bullshit statement: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%." and how bad programmers are under the delusion that "optimization" is magically to blame for shit variable names, for lack of comments, for comments that don't document WHY this code is needed, for over-engineering, for excessive library includes, for not looking at the generated assembly code, for pretending the compiler is a magic wand, for being clueless how OOP is in general shit for high performance, for assuming you can just throw more hardware at a problem, for using string keys in a map instead of using an enum and array indices, for ignoring memory management, for assuming the GC will solve your memory problems, for assuming that one can optimize later -- when you now have 100 issues instead of writing a reference implementation and measuring your optimization from day one, etc. -- then yeah, it is not just /.; it is a systemic problem by shit programmers making excuses why "they" don't need to optimize.
--
Only young and dumb programmers argue over semi-colons, indentation, and brace placement. The rest of us are too busy solving actual problems after we picked a consistent coding standard.
Re: (Score:2)
Hundreds of microseconds.
That may have been true ten years ago. How about today?
That is WAY too long for many real-time applications.
Do you consider the service in the article "a real-time application"?
Re: (Score:2)
Rust can "do it all".
Can it, though?
Rust, afaict, is just automatic RAII. There are many instances where even that isn't acceptable for low-level real-time software.
Re: (Score:2)
Rust, afaict, is just automatic RAII. There are many instances where even that isn't acceptable for low-level real-time software.
Rust is normally automatic RAII. But it does have the "unsafe" keyword, so you can take the seatbelt off if you really need the extra performance in a block of code. Then you can use raw pointers, unions, memory-mapped I/O, etc., just like C++.
Unlike C++, it is hard for an inexperienced coder to blunder into writing unsafe code. An "unsafe" code block is clearly marked, so easy to flag for review.
Re: (Score:2)
Re: (Score:2)
GC is always going to give you some level of latency.
True, but the same applies to anything that happens inside a complex piece of software. The question is, at what point is the latency of a certain component low enough to not be a concern? The best GCs these days have sub millisecond pause times. This is low enough that it won't affect frame rate in a video game, unless you can see changes in excess of 1000 frames per second.
Rust gives you memory safety with no GC at all.
This is true, but the memory safety aspects aren't necessarily ensured. Unsafe rust is a thing, either for performance or because some
Re: (Score:2)
Unsafe rust is a thing
Unsafe code in Rust is clearly marked and easily flagged for review.
either for performance or because some data structure is difficult to model otherwise.
Go doesn't give you a better way to solve these problems. Instead, it "solves" them by making them impossible to fix.
any language will be inappropriate for some applications.
What application is Go appropriate for that Rust is not?
Re: (Score:2)
What application is Go appropriate for that Rust is not?
Any application which requires rapid development time and a easy learning curve. I'm not trying bash Rust by the way. Different designs have different tradeoffs, and this is mentioned all the time.
Re: (Score:2)
Any application which requires rapid development time
While it might take longer to first write your application, the time you spend debugging later is definitely reduced with Rust.
Re: (Score:2)
What application is Go appropriate for that Rust is not?
One where you want the code to be readable? Or at least not hideously ugly.
Not that I'm a fan of Go, but Rust just feels like someone somewhere gave up on elegance and decided to just force the programmer to handle everything through the use of hieroglyphics.
I mean:
for planet in vec!["Mars", "Jupiter", "Saturn", "Uranus"]
(from some example code online)
'vec![' Seriously? And that's hardly even the start of the horrible syntax.
Re: (Score:3)
Game dev. here. Ignoring memory management doesn't magically make it go away. GC has two major problems:
1. It is non-deterministic, and
2. Doesn't allow you fine-tune how long they are allowed to run.
For the longest time most games didn't use GC (especially on consoles) due its problems. Some engines support it (such as UE4 and Unity). As more and more games support scripting GC has become more popular.
GC is almost always a symptom and not a solution. "Now you have two problems." -- apologies to JWZ.
Using a
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Not on a single-threaded CPU, and not if your thread is allocating and freeing memory. At best there'll be some way for you to explicitly tell the GC "stand down for a moment". But for real-time applications, when a few microseconds of unpredictable pause can potentially be devastating, I don't see any way GC could ever be viable.
Re: (Score:3)
As I've always heard it used "real time" used among professionals, you must be able to *guarantee* that operations complete within a certain amount of time. GC may be able to, on average, satisfy the constraints - but choke on the need for some nasty deallocation at the wrong moment, and that guarantee goes out the window.
Which is also the reason you don't see modern multi-threaded OSes in real-time systems - the OS adds unpredictable delays which prevent you from making any kind of time guarantees. You m
Re: (Score:2)
Good garbage collection is hard, and requires some CPU help (marking pages or objects as dirty). Most new languages these days are built on top of a C-like base model, for portability purposes, often as an interpreted language, and that greatly hampers the ability to do good garbage collection. And this applies to Java as well.
Re: (Score:3)
Good garbage collection is hard, and requires some CPU help
It at least requires the help of the programmer to not put it into badly performing states, but thats true of any library you use, yes?
The garbage collector is a library, but all of you seem to treat it like some uncontrollable black box thats just there behind the scenes.
YOU CAN CONTROL WHEN COLLECTIONS OCCUR
I can guarantee there is no manual collection happening in the code base in question. Thats a full stop on any rational conclusions about the performance of the GC in question. Its being used i
Re: (Score:2)
I can guarantee there is no manual collection happening in the code base in question.
So we're back to manual memory management.
Re: (Score:3)
If you want steady, reliable performance, then don't use a language with GC.
Which is what you want if you are dealing with video and audio - where they used rust. It is the last place you want to see GC.
Re: (Score:2)
Re:Spoiler (Score:5, Informative)
If you want steady, reliable performance, then don't use a language with GC.
Or, learn what the GC does for you and take a bit of control with regards to when it does those things for you.
I constantly see developers complain about GC collection times but when I look at their code they never manually collect at regular intervals, and in fact, never manually collect at all.
If what I am saying is a bit greek to you, and you are a C# or whatever programmer, then fucking shame on you if you've ever complained. For instance, at the top of your render loop in that game you wrote, fucking "GC.Collect();" you fucking dumbass. The GC is going to use all available ram before it tries to collect on its own, on the optimistic assumption that it wont need to, an assumption that is true for 99% of all programs. Take the win that the GC can probably free an entire iterations temporaries with a single heap operation and understand that being ignorant has costs.
Re:Spoiler (Score:5, Insightful)
"For instance, at the top of your render loop in that game you wrote, fucking "GC.Collect();" you fucking dumbass."
This is kinda like advice on how to serve yourself a tasty drink when there's a turd in the punchbowl. Just scoop around it, like masters like you do.
"...learn what the GC does for you..."
It makes performance non-deterministic, that's what it does for you, "you fucking dumbass".
"...the GC can probably free an entire iterations temporaries with a single heap operation and understand that being ignorant has costs."
It sure does, kinda like the ignorance you display when accepting "entire iterations temporaries" in a "render loop" you need to be performant.
Ignorance and hubris, /. never fails to deliver.
Re: (Score:3)
The fundamental issue is does the abstraction really work. Like a lot of people here my 'home language' is C. I have done a lot of Ruby work as well.
I have not yet made the jump to Ruby 3.0.0 but 2.7s GC is probably a good example of a solid solution but not exactly cutting edge tech.
Ruby really offers two big things, one a true OO world with nice functional sugars, and two a managed world to work in. In practice though it often falls short. Case in point a network service.
You'd want requests to come in a
Re: (Score:2)
If you want steady, reliable performance, then don't use a language with GC.
You:
Take the win that the GC can probably
You basically lost the argument right there. "Probably" is not good enough if you really want steady reliable performance, as the GP specifies. Your "probably" is just an optimistic, but highly fragile, guess.
If someone adds something to the loop that prevents a neat single heap operation, then you've lost your "probably". Can you guarantee that future code that people add to the loop would "probably" not interfere with the GC optimizations? If not, then your "probably" is not.
I constantly see developers complain about GC collection times but when I look at their code they never manually collect at regular intervals, and in fact, never manually collect at all.
Yes, because the gen
Re: (Score:2)
If you want steady, reliable performance, then don't use a language with GC.
Ya, that's not entirely fair.
There are deterministic GCs, and there are mark and sweepers. Mark and sweep tends to perform better overall (due to delaying cleanup until it's "convenient") and deterministic GCs do not suffer from unpredictable latency spikes in execution.
If you want steady, reliable performance, then don't use a language with mark-and-sweep GC.
is what that should have said.
Re: (Score:2)
You would think that Google with all its riches would be able to do better. But yeah, this is Google, the promised land of rest and vest.
Re: (Score:2)
Don't know why people keep thinking they can design "new" languages without learning from the experience of other languages.
Old news (Score:5, Informative)
Re:Old news (Score:4, Interesting)
Re:Old news (Score:5, Funny)
Re:Old news (Score:5, Funny)
Did you hear what CmdrTaco said about the iPod? I think that'd make a great Slashdot submission!
Re: (Score:2)
What's an iPod? Is that some kind of Boomer device? Does it not have internet?
Re: Old news (Score:2)
Is this your way of admitting your ignorance and inexperience of the world? Ah, bless your little cotton socks.
Re: (Score:2)
IBM [ibm.com] introduces custom hybrid circuits using discrete, flip chip-mounted, glass-encapsulated transistors and diodes, with silk screened resistors on a ceramic substrate, forming a Solid Logic Technology (SLT) module. SLT sports much higher circuit densities and improved reliability over packaging techniques such as the Standard Modular System. SLT research produces ball chip assembly, wafer bumping, trimmed thick film resistors, printed discrete func
Re: Old news (Score:3)
It'll never catch on. Go old tried and tested vacuum tubes are what the real computers are using and will continue to use long after this solid-state fad fades away.
Re: (Score:2)
My theory is that this happens because the search function is so bad. If you want to know what searching the internet was like in 1999, try the Slashdot search box.
The formatting of the site makes it difficult to find what you want with Google too.
Old version of Go (Score:4, Informative)
Discord were using Go v1.9.2 which was two years old at the time of this post (Feb 2020). So they were comparing an old version of a language with the bleeding edge of another language.
All power to them, Rust is a fine language, but it seems strange to me that they never bothered trying the latest version of Go before putting the effort into porting to a new language.
FWIW, Go's performance since v1.9 has improved dramatically. And there are performance improvements which will hopefully be added in the next version later this year (register based arguments and return values, as opposed to stack based)
Also no async GC (Score:2)
There's a good Gophercon presentation about it: https://www.gophercon.com/agen... [gophercon.com]
Apples and Oranges (Score:5, Insightful)
Rust on the other hand is a lower level language, it has a steeper learning curve and the development process will typically take longer than Go. It is intended to replace other relatively low level compiled languages like C++.
So there is no one size fits all, if your project has no performance goals then simply use something like python that has an enormous library for anything you can possibly imagine and is really easy to get started with. If you need better performance and your application is a command line tool, web application or a faceless api, Go is a good fit, and will bring with it better performance than most interpreted languages. If you want top performance then use C or Rust.
It is the old maxim of choosing the right tool for the job, not that one tool is better than another. Some projects the speed to market is the most important factor, for others like a video encoder with millions of streams, performance is going to be king. Stop hating on other languages and just use what is most appropriate for the task in hand.
Re: (Score:3)
I actually find that Julia is a great language to replace python in most data mining kind of applications.
Re: (Score:3)
Re: (Score:2)
> I actually find that Julia is a great language to replace python in most data mining kind of applications.
Have the concurrency PR's landed in a shipped version? I tried to use Julia for a project a couple years ago but the most it could do was tasks on one OS thread (outside of MPI, which is a totally separate feature).
Re: (Score:2)
The trouble with Go for me is that it is a step back in almost every respect with regards to expressiveness.
Gophers think that's a feature. I don't.
I'd pick GraalVM over Go.
Re: Apples and Oranges (Score:2)
Expressivity is there, brevity is not. Sometimes people are too clever when they write code, and the rest of the world doesn't have time to decipher the proof of cleverness block.
Write simple dumb plain ordinary code. Then most of the bugs you face will be simple dumb plain and ordinary.
Off topic question (Score:3)
Re: (Score:3, Funny)
why does everyone want me on their Discord server?
So you'll post less on Slashdot?
Re: (Score:2)
No they don't get paid. There are a couple of reasons I suppose:
1/ Some people really find the tool helpful. I have been using discord to teach classes, to run a research group, to run professional training workshops. It is pretty nice. I suppose not necessarily different from things like MS teams or combination of slack+zoom, or things like that.
2/ It is pretty popular among the young and they always seem to be trying to build a community around themselves. That leads to a bunch of "I created a discord on
Re: (Score:2)
> why does everyone want me on their Discord server? Do they get paid by the user or something?
A few I've seen have been people who were afraid of getting nuked from YouTube and Twitter. Then they got nuked from YouTube and Twitter.
THEN Discord started nuking people.
WHICH CENTRALIZED SERVICE SHOULD WE ALL GO TO NEXT?
Sheesh. It's like everybody still wants to be a mod on CompuServe.
Switched from a Hammer to a Screwdriver (Score:2)
More Letters ... (Score:5, Funny)
C has one letter
Go has 2 letters
Rust has 4 letters
Fortran has 7 letters
That means that Go is twice as good as C, and that Rust is twice as good again. If you want something almost twice as good as Rust, you will switch to FORTRAN. Of course, BASIC is about half way between the goodness of Go and Rust ...
Re: (Score:2)
but Rust is a corporate-controlled monopoly vector
So you missed the part where Mozilla laid off pretty well the entire Rust dev team? And the creation of the independent foundation to guide Rust?
Re: Obvious. (Score:2)
Re: (Score:2)
In fairness to Google that's the approach Sun took when creating the world's most popular programming language.
Re: (Score:2)
The independent foundation that is funded by multiple megacorps? Yeah, I've heard...
Multiple megacorps do not a monopoly make
Re: (Score:2)
From Wikipedia
On February 8, 2021 the formation of the Rust Foundation was officially announced by its five founding companies (AWS, Huawei, Google, Microsoft, and Mozilla)
Seems like it wants to corporate-controlled monopoly vector. Maybe that is just me.
You keep using that word. I do not think it means what you think it means.