Rust and Go are not competing with each other. Why do we see so many comparisons of them?
Unless Rust wants to position itself as embedded-only it will compete with Go for higher level tasks.
11–20 of 118 posts
Rust and Go are not competing with each other. Why do we see so many comparisons of them?
Unless Rust wants to position itself as embedded-only it will compete with Go for higher level tasks.
> It’s unprecedented for a language to be both garbage-collected and as squarely aimed at systems programming as Go is, because systems programmers have trouble tolerating the stop-the-world pauses that happen when the GC runs. Only for those that never heard of Mesa/Cedar, Algol-68, CPL, Ada, Modula-2+, Modula-3, Oberon, Oberon-2, Active Oberon, Component Pascal, Oberon-07, C+@, Sing#, System C#, D.
Ada is (usually) not garbage-collected, precisely due to the unpredictable pauses.
Earlier quoted context omitted.
Probably Oberon, which was used during several years at ETHZ across the IT department of the university, including the secretary personal. Was also the source for many of Plan 9 UI ideas. What is most successful operating system created in Go or Rust?
For Rust, probably Redox ( https://www.redox-os.org/ ). Then there's http://os.phil-opp.com/ and https://intermezzos.github.io/book/ For Go, I don't know any (but might be wrong, googling did not turn up anything).
My point is that commercial failures of specific OSes have more to do with politics and economic games than capabilities of programming languages.
As the OP was kind of insinuating just because many are too young to remember the OSes written in those languages, they should be ignored.
Yet, so far none of the OSes being written in Rust or possibly Go, have achieved the same amount of users those old forgotten systems had.
We can only improve our future by learning the lessons from the past.
Rust and Go are not competing with each other. Why do we see so many comparisons of them?
For any type of application, including user space drivers, that can be developed with the constraints of a sub-millisecond GC pauses, GC is a good language, in spite of its stance on generics.
As for kernel space, Go could eventually be used as well, in spite of GC hate, as academia including Microsoft have proven a few times.
Me personally, I prefer Rust, but I do see others would think otherwise.
Looking at Android as a representative of "embedded" also seems a bit fallacious. The lowest-end android device I can buy has a lot more ram, storage and clocks than an average home router.
EDIT: this comes across pretty snarky - more so than is warranted. I'm surprised by the first part, but have no right to impugn the whole project based on that. The surprise remains, but I apologise for my tone.
DNS lookup stalls as motivating concurrency .. messy, complicated code with known bugs .. seriously? It's not that hard to call getaddrinfo() in a thread and feed results back (atomically) over a pipe. No shared memory or mutexes needed. Looking at Android as a representative of "embedded" also seems a bit fallacious. The lowest-end android device I can buy has a lot more ram, storage and clocks than an average home…
> I checked this by writing loccount as a parallelized tree traversal. Each file in the tree gets a goroutine spawned to count its lines; the threads run in parallel and as each finishes its work it stuffs a statistics block into a channel. In the past, this approach would blow up because Go would spawn a kernel thread for each blocking system call that was performed. I had to use a rate limiting channel to constrain…
Rust and Go are not competing with each other. Why do we see so many comparisons of them?
Because they are competing with eachother! Unless Rust wants to position itself as embedded-only it will compete with Go for higher level tasks.
Put Rust and Go in front of a python coder who wrote dozens of web services using flask - and I am pretty sure I can predict what tool he'll pick. Sure you could write web services in Rust, that's not what I'm arguing, learning Rust for writing stuff like that is simply not worth it for people having to write such services.
Rust's complexity is comparable with C++, and the main reason for this complexity is to address problems that are mainly seen in C/C++ applications. Rust's reason for existing is simple: modern low-level language with built-in (memory) safety with no performance trade-offs (implying concurrency support etc). That makes it squarely aimed at C++, where developers accept the complexity as a trade-off for performance.
Go's reason of existence and goals are completely different, it addresses the gap that existed between compiled and interpreted languages. It wants to be a simple, safe, easy to deploy language that offers more performance over classic scripting languages and thus is able to address more performance-critical issues. It's main target is clear: servers and networking services, where a GC's impact less important due to the I/O bottlenecks in most scenario's.
Rust and Go are not competing with each other. Why do we see so many comparisons of them?
Because they are competing with eachother! Unless Rust wants to position itself as embedded-only it will compete with Go for higher level tasks.
But that is true for any fast-enough high-level language like Java, Scala, C#, OCaml, Haskell, F#, Kotlin, etc.
So it's not Rust vs Go, it's Rust (and Go) vs the world.