6 ms·

Huge caveat: This article was written in 2012. So do yourself and fellow reader a favor and not argue over content that is now six years-old. Obviously, Go has

Huge caveat: This article was written in 2012. So do yourself and fellow reader a favor and not argue over content that is now six years-old. Obviously, Go has not replaced C++ usage. And, these days, I would see Rust as the more likely step from C++. (Although, I still feel that it remains to be seen whether Rust will make a huge dent there; is memory-safety the killer-app feature that makes people want to use Rust? Do enough people feel that they Need To Use Rust to make it stick? I'm interested to see how that plays out.) What Go has done, I think, is replaced interpreted language use (PHP, Python, Ruby) in backend code. Which makes sense, to me--those are already GC languages, so you're pretty familiar with the lay of that land. Generics may not make a huge deal for you because there were no generics to use in those other languages. And Go is quite a bit faster than any of the aforementioned interpreted languages.

sanderjd 9y ago
> Generics may not make a huge deal for you because there were no generics to use in those other languages. While this is technically true, in practice it is a good deal easier to create generic data types in those languages because you don't have to switch back and forth between type-world and no-type-world.
- peterevans 9y ago
  Sort of--you get dynamic types, so you can stuff whatever you want into your collections. You can do that in Go, too--just use interface{}. Sadly, that has not quieted the Generics Brigade. If you used arrays in PHP, or Ruby, or Python, you can get those--with static typing!--in Go, either with slices for sequential arrays, or maps for associative arrays. I think that satisfies the vast majority of collection use-cases that arise in practical applications of those three languages. (Note: I think generics would be a Good Thing for Go, and I think they'll probably happen at some point. They keep doing user surveys, and the user surveys keep bringing up the lack of generics as one of if not the number-one issue that users would like to see addressed.)
  - candiodari 9y ago
    > Sort of--you get dynamic types, so you can stuff whatever you want into your collections. You can do that in Go, too--just use interface{}. Sadly, that has not quieted the Generics Brigade. This argument, made often by the Go team, contradicts other arguments made by the Go team. Generics done like this have no type safety, which is the central reason for Go. > If you used arrays in PHP, or Ruby, or Python, you can get those--with static typing!--in Go, either with slices for sequential arrays, or maps for associative arrays. I think that satisfies the vast majority of collection use-cases that arise in practical applications of those three languages. Of course what everybody wants is trees, sorted maps, sets, ... WITH static typing. > (Note: I think generics would be a Good Thing for Go, and I think they'll probably happen at some point. They keep doing user surveys, and the user surveys keep bringing up the lack of generics as one of if not the number-one issue that users would like to see addressed.) No they won't. The real issue is that implementing them is pretty difficult in the compiler. Go's compiler is extremely, extremely simplistic, even to the point that it's badly written. It needs a LOT of cleaning up before anyone can reasonably contemplate adding generics.
    - peterevans 9y ago
      I suppose time will tell whether generics are added or not. I'm--not exactly buying your argument that Go's compiler is badly written, or itself the reason that generics can't be added. But god bless ya for having an opinion.
    - mseepgood 9y ago
      > Generics done like this have no type safety, which is the central reason for Go. Type safety is not the central reason for Go.
      - candiodari 9y ago
        I couldn't find the initial announcement, but here is one of the very first presentations by Rob Pike: https://web.stanford.edu/class/ee380/Abstracts/100428-pike-stanford.pdf https://web.stanford.edu/class/ee380/Abstracts/100428-pike-s... "The target Go aims to combine the safety and performance of a statically typed compiled language with the expressiveness and convenience of a dynamically typed interpreted language."
stochastic_monk 9y ago
I think Rust will stick. Until its metaprogramming abilities can match or outpace C++ and be as fast, it won’t replace C++. I do expect it to replace a lot of Java use cases, and perhaps some Go.
nordsieck 9y ago
> What Go has done, I think, is replaced interpreted language use (PHP, Python, Ruby) in backend code. Which makes sense, to me--those are already GC languages, so you're pretty familiar with the lay of that land. One of the less talked about reasons Go is successful at replacing these languages is the devops story - essentially no runtime dependencies.
- candiodari 9y ago
  This can be easily done in C and C++, by static linking. In java, by building custom jars. This is in fact common practice in large companies, for exactly the reason you mention.
  - hackits 9y ago
    You can use static link in C/C++ although you may find that the DLL you're statically linking tend to dynamically load the underlying DLL anyway that defeats the purpose. In most C/C++ world, you're better dynamically linking anyway due to most prior to Visual Studio 2012 it would determine the Service Pack/Dependencies of your host operating system and include that into the exe manifest.
  - kamaal 9y ago
    The argument was made from devops perspective. Which means, no GC is a show stopper. So that eliminates C/C++. Heck the whole point of languages like Perl was C/C++ had huge practical limitations as languages when one wants to get work done quickly. Also Java never really worked in Devops. You need to a lot of ceremony to just open files and do simple regex work. Unfortunately Python went down the same path.
  - zbentley 9y ago
    It cannot be done as easily with interpreted languages (Python, PHP, Ruby, Node.js), though--and those are precisely the languages from which Go has been stealing users.
    - vinceguidry 9y ago
deleted 9y ago
[deleted]
segmondy 9y ago
Go has replaced C/C++ in some circles. Go look at most recent go projects. Kubernetes will never have been done in PHP/Python/Ruby. It would have been a Java or C++ project. Same with cockroachDB, Docker, Etcd, Fleet, Lime, InfluxDB, Prometheus, etc.
marcosdumay 9y ago
> is memory-safety the killer-app feature that makes people want to use Rust? There are algebraic types with pattern matching, sane generics, actually good type inference, strong types that will help you declare behavior only once (as in normal vs. modular arithmetic), and a huge push for not having undefined behavior (that is mostly but not completely successful). Any of those (and yes memory safety) would be enough of a killer feature on my view. There are still some things I dislike in Rust, but compared with C it's a complete no-brainer.

sanderjd 9y ago

> Generics may not make a huge deal for you because there were no generics to use in those other languages. While this is technically true, in practice it is a good deal easier to create generic data types in those languages because you don't have to switch back and forth between type-world and no-type-world.

peterevans 9y ago
Sort of--you get dynamic types, so you can stuff whatever you want into your collections. You can do that in Go, too--just use interface{}. Sadly, that has not quieted the Generics Brigade. If you used arrays in PHP, or Ruby, or Python, you can get those--with static typing!--in Go, either with slices for sequential arrays, or maps for associative arrays. I think that satisfies the vast majority of collection use-cases that arise in practical applications of those three languages. (Note: I think generics would be a Good Thing for Go, and I think they'll probably happen at some point. They keep doing user surveys, and the user surveys keep bringing up the lack of generics as one of if not the number-one issue that users would like to see addressed.)
- candiodari 9y ago
  > Sort of--you get dynamic types, so you can stuff whatever you want into your collections. You can do that in Go, too--just use interface{}. Sadly, that has not quieted the Generics Brigade. This argument, made often by the Go team, contradicts other arguments made by the Go team. Generics done like this have no type safety, which is the central reason for Go. > If you used arrays in PHP, or Ruby, or Python, you can get those--with static typing!--in Go, either with slices for sequential arrays, or maps for associative arrays. I think that satisfies the vast majority of collection use-cases that arise in practical applications of those three languages. Of course what everybody wants is trees, sorted maps, sets, ... WITH static typing. > (Note: I think generics would be a Good Thing for Go, and I think they'll probably happen at some point. They keep doing user surveys, and the user surveys keep bringing up the lack of generics as one of if not the number-one issue that users would like to see addressed.) No they won't. The real issue is that implementing them is pretty difficult in the compiler. Go's compiler is extremely, extremely simplistic, even to the point that it's badly written. It needs a LOT of cleaning up before anyone can reasonably contemplate adding generics.
  - peterevans 9y ago
    I suppose time will tell whether generics are added or not. I'm--not exactly buying your argument that Go's compiler is badly written, or itself the reason that generics can't be added. But god bless ya for having an opinion.
  - mseepgood 9y ago
    > Generics done like this have no type safety, which is the central reason for Go. Type safety is not the central reason for Go.
    - candiodari 9y ago
      I couldn't find the initial announcement, but here is one of the very first presentations by Rob Pike: https://web.stanford.edu/class/ee380/Abstracts/100428-pike-stanford.pdf https://web.stanford.edu/class/ee380/Abstracts/100428-pike-s... "The target Go aims to combine the safety and performance of a statically typed compiled language with the expressiveness and convenience of a dynamically typed interpreted language."

stochastic_monk 9y ago

I think Rust will stick. Until its metaprogramming abilities can match or outpace C++ and be as fast, it won’t replace C++. I do expect it to replace a lot of Java use cases, and perhaps some Go.

nordsieck 9y ago

> What Go has done, I think, is replaced interpreted language use (PHP, Python, Ruby) in backend code. Which makes sense, to me--those are already GC languages, so you're pretty familiar with the lay of that land. One of the less talked about reasons Go is successful at replacing these languages is the devops story - essentially no runtime dependencies.

candiodari 9y ago
This can be easily done in C and C++, by static linking. In java, by building custom jars. This is in fact common practice in large companies, for exactly the reason you mention.
- hackits 9y ago
  You can use static link in C/C++ although you may find that the DLL you're statically linking tend to dynamically load the underlying DLL anyway that defeats the purpose. In most C/C++ world, you're better dynamically linking anyway due to most prior to Visual Studio 2012 it would determine the Service Pack/Dependencies of your host operating system and include that into the exe manifest.
- kamaal 9y ago
  The argument was made from devops perspective. Which means, no GC is a show stopper. So that eliminates C/C++. Heck the whole point of languages like Perl was C/C++ had huge practical limitations as languages when one wants to get work done quickly. Also Java never really worked in Devops. You need to a lot of ceremony to just open files and do simple regex work. Unfortunately Python went down the same path.
- zbentley 9y ago
  It cannot be done as easily with interpreted languages (Python, PHP, Ruby, Node.js), though--and those are precisely the languages from which Go has been stealing users.
  - vinceguidry 9y ago

deleted 9y ago

[deleted]

segmondy 9y ago

Go has replaced C/C++ in some circles. Go look at most recent go projects. Kubernetes will never have been done in PHP/Python/Ruby. It would have been a Java or C++ project. Same with cockroachDB, Docker, Etcd, Fleet, Lime, InfluxDB, Prometheus, etc.

marcosdumay 9y ago

> is memory-safety the killer-app feature that makes people want to use Rust? There are algebraic types with pattern matching, sane generics, actually good type inference, strong types that will help you declare behavior only once (as in normal vs. modular arithmetic), and a huge push for not having undefined behavior (that is mostly but not completely successful). Any of those (and yes memory safety) would be enough of a killer feature on my view. There are still some things I dislike in Rust, but compared with C it's a complete no-brainer.