I love Rust, but in all honesty I wouldn't use it vs. Golang or C++17 for something that isn't a critical system (e.g a cryptography lib) and even then I'm not sure I wouldn't use something like OCaml instead.
The curve to productivity seem way too steep for the payoff.
Woah, woah, woah. First, Go and C++ are vastly different languages. Apples and oranges.
C++ is huge. It takes an incredible amount of effort to become a proficient C++ developer, and even then, C++ offers none of the amazing safety guarantees that Rust's borrow checker enforces. It's old language with sedimentary layers, including C backwards compatibility. Rust is no where near as complex, and Rust does 5x more to ensure you use Rust correctly. It has brought so many crucial advancements as well: immutable by default, typeclasses instead of OOP (thank god), real sum types, better unicode support, better concurrency primitives, and much much much better tooling and package management. No one in their right mind would be cracking out another C++ project if they took the time to learn Rust and C++.
Go isn't really in the same league as Rust, C++, or C. It's syntax is deceptively C like, and it has an equally poor type system, but it's performance is closer to Java, which is a few orders of magnitude slower than C++. Despite pushing outdated concepts like null and raw pointers on to the programmer, it has a runtime with a stop the world GC with no guarantees about object placement on the stack or heap. Go is also incredibly divisive, it's a step backwards that hardcodes a few useful container types, and gives you no facility to create your own. It has a hard coded method of concurrency (goroutines). While useful in it's simplicity, it lacks the generality one would expect of an industrial language, and these concerns are only now being accepted by the Go team in their 2.0 drafts. Many people believe that Go rose to popularity because of the authors and the company sponsoring it, not on its technical merits ,and Brad Fitzpatrick, one of the maintainers, even said the language brought nothing new to the table aside from better concurrency support in the Gotime podcast episode he attended.
> Many people believe that Go rose to popularity because of the authors and the company sponsoring it, not on its technical merits
I don't believe this to be the popular opinion. Originally Google's involvement dissuaded me, and indeed the very Googly bits have been the worst (context.Context), but the rest of it is markedly un-google-like. It's much more of a Bell Labs feel, with a focus on tool efficiency and stability.
> Brad Fitzpatrick, one of the maintainers, even said the language brought nothing new to the table aside from better concurrency support in the Gotime podcast episode he attended.
I think that was very much the intent. There were a lot of good ideas over the years (especially in Plan 9) and Go is really just a modern, polished revision of those ideas glued together.
Go is a _systems_ language at heart. It focuses on maintainability and literacy, and that's where it leads the pack in my eyes. It's possible to squeeze pretty phenomenal performance out of such a simple language. It's easy to drop into assembly for ultimate optimizations.
Perhaps generality is a mistake? I don't miss it. I've never found joy in debugging someone else's generalized metaprogramming.
Building software at serious scale has led me to appreciate the wisdom buried within Go. It's boring and I love it.
I've written a bit of Rust (and a lot of C++) which I find enjoyable enough, but they're tools I rarely find myself reaching for.
> but it's performance is closer to Java, which is a few orders of magnitude slower than C++
A few order of magnitude is an exaggeration. A more reasonable expectation is a 5x slowdown [1]. Depending on your task, a few orders of magnitude can be correct for JVM based languages; they can have very poor startup times (compared to c++) [2]. However, in startup time, go is not similar to Java.
> Go isn't really in the same league as Rust, C++, or C. It's syntax is deceptively C like, and it has an equally poor type system, but it's performance is closer to Java, which is a few orders of magnitude slower than C++. Despite pushing outdated concepts like null and raw pointers on to the programmer, it has a runtime with a stop the world GC with no guarantees about object placement on the stack or heap
Man, stating your opinions as fact is one thing, but every other claim you made above is empirically incorrect. Rust is a fantastic language on its own merits; no need to make stuff up about “the competition”.
>First, Go and C++ are vastly different languages.
Yes, the point isn't to say that they are similar. Quite the contrary in fact, they are different enough that they compliment well. If I have to do latency sensitive systems work I would use C++17. It's good enough, has useful constructs, and all-in-all, rather easy to write.
It's nice to have stronger static safety but they usually displace the cost somewhere else. AFAIK, Rust becomes extremely touchy when you start inter-operating with abstractions the borrow-checker is not omniscient about. Wrapping code in unsafe{} everywhere feels clunky. That's not my biggest peeve though. Programming complex systems is an iterative process for me. I prototype, go back, throw it away, rewrite, until requirements are met and so on. I don't feel like I would be productive doing that in Rust. I don't care for safety for as long as the software prototype is complete enough. In that phase of development, what I care about is a compromise between velocity, performance, and safety.
The only thing I really miss in C++ is powerful type-system: GADTs and all. But again, if I find that I need those I would use a language that truly excels at that, OCaml.
For anything else, I found Golang to be a terrific fit.
It is easy to on-board new people and have them get productive and feel empowered enough to push change. The building blocks are easy and compose well.
Yes, I agree the lacks generics of generics can be frustrating, especially when software grows. On the other hand, it can get old really fast to debug templated software.
As for GC, it might not use fancy algorithms but from empirical experience, having worked with a wide-range of different applications with different workloads, I found that GC pauses are short and hardly ever an issue. I wouldn't use to write a RTOS but for most usage it's fine and a net positive in productivity and quality.
>Go rose to popularity because of the authors and the company sponsoring it, not on its technical merits
It rose to popularity because it fills a huge niche. My job is to build robust systems that do their job and deliver business value. It's easy to maintain Go code, it's easy to understand, and provides the right amount of static safety most of the time. I find Golang to be a humble and honest language, a productive C.
Rust is cool but not worth it for me.
>No one in their right mind would be cracking out another C++ project if they took the time to learn Rust and C++.
If I had a dollar every time I had read that (replace Rust by Haskell/Erlang/Lisp/Whatever language the cool hip kids use).
ilovecaching|7 years ago
C++ is huge. It takes an incredible amount of effort to become a proficient C++ developer, and even then, C++ offers none of the amazing safety guarantees that Rust's borrow checker enforces. It's old language with sedimentary layers, including C backwards compatibility. Rust is no where near as complex, and Rust does 5x more to ensure you use Rust correctly. It has brought so many crucial advancements as well: immutable by default, typeclasses instead of OOP (thank god), real sum types, better unicode support, better concurrency primitives, and much much much better tooling and package management. No one in their right mind would be cracking out another C++ project if they took the time to learn Rust and C++.
Go isn't really in the same league as Rust, C++, or C. It's syntax is deceptively C like, and it has an equally poor type system, but it's performance is closer to Java, which is a few orders of magnitude slower than C++. Despite pushing outdated concepts like null and raw pointers on to the programmer, it has a runtime with a stop the world GC with no guarantees about object placement on the stack or heap. Go is also incredibly divisive, it's a step backwards that hardcodes a few useful container types, and gives you no facility to create your own. It has a hard coded method of concurrency (goroutines). While useful in it's simplicity, it lacks the generality one would expect of an industrial language, and these concerns are only now being accepted by the Go team in their 2.0 drafts. Many people believe that Go rose to popularity because of the authors and the company sponsoring it, not on its technical merits ,and Brad Fitzpatrick, one of the maintainers, even said the language brought nothing new to the table aside from better concurrency support in the Gotime podcast episode he attended.
xyzzy_plugh|7 years ago
I don't believe this to be the popular opinion. Originally Google's involvement dissuaded me, and indeed the very Googly bits have been the worst (context.Context), but the rest of it is markedly un-google-like. It's much more of a Bell Labs feel, with a focus on tool efficiency and stability.
> Brad Fitzpatrick, one of the maintainers, even said the language brought nothing new to the table aside from better concurrency support in the Gotime podcast episode he attended.
I think that was very much the intent. There were a lot of good ideas over the years (especially in Plan 9) and Go is really just a modern, polished revision of those ideas glued together.
Go is a _systems_ language at heart. It focuses on maintainability and literacy, and that's where it leads the pack in my eyes. It's possible to squeeze pretty phenomenal performance out of such a simple language. It's easy to drop into assembly for ultimate optimizations.
Perhaps generality is a mistake? I don't miss it. I've never found joy in debugging someone else's generalized metaprogramming.
Building software at serious scale has led me to appreciate the wisdom buried within Go. It's boring and I love it.
I've written a bit of Rust (and a lot of C++) which I find enjoyable enough, but they're tools I rarely find myself reaching for.
thethirdone|7 years ago
A few order of magnitude is an exaggeration. A more reasonable expectation is a 5x slowdown [1]. Depending on your task, a few orders of magnitude can be correct for JVM based languages; they can have very poor startup times (compared to c++) [2]. However, in startup time, go is not similar to Java.
[1]:https://benchmarksgame-team.pages.debian.net/benchmarksgame/... [2]:https://github.com/bdrung/startup-time
weberc2|7 years ago
Man, stating your opinions as fact is one thing, but every other claim you made above is empirically incorrect. Rust is a fantastic language on its own merits; no need to make stuff up about “the competition”.
relyio|7 years ago
Yes, the point isn't to say that they are similar. Quite the contrary in fact, they are different enough that they compliment well. If I have to do latency sensitive systems work I would use C++17. It's good enough, has useful constructs, and all-in-all, rather easy to write.
It's nice to have stronger static safety but they usually displace the cost somewhere else. AFAIK, Rust becomes extremely touchy when you start inter-operating with abstractions the borrow-checker is not omniscient about. Wrapping code in unsafe{} everywhere feels clunky. That's not my biggest peeve though. Programming complex systems is an iterative process for me. I prototype, go back, throw it away, rewrite, until requirements are met and so on. I don't feel like I would be productive doing that in Rust. I don't care for safety for as long as the software prototype is complete enough. In that phase of development, what I care about is a compromise between velocity, performance, and safety.
The only thing I really miss in C++ is powerful type-system: GADTs and all. But again, if I find that I need those I would use a language that truly excels at that, OCaml.
For anything else, I found Golang to be a terrific fit.
It is easy to on-board new people and have them get productive and feel empowered enough to push change. The building blocks are easy and compose well.
Yes, I agree the lacks generics of generics can be frustrating, especially when software grows. On the other hand, it can get old really fast to debug templated software.
As for GC, it might not use fancy algorithms but from empirical experience, having worked with a wide-range of different applications with different workloads, I found that GC pauses are short and hardly ever an issue. I wouldn't use to write a RTOS but for most usage it's fine and a net positive in productivity and quality.
>Go rose to popularity because of the authors and the company sponsoring it, not on its technical merits
It rose to popularity because it fills a huge niche. My job is to build robust systems that do their job and deliver business value. It's easy to maintain Go code, it's easy to understand, and provides the right amount of static safety most of the time. I find Golang to be a humble and honest language, a productive C.
Rust is cool but not worth it for me.
>No one in their right mind would be cracking out another C++ project if they took the time to learn Rust and C++.
If I had a dollar every time I had read that (replace Rust by Haskell/Erlang/Lisp/Whatever language the cool hip kids use).