7 ms·

Well, one of those things is not like the others. Golang competes more with gc languages/runtimes like Python/Ruby/Nodejs. To a lesser extent it may compete w

by jasode 11y ago

Well, one of those things is not like the others. Golang competes more with gc languages/runtimes like Python/Ruby/Nodejs. To a lesser extent it may compete with Java JVM. (However at this point in time, the JVM GC technology is still far ahead of Go's GC.) If one is writing a networkish service such as REST API endpoint, Golang's combination of language featurs & quality libraries (http) is positioned very well for that. Go isn't suited for system drivers or tight loops that depend on controlling exact memory layouts. I've heard several times to think of Golang as a "DSL for networking apps" and I think it's the best succinct soundbite for that language. That leaves D-minus-the-gc and Rust which Andrei Alexandrescu provided very reasonable analysis. I don't think either will replace C. In 1995, many predicted that Java would supplant C++ and that never happened. For the performance domains that C++ was good at (e.g. AAA games, commercial software like AutoCAD and MS Office), it became even more entrenched. In terms of being forced to make bets, I'd say Rust has a better chance than D because Rust has the momentum behind it that D never had.

buster 11y ago
Plus, as Andrei says himself, D has a GC and it's impractical to work around that in D. So, from that point of view, only Rust can compete with C/C++.
- jasode 11y ago
  Right. I clarified that I meant D's usage explicitly avoiding the historical GC. I'm not a D expert but it looks like the GC obstacle is mostly in the libraries and not impeding the language syntax.
  - chipsy 11y ago
    It's a whole-ecosystem issue. There are plenty of built-in features that happen to depend on GC, and while the ways to eliminate GC use are only increasing with time, the "idiomatic D style" is left in doubt when it's so dependent on allocation strategy. Precision choices for performance are characteristic of D - you have a lot of options to type or annotate your code towards a certain envelope of performance, or ignore almost everything and leave it to the GC. So this is not an unfamiliar problem, but it's a point of friction in the same way that borrow-checking poses friction for Rust - the friction may be centered on what you want for your problem domain. If nothing else, you can write C in D, in a roughly similar way to how you can write C in C++ - the features are there, and so are the libraries.
  - Zardoz84 11y ago
    There is movement to allow to not use the GC. Changes on the standard lib and on the language itself. Even there is movement to include support for ref counting.
odiroot 11y ago
> Golang competes more with gc languages/runtimes like Python/Ruby/Nodejs. I still cannot even grasp this trope. Seems like some try to apply "fake it till you make it" approach. To me, coming from Python and Node (and a bit Ruby) development it seems as a completely opposite direction -- similar to going back to C++ or Java (where I started myself). If not for the quirky syntax and lack of generics I would personally pose it as a replacement for the C++ itself. Rust on the other hand seems to me to be the most promising out of these three as a systems language.
- jasode 11y ago
  >I still cannot even grasp this trope. Seems like some try to apply "fake it till you make it" approach. It's not a fake trope. There are tons of blog posts from programmers describing experiences of switching from Ruby+Rails to Go, or Python+Django to Go, or Javscript+NodeJs to Go. Some defections were high profile such as Nodejs uber-contributor TJ Holowaychuk switching to Go. Compare that to virtually zero notable stories of C++ projects switching to Go. If people are using C/C++, they very likely depend on it for the performance characteristics and therefore switching to Go to suffer a speed penalty makes no sense. On the other hand, people leaving Python/Ruby report performance gains. That's why the reality on the ground looks the way it does.
  - cbr 11y ago
    Compare that to virtually zero notable stories of C++ projects switching to Go. A lot of projects at Google have switched from C++ to Go, and the people I know who work on them are pretty excited about working in Go. Here's a blog post by a coworker who leads the Chrome Data Compression Proxy project: http://matt-welsh.blogspot.co.uk/2013/08/rewriting-large-production-system-in-go.html http://matt-welsh.blogspot.co.uk/2013/08/rewriting-large-pro...
    - jasode 11y ago
      Thanks for the example. I think your coworkers' rewrite further reinforces the "sweet spot" for Go. The transcoding was left as C++ but the other stuff including the networking was rewritten in Go. That makes sense to me because transcoding is performance intensive and cpu-bound instead of io-bound. (E.g. CPUs pegged at 100% while bytes being read at a slow 10MB/sec.) In other words, if people tried to rewrite ffmpeg in Golang, a conversion job such as avi to mp4 would run slower. If Google's internal cpu-bound projects switched from C++ to Golang, that would be a very interesting data point. In other words, I don't expect Google would switch their machine-learning algorithms scanning petabytes of data from C++ to Go (or create greenfield machine learning projects using Go instead of C++).
pjmlp 11y ago
We have to thank Microsoft and Oracle for C++'s comeback to the news. Microsoft for their work supporting the standards work, C++ conferences, push to improve language's safety. Also the change to back to native since the Longhorn failure that has switched focus to C++ and driven .NET to improve its AOT story, starting with Windows Phone 8. Oracle by dropping the ball on Java support (JIT and AOT) for the mobile OSes, making C++ the only option to write portable code across all mobile OSes. As for Go suitability for real systems programming, as a language geek and former Oberon fan, I think the day someone shows a Go bare metal runtime on top of something like Raspberry PI, the opinions will change. Thesis idea. :)
- mpweiher 11y ago
  > making C++ the only option to write portable code across all mobile OSes. Objective-C is also an option. Last I checked there were at least two options for ObjC on Windows and Android. More on Android, IIRC.
  - pjmlp 11y ago
    For many of us it is not an option, if it isn't in the official SDK. Since many years I only work with platform languages. So Google doesn't offer it on the NDK, it isn't an option on Android, even if third party do make it available. Microsoft still isn't fully done with their clang integration, so still not an option as of today.
    - mpweiher 11y ago
      That is a valid choice. However, I think there is a difference between "that's not an option for me because of my preferences" and "that's not an option, period".
      - pjmlp 11y ago
        > "that's not an option, period". That is the answer we get from customers. Dev machines are managed by their IT. My preferences are the customer preferences.
pjc50 11y ago
(AAA games, commercial software like AutoCAD and MS Office), [C++] became even more entrenched. If you're building Windows desktop "productivity" software, your options are basically which version of the Microsoft C+ API you want to work with. Microsoft are trying to migrate people to C#, and there are a few Java desktop apps (mostly java IDEs like Netbeans and Eclipse). Similarly for (Windows) games: C++ is the only realistic option, although smart developers will embed a scripting language for the game logic (eg Lua for WoW). If you don't embed a language, the configuration system ends up being a badly specified Turing complete mess anyway.
Eridrus 11y ago
So I wasn't really involved in tech in 1995, but it seems like at that point C/++ was the only mainstream option for writing code. Hell, PayPal wrote their web app in C and still maintains it. I would say that besides the niche that C/++ is in now, Java (and GC languages in general) did win.
- blub 11y ago
  "Win", "die" and other such terms are nonsensical when referring to programming languages. What happens in reality is that the new language carves itself a niche, taking more or less from the market of the old language. And Java has carved itself a really nice piece of the pie, but it's unlikely that it will expand any more, because it's already dominating in its target niches and doesn't have much to offer where it is not dominating.

by jasode 11y ago

buster 11y ago

Plus, as Andrei says himself, D has a GC and it's impractical to work around that in D. So, from that point of view, only Rust can compete with C/C++.

jasode 11y ago
Right. I clarified that I meant D's usage explicitly avoiding the historical GC. I'm not a D expert but it looks like the GC obstacle is mostly in the libraries and not impeding the language syntax.
- chipsy 11y ago
  It's a whole-ecosystem issue. There are plenty of built-in features that happen to depend on GC, and while the ways to eliminate GC use are only increasing with time, the "idiomatic D style" is left in doubt when it's so dependent on allocation strategy. Precision choices for performance are characteristic of D - you have a lot of options to type or annotate your code towards a certain envelope of performance, or ignore almost everything and leave it to the GC. So this is not an unfamiliar problem, but it's a point of friction in the same way that borrow-checking poses friction for Rust - the friction may be centered on what you want for your problem domain. If nothing else, you can write C in D, in a roughly similar way to how you can write C in C++ - the features are there, and so are the libraries.
- Zardoz84 11y ago
  There is movement to allow to not use the GC. Changes on the standard lib and on the language itself. Even there is movement to include support for ref counting.

odiroot 11y ago

> Golang competes more with gc languages/runtimes like Python/Ruby/Nodejs. I still cannot even grasp this trope. Seems like some try to apply "fake it till you make it" approach. To me, coming from Python and Node (and a bit Ruby) development it seems as a completely opposite direction -- similar to going back to C++ or Java (where I started myself). If not for the quirky syntax and lack of generics I would personally pose it as a replacement for the C++ itself. Rust on the other hand seems to me to be the most promising out of these three as a systems language.

jasode 11y ago
>I still cannot even grasp this trope. Seems like some try to apply "fake it till you make it" approach. It's not a fake trope. There are tons of blog posts from programmers describing experiences of switching from Ruby+Rails to Go, or Python+Django to Go, or Javscript+NodeJs to Go. Some defections were high profile such as Nodejs uber-contributor TJ Holowaychuk switching to Go. Compare that to virtually zero notable stories of C++ projects switching to Go. If people are using C/C++, they very likely depend on it for the performance characteristics and therefore switching to Go to suffer a speed penalty makes no sense. On the other hand, people leaving Python/Ruby report performance gains. That's why the reality on the ground looks the way it does.
- cbr 11y ago
  Compare that to virtually zero notable stories of C++ projects switching to Go. A lot of projects at Google have switched from C++ to Go, and the people I know who work on them are pretty excited about working in Go. Here's a blog post by a coworker who leads the Chrome Data Compression Proxy project: http://matt-welsh.blogspot.co.uk/2013/08/rewriting-large-production-system-in-go.html http://matt-welsh.blogspot.co.uk/2013/08/rewriting-large-pro...
  - jasode 11y ago
    Thanks for the example. I think your coworkers' rewrite further reinforces the "sweet spot" for Go. The transcoding was left as C++ but the other stuff including the networking was rewritten in Go. That makes sense to me because transcoding is performance intensive and cpu-bound instead of io-bound. (E.g. CPUs pegged at 100% while bytes being read at a slow 10MB/sec.) In other words, if people tried to rewrite ffmpeg in Golang, a conversion job such as avi to mp4 would run slower. If Google's internal cpu-bound projects switched from C++ to Golang, that would be a very interesting data point. In other words, I don't expect Google would switch their machine-learning algorithms scanning petabytes of data from C++ to Go (or create greenfield machine learning projects using Go instead of C++).

pjmlp 11y ago

We have to thank Microsoft and Oracle for C++'s comeback to the news. Microsoft for their work supporting the standards work, C++ conferences, push to improve language's safety. Also the change to back to native since the Longhorn failure that has switched focus to C++ and driven .NET to improve its AOT story, starting with Windows Phone 8. Oracle by dropping the ball on Java support (JIT and AOT) for the mobile OSes, making C++ the only option to write portable code across all mobile OSes. As for Go suitability for real systems programming, as a language geek and former Oberon fan, I think the day someone shows a Go bare metal runtime on top of something like Raspberry PI, the opinions will change. Thesis idea. :)

mpweiher 11y ago
> making C++ the only option to write portable code across all mobile OSes. Objective-C is also an option. Last I checked there were at least two options for ObjC on Windows and Android. More on Android, IIRC.
- pjmlp 11y ago
  For many of us it is not an option, if it isn't in the official SDK. Since many years I only work with platform languages. So Google doesn't offer it on the NDK, it isn't an option on Android, even if third party do make it available. Microsoft still isn't fully done with their clang integration, so still not an option as of today.
  - mpweiher 11y ago
    That is a valid choice. However, I think there is a difference between "that's not an option for me because of my preferences" and "that's not an option, period".
    - pjmlp 11y ago
      > "that's not an option, period". That is the answer we get from customers. Dev machines are managed by their IT. My preferences are the customer preferences.

pjc50 11y ago

(AAA games, commercial software like AutoCAD and MS Office), [C++] became even more entrenched. If you're building Windows desktop "productivity" software, your options are basically which version of the Microsoft C+ API you want to work with. Microsoft are trying to migrate people to C#, and there are a few Java desktop apps (mostly java IDEs like Netbeans and Eclipse). Similarly for (Windows) games: C++ is the only realistic option, although smart developers will embed a scripting language for the game logic (eg Lua for WoW). If you don't embed a language, the configuration system ends up being a badly specified Turing complete mess anyway.

Eridrus 11y ago

So I wasn't really involved in tech in 1995, but it seems like at that point C/++ was the only mainstream option for writing code. Hell, PayPal wrote their web app in C and still maintains it. I would say that besides the niche that C/++ is in now, Java (and GC languages in general) did win.

blub 11y ago
"Win", "die" and other such terms are nonsensical when referring to programming languages. What happens in reality is that the new language carves itself a niche, taking more or less from the market of the old language. And Java has carved itself a really nice piece of the pie, but it's unlikely that it will expand any more, because it's already dominating in its target niches and doesn't have much to offer where it is not dominating.