4 ms·
Go and Rust competes in the narrow space of, "what's The Next Interesting Thing to learn?" In that narrow sense, it doesn't matter that the underlying semantic
by jasode 11y ago
Go and Rust competes in the narrow space of, "what's The Next Interesting Thing to learn?"
In that narrow sense, it doesn't matter that the underlying semantics and runtimes of Go and Rust are targeted for different use cases. They get lumped together in the same conversation because people have a vague sense that something... (newer programming language, newer database engine, newer CSS templating, etc)... will make their project better. In that nebulous cloud of possible future benefits, it's understandable for people to mention both in the same conversation. However once people get past the unspecified idea of "better" and actually analyze (i.e. write concrete programs) the real costs & benefits, the differences of Go & Rust will reveal themselves. People will realize that Go is inappropriate to write a 60 fps graphics rendering engine and likewise, Rust is inappropriate to write quick scripts for Google-scale cloud orchestrations.
One other reason that Go is mentioned along with Rust is that Google used the adjective "systems" to describe it. "Go is intended as a systems language". Unfortunately, a lot of folks didn't realize that Google was using an idiosyncratic definition of "systems" to mean a programming language to help the management of their datacenters. To others, "systems language" means writing operating systems, device drivers, embedded chips, etc. There was a nuance that got lost and it ended up muddying the discussion. The phrases, "Go is a systems language", and "Rust is a systems language" look the same but they mean different things.
- cwyers 11y agoNo, they meant Go was intended as a systems language. Rob Pike: http://commandcenter.blogspot.com/2012/06/less-is-exponentially-more.html?m=1 http://commandcenter.blogspot.com/2012/06/less-is-exponentia... > I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++. > We—Ken, Robert and myself—were C++ programmers when we designed a new language to solve the problems that we thought needed to be solved for the kind of software we wrote. It seems almost paradoxical that other C++ programmers don't seem to care. Read the whole thing if you have time - Pike talks about how they were trying to write a language that filled a role similar to C and C++. So they came up with a compiled, statically typed language.
- jasode 11y agoI've read that and I disagree with your interpretation. Google was using C++ in the "systems management" of their datacenters. Rob Pike is using a Google-idiosyncratic definition of "systems". I do believe that Google did use C++ for many classic low-level scenarios (e.g. writing custom Linux device drivers, failover code, etc) but they were also using C++ for "high-level" systems orchestrations and batch jobs. It's the "high-level" uses of C++ that that Rob Pike successfully addressed with Golang. I'm saying a large percentage of programmers outside the Google bubble think of "systems" as low-level stuff like realtime embedded, low-latency device drivers, etc that require zero-cost abstractions. Rob Pike did not design Go's semantics & runtime for those use cases.
- cwyers 11y agoI don't think Rust is designed for those use cases either, honestly.
- qznc 11y agoYou don't think Rust is suitable for writing device drivers or realtime stuff? Why is that?
- cwyers 11y agoWell, no, that's not what I said. I said it's not designed for those use-cases -- if Go is 'designed for systems programming at Google', then Rust is 'designed for systems programming at Mozilla', which if anything is further from the metal than a lot of what happens at Google. I think Rust made a lot of design decisions that probably makes it better for those use cases than Go. But there have been people who have tried to write low-level OS code in Rust and found some significant pain points: http://scialex.github.io/reenix.pdf http://scialex.github.io/reenix.pdf Now, some people who know a lot more about Rust than I do have said these are problems that can be solved in Rust, and I have no reason to disbelieve them. But I don't think writing that sort of stuff was a design focus of the language, compared to writing the sort of large user-space applications that are currently written in C and C++.