7 ms·

> Your company should be pivoting or have a strategy to get on deck with these languages. That’s a bold blanket statement. Besides the fact that I would die in

> Your company should be pivoting or have a strategy to get on deck with these languages. That’s a bold blanket statement. Besides the fact that I would die inside a little if I had to use Go every day of my life, Go is in no position to replace any of the aforementioned languages (Python, Js, Ruby, C++), let alone all of them, not by a mile.

hu3 8y ago
I don't think your parent meant that a language broadly replaces another but rather that Go and Rust lend themselves well for some types of projects typically done in other languages.
ilovecaching 8y ago
Not C++, but definitely the other languages outside of some non standard SWE domains like ML, where Python is going to be an obvious winner. Otherwise Go beats them by having a type system but still supporting duck typing through interfaces, having a modern concurrency story, being easier to learn (the Go spec can be read in one evening), having less features to abuse, faster development loops with lightning fast compile times and catching more errors at compile time, and just generally being faster and having a garbage collector that is tuned for low latency (a good fit for web services). We can also start faster which is really important for container workloads, idle with less memory which is important for horizontal scaling, and use less CPU which means smaller machines and more colo. Go also favors libraries over frameworks and is super thoughtful about using too many untested dependancies which means we don’t get stuck in frameworks that become legacy (rails) or use stuff that has security holes or that will change out from under us (npm).
- treis 8y ago
  >Go also favors libraries over frameworks and is super thoughtful about using too many untested dependancies which means we don’t get stuck in frameworks that become legacy (rails) The Go standard library doesn't come close to replicating the functionality of Rails, let alone the gem ecosystem of Ruby/Rails. If you don't need it, great! Otherwise, you're spending time re-implementing what already exists and probably doing a worse job of it.
  - ilovecaching 8y ago
    > The Go standard library doesn't come close to replicating the functionality of Rails Why would it? It's the standard library. Go has a massive ecosystem of third parties libraries, and unlike Ruby, which was a one trick pony, Go has libraries for pretty much anything you could want to do. It's exceedingly versatile and it has better integration into modern infra. Why? Because it's all written in Go. Prometheus, Kubernetes, etcd, terraform, docker, caddy, fleet, influxDB, synthing, coachroachDB, gogs, mino... all written in Go. Go is cloud first, and has first class support for multicloud abstractions written by the go team. It's got great support for rpc through grpc and protocol buffers both of which are much easier to use in a statically compiled C like language that resembled the protocol buffers primitives. Rails literally offers nothing you can't get from Go, and it doesn't make you pay for the stuff you aren't using. With Go you don't write in a DSL based on the language, you just write regular Go code. You aren't a rails developer, you're a Go developer.
    - aprdm 8y ago
      Err, both Python and Ruby have a much bigger ecosystem than Go. Not only that but you're speaking as if Python or Ruby were usually used in the context of building infrastructure-level services (k8s, dbs, consul, docker, etc.) instead of business logic / applications kind of services ( gitlab, shopify, your usual startup CRUD). Why would you even compare both? You wouldn't want to create gitlab V1 with Go just like you wouldn't want to write Kubernetes in Ruby.
      - Zancarius 8y ago
        > You wouldn't want to create gitlab V1 with Go Does Gitea[1] count (fork of Gogs)? I understand your point (I love Python, too), but I can't help finding some amusement in it since it has been done. :) [1] https://github.com/go-gitea/gitea https://github.com/go-gitea/gitea
    - pjmlp 8y ago
      > Go has libraries for pretty much anything you could want to do. Except for CRMs, GUI, DB drivers with the same feature level as JDBC or ADO.NET, Office/PDF docs (full spec not hello world stuff), GPGU, 3D game engines (Unreal/Unity/CryEngine,...), ... Modern infra is the NoSQL of 2019.

hu3 8y ago

I don't think your parent meant that a language broadly replaces another but rather that Go and Rust lend themselves well for some types of projects typically done in other languages.

ilovecaching 8y ago

Not C++, but definitely the other languages outside of some non standard SWE domains like ML, where Python is going to be an obvious winner. Otherwise Go beats them by having a type system but still supporting duck typing through interfaces, having a modern concurrency story, being easier to learn (the Go spec can be read in one evening), having less features to abuse, faster development loops with lightning fast compile times and catching more errors at compile time, and just generally being faster and having a garbage collector that is tuned for low latency (a good fit for web services). We can also start faster which is really important for container workloads, idle with less memory which is important for horizontal scaling, and use less CPU which means smaller machines and more colo. Go also favors libraries over frameworks and is super thoughtful about using too many untested dependancies which means we don’t get stuck in frameworks that become legacy (rails) or use stuff that has security holes or that will change out from under us (npm).

treis 8y ago
>Go also favors libraries over frameworks and is super thoughtful about using too many untested dependancies which means we don’t get stuck in frameworks that become legacy (rails) The Go standard library doesn't come close to replicating the functionality of Rails, let alone the gem ecosystem of Ruby/Rails. If you don't need it, great! Otherwise, you're spending time re-implementing what already exists and probably doing a worse job of it.
- ilovecaching 8y ago
  > The Go standard library doesn't come close to replicating the functionality of Rails Why would it? It's the standard library. Go has a massive ecosystem of third parties libraries, and unlike Ruby, which was a one trick pony, Go has libraries for pretty much anything you could want to do. It's exceedingly versatile and it has better integration into modern infra. Why? Because it's all written in Go. Prometheus, Kubernetes, etcd, terraform, docker, caddy, fleet, influxDB, synthing, coachroachDB, gogs, mino... all written in Go. Go is cloud first, and has first class support for multicloud abstractions written by the go team. It's got great support for rpc through grpc and protocol buffers both of which are much easier to use in a statically compiled C like language that resembled the protocol buffers primitives. Rails literally offers nothing you can't get from Go, and it doesn't make you pay for the stuff you aren't using. With Go you don't write in a DSL based on the language, you just write regular Go code. You aren't a rails developer, you're a Go developer.
  - aprdm 8y ago
    Err, both Python and Ruby have a much bigger ecosystem than Go. Not only that but you're speaking as if Python or Ruby were usually used in the context of building infrastructure-level services (k8s, dbs, consul, docker, etc.) instead of business logic / applications kind of services ( gitlab, shopify, your usual startup CRUD). Why would you even compare both? You wouldn't want to create gitlab V1 with Go just like you wouldn't want to write Kubernetes in Ruby.
    - Zancarius 8y ago
      > You wouldn't want to create gitlab V1 with Go Does Gitea[1] count (fork of Gogs)? I understand your point (I love Python, too), but I can't help finding some amusement in it since it has been done. :) [1] https://github.com/go-gitea/gitea https://github.com/go-gitea/gitea
  - pjmlp 8y ago
    > Go has libraries for pretty much anything you could want to do. Except for CRMs, GUI, DB drivers with the same feature level as JDBC or ADO.NET, Office/PDF docs (full spec not hello world stuff), GPGU, 3D game engines (Unreal/Unity/CryEngine,...), ... Modern infra is the NoSQL of 2019.