5 ms·

For better or worse, I think Go sucked up a lot of the metaphorical oxygen for similar languages. Swift and Rust are in different niches and don't compete head

by curtis 10y ago

For better or worse, I think Go sucked up a lot of the metaphorical oxygen for similar languages. Swift and Rust are in different niches and don't compete head to head with Go, so this isn't a real problem for them. What I've long wanted is a better C++, not a better C. It would be hard for any such language to succeed today, because it will have to compete with Go, and Go has a fairly mature toolchain and widespread adoption and a lot of mindshare. D literally is designed to be a better C++, and it hasn't really been a big success. Maybe that's because there really wasn't as big a demand for a better C++ as there was for a better C. On the other hand it may have been because Go sucked up a lot of the oxygen that D was going to need to succeed, and maybe that was because Go was a product of Google and D wasn't. (If this was my primary point, I'd make a more nuanced argument, though.) I'm now wondering if the best way to get to a better C++ might be by piggy-backing on the Go toolchain. To get back to my original point, I'm wondering if Go might in fact be a good target for all sorts of better (for some definition) programming languages.

wrsh07 10y ago
For my money, a better C++ is in development: it's called C++20.
- xordon 10y ago
  C++ with more stuff isn't the same as "better C++". C++ has more features than any one person could ever need and it seems like the design philosophy is: anything that is possible in any language; should be added to C++. In reality it is a huge problem for productivity.
  - wrsh07 10y ago
    If you think that languages iterate simply to add stuff, I don't think you understand language development as well as you think. Maybe you're being glib, and that's fine. But improving build times, metaprogramming (which greatly simplifies many libraries), adding lazy ranges, more powerful type inference, better error messages - these are all improvements. The fact is, better metaprogramming means c++ gets smaller, because you don't have to learn separate languages for run time vs compile time computation. If you think the development of c++ in the past few years is anything short of amazing, you're quite mistaken.
dochtman 10y ago
It seems likely to me that Rust is your better C++. I'm also quite positive that there is (more than) enough oxygen for Rust to succeed. As for D, I think it has numerous other issues, that don't apply to Rust.
- curtis 10y ago
  The stuff I've done in C++ would have worked as well or better in a language with garbage collection. On the other hand if you want to write the next OS kernel, then you need a "better C++" that is designed to work without GC. In the latter case, I think there is no question that Rust is your best bet today. I'd like a programming language that is statically compiled, with good performance, garbage collection, and decent support for abstraction. It's the last part where I think Go comes up short, and I think the Go designers think that's a feature not a defect.
  - frou_dh 10y ago
    > I'd like a programming language that is statically compiled, with good performance, garbage collection, and decent support for abstraction. Well if you really are tired of "better C" (in varying guises) then pull the fire alarm and go off-piste with OCaml or Haskell
  - dochtman 10y ago
    > I'd like a programming language that is statically compiled, with good performance, garbage collection, and decent support for abstraction. It feels like you're mixing actual requirements (like "good performance" and "decent support for abstraction") here with things that are more like implementation details ("garbage collection", "statically compiled"). I don't really understand why you want "garbage collection", as such, though I could understand wanting some kind of increased productivity from not having to think about memory management. However, if your real requirement is as I describe it here, then I would still contend that Rust fits the bill.
tedmielczarek 10y ago
Go and D both made the design choice to have garbage collection heavily intertwined with the language (or at least the standard library), which makes them not really suitable for replacing C++ in most applications. Rust doesn't have a GC, so it should do better in that niche. It's always seemed like Google wrote Go to for the purpose of having a "faster Python"--where they were writing components in Python that weren't fast enough, they could write them in Go instead of having to resort to C++.
- curtis 10y ago
  I'm not certain that the goal was a substitute for Python, but either way I think you can make the case that it's worked out that way. It seems like a lot of people who ended up moving to Go started out with Python or maybe Ruby rather than one of the statically typed languages.
geodel 10y ago
I think Go being Google product is overemphasized. Dart is far more a Google product and has achieved modest success in industry. Rust is putting lot of effort in better marketing because they want much broader usage than bits of high-perf, low level code which cannot tolerate a GC pause. Similarly Swift is putting effort on general Server side coding. But I think it will remain limited to server side bits of macOS/iOS applications etc.

by curtis 10y ago

wrsh07 10y ago

For my money, a better C++ is in development: it's called C++20.

xordon 10y ago
C++ with more stuff isn't the same as "better C++". C++ has more features than any one person could ever need and it seems like the design philosophy is: anything that is possible in any language; should be added to C++. In reality it is a huge problem for productivity.
- wrsh07 10y ago
  If you think that languages iterate simply to add stuff, I don't think you understand language development as well as you think. Maybe you're being glib, and that's fine. But improving build times, metaprogramming (which greatly simplifies many libraries), adding lazy ranges, more powerful type inference, better error messages - these are all improvements. The fact is, better metaprogramming means c++ gets smaller, because you don't have to learn separate languages for run time vs compile time computation. If you think the development of c++ in the past few years is anything short of amazing, you're quite mistaken.

dochtman 10y ago

It seems likely to me that Rust is your better C++. I'm also quite positive that there is (more than) enough oxygen for Rust to succeed. As for D, I think it has numerous other issues, that don't apply to Rust.

curtis 10y ago
The stuff I've done in C++ would have worked as well or better in a language with garbage collection. On the other hand if you want to write the next OS kernel, then you need a "better C++" that is designed to work without GC. In the latter case, I think there is no question that Rust is your best bet today. I'd like a programming language that is statically compiled, with good performance, garbage collection, and decent support for abstraction. It's the last part where I think Go comes up short, and I think the Go designers think that's a feature not a defect.
- frou_dh 10y ago
  > I'd like a programming language that is statically compiled, with good performance, garbage collection, and decent support for abstraction. Well if you really are tired of "better C" (in varying guises) then pull the fire alarm and go off-piste with OCaml or Haskell
- dochtman 10y ago
  > I'd like a programming language that is statically compiled, with good performance, garbage collection, and decent support for abstraction. It feels like you're mixing actual requirements (like "good performance" and "decent support for abstraction") here with things that are more like implementation details ("garbage collection", "statically compiled"). I don't really understand why you want "garbage collection", as such, though I could understand wanting some kind of increased productivity from not having to think about memory management. However, if your real requirement is as I describe it here, then I would still contend that Rust fits the bill.

tedmielczarek 10y ago

Go and D both made the design choice to have garbage collection heavily intertwined with the language (or at least the standard library), which makes them not really suitable for replacing C++ in most applications. Rust doesn't have a GC, so it should do better in that niche. It's always seemed like Google wrote Go to for the purpose of having a "faster Python"--where they were writing components in Python that weren't fast enough, they could write them in Go instead of having to resort to C++.

curtis 10y ago
I'm not certain that the goal was a substitute for Python, but either way I think you can make the case that it's worked out that way. It seems like a lot of people who ended up moving to Go started out with Python or maybe Ruby rather than one of the statically typed languages.

geodel 10y ago

I think Go being Google product is overemphasized. Dart is far more a Google product and has achieved modest success in industry. Rust is putting lot of effort in better marketing because they want much broader usage than bits of high-perf, low level code which cannot tolerate a GC pause. Similarly Swift is putting effort on general Server side coding. But I think it will remain limited to server side bits of macOS/iOS applications etc.