6 ms·

> 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 t

> 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.
- ilovecaching 8y ago
  Go has libraries, more than you can count, for CRMs, PDF, GUIs (and TUIs), and DBs (including standard library support for SQL). I actually try to use as few libraries as possible. Unlike the C# and Java developers I actually know how to code and can whip up something to do exactly what I need in the same time it takes you to read your Javadocs.
  - pjmlp 8y ago
    Most of them of "Hello World" quality hardly usable in production.
  - erik_seaberg 8y ago
    If you reuse a library, you reuse all the debugging work and fixes invested in it. "Shoulders of giants" and all that. If everyone rewrites their own, nobody will ever help you with yours.
gray_-_wolf 8y ago
> Ruby, which was a one trick pony citation needed
jbergens 8y ago
Aren't there more third party libraries for java than for go? Then that is no reason to go from java. Performance wise they seem to be pretty similar too. Of course not for startup time in serverless environments but for most server applications. It sounds like we are down to productivity (and developer happiness) which are a bit unclear and probably different for different teams and organizations. I would guess that large organizations will get into problems if they switch everything to go and then have to re-train all developers, or hire new ones.
- ilovecaching 8y ago
  For libraries, I have never once found Go lacking. I’ve noticed that because Go jumped to the front of the line quite recently you are more likely to find packages that are being actively maintained than Java. That said there are always edge cases, and I have run into places where the only Java library I could get was proprietary, which is pretty usual for Java and pretty rare for Golang. As you many already know the authors of Go are bell labs folks who practically invented hacking and showing up large enterprises (Multics), so there is a hacker mentality in the Go ecosystem that makes ditching libraries and writing a little bit more code attractive to Gophers. I highly encourage anyone learning Go to try to adopt this mindset, Russ Cox has a great blog post about the dangers of depdancies that are often easily dismissed by the Java and Javascriptors. As for resource consumption Go and Java generally execute at the same speed but that’s where the comparison ends. Java has been trying to modernize in some ways but they have fundamental barriers over a statically compiled language, and in typical Java fashion there’s a lot of finger pointing at Jigsaw and Vert.X as answers to Java’s failings, but the truth is that the former has been in development for years and the latter is massively complicated for Java’s target audience. I believe they are also working on fibers, but again that’s far down the line.
bovermyer 8y ago
I really enjoy Go and reach for it first when starting a project. However, Ruby on Rails still has use cases that it's better suited for than Go. Other languages, too, have their uses. Please don't trash talk other languages just because you have a favorite. It's unprofessional.
- ilovecaching 8y ago
  Comparing technologies is a core part of the profession actually. What's worse is when people see a new tool or language and instantly dismiss it because it's not something they already know. A professional considers the technical capabilities in her tools and is willing to upgrade with the times. If there are use cases where Rails is a better fit than Go, than by all means make your argument and I'll make my rebuttal. Maybe we will both learn something, or maybe someone who reads the discussion will learn something. Not every tool is useful, and not every useful tool will be useful tomorrow.
  - bovermyer 8y ago
    Alright, I'll bite. Hypothetical situation: a company has a large and complex Ruby on Rails application that is its primary revenue stream. All of its employees are well-versed in RoR. The operations team consistently reports performance to be within acceptable ranges, and customers are happy with the product. This scenario is common. Just replace "Ruby on Rails" with any other language/framework. Staying with the existing ecosystem is the ideal choice for the business, rather than rewriting everything in Go.
    - ilovecaching 8y ago
      Rewrites are almost never the right call, I agree. The company knows this, but they also see how RoR has locked them in and that the web ecosystem has changed in a lot of ways that makes the RoR proposition not so great. So they task one or two engineers to learn Go. They learn Go in one or two days, and rewrite some scripts in Go. Big success, the scripts are much faster and are statically typed. Then they decide that for a new piece of functionality they'll write it as a service. Since Ruby and Go are both officially support grpc languages, it's easy to connect them using a protobuf schema, and have the RoR app call out to Go. Slowly over time, more new features are written as small Go services, until eventually everything in the RoR app is legacy, or can be replaced by any API gateway. Now if the company needs to switch again, they can just rewrite individual services in a different language.
treis 8y ago
You said: >we don’t get stuck in frameworks that become legacy (rails) And now advocate >Go has a massive ecosystem of third parties libraries What is so special about these libraries that prevent them from becoming legacy?
- ilovecaching 8y ago
  Framework != library. A framework is defined by a DSL or all encompassing architecture that has an opinion on how you structure your app. Frameworks trade choice for supposed convenience. Libraries are just collections of functionality that you can mix or match. Good libraries are framework or paradigm agnostic and are very unmagical in their interface. Libraries are replaceable, frameworks are usually not. In Go, if you use an interface to abstract the library calls you need (which is trivially easy to do) you can easily replace any library in your code. But ditching Rails is a ground up rewrite of your entire application and chances are you have read entire books on Rails so switching is going to cost you a lot.
  - treis 8y ago
    This doesn't accurately represent what Rails is today (or has been for quite a while). Most of its functionality comes from libraries that you can replace as you see fit. You can easily build your own "Rails" if you want by using libraries. >Frameworks trade choice for supposed convenience. It's not just convenience. By coalescing on one standard set of libraries it becomes much more likely that those individual libraries will be maintained. >Libraries are replaceable, frameworks are usually not. In Go, if you use an interface to abstract the library calls you need (which is trivially easy to do) you can easily replace any library in your code. But ditching Rails is a ground up rewrite of your entire application and chances are you have read entire books on Rails so switching is going to cost you a lot. What you describe in the first half is effectively recreating Rails. Expending that initial cost in order to avoid the possibility of expending it later doesn't make sense. And you're not right about the cost of switching from Rails. You can use pretty much all the code you write without Rails. The effort will come in creating whatever it is you want to use to replace Rails.

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.

ilovecaching 8y ago
Go has libraries, more than you can count, for CRMs, PDF, GUIs (and TUIs), and DBs (including standard library support for SQL). I actually try to use as few libraries as possible. Unlike the C# and Java developers I actually know how to code and can whip up something to do exactly what I need in the same time it takes you to read your Javadocs.
- pjmlp 8y ago
  Most of them of "Hello World" quality hardly usable in production.
- erik_seaberg 8y ago
  If you reuse a library, you reuse all the debugging work and fixes invested in it. "Shoulders of giants" and all that. If everyone rewrites their own, nobody will ever help you with yours.

gray_-_wolf 8y ago

> Ruby, which was a one trick pony citation needed

jbergens 8y ago

Aren't there more third party libraries for java than for go? Then that is no reason to go from java. Performance wise they seem to be pretty similar too. Of course not for startup time in serverless environments but for most server applications. It sounds like we are down to productivity (and developer happiness) which are a bit unclear and probably different for different teams and organizations. I would guess that large organizations will get into problems if they switch everything to go and then have to re-train all developers, or hire new ones.

ilovecaching 8y ago
For libraries, I have never once found Go lacking. I’ve noticed that because Go jumped to the front of the line quite recently you are more likely to find packages that are being actively maintained than Java. That said there are always edge cases, and I have run into places where the only Java library I could get was proprietary, which is pretty usual for Java and pretty rare for Golang. As you many already know the authors of Go are bell labs folks who practically invented hacking and showing up large enterprises (Multics), so there is a hacker mentality in the Go ecosystem that makes ditching libraries and writing a little bit more code attractive to Gophers. I highly encourage anyone learning Go to try to adopt this mindset, Russ Cox has a great blog post about the dangers of depdancies that are often easily dismissed by the Java and Javascriptors. As for resource consumption Go and Java generally execute at the same speed but that’s where the comparison ends. Java has been trying to modernize in some ways but they have fundamental barriers over a statically compiled language, and in typical Java fashion there’s a lot of finger pointing at Jigsaw and Vert.X as answers to Java’s failings, but the truth is that the former has been in development for years and the latter is massively complicated for Java’s target audience. I believe they are also working on fibers, but again that’s far down the line.

bovermyer 8y ago

I really enjoy Go and reach for it first when starting a project. However, Ruby on Rails still has use cases that it's better suited for than Go. Other languages, too, have their uses. Please don't trash talk other languages just because you have a favorite. It's unprofessional.

ilovecaching 8y ago
Comparing technologies is a core part of the profession actually. What's worse is when people see a new tool or language and instantly dismiss it because it's not something they already know. A professional considers the technical capabilities in her tools and is willing to upgrade with the times. If there are use cases where Rails is a better fit than Go, than by all means make your argument and I'll make my rebuttal. Maybe we will both learn something, or maybe someone who reads the discussion will learn something. Not every tool is useful, and not every useful tool will be useful tomorrow.
- bovermyer 8y ago
  Alright, I'll bite. Hypothetical situation: a company has a large and complex Ruby on Rails application that is its primary revenue stream. All of its employees are well-versed in RoR. The operations team consistently reports performance to be within acceptable ranges, and customers are happy with the product. This scenario is common. Just replace "Ruby on Rails" with any other language/framework. Staying with the existing ecosystem is the ideal choice for the business, rather than rewriting everything in Go.
  - ilovecaching 8y ago
    Rewrites are almost never the right call, I agree. The company knows this, but they also see how RoR has locked them in and that the web ecosystem has changed in a lot of ways that makes the RoR proposition not so great. So they task one or two engineers to learn Go. They learn Go in one or two days, and rewrite some scripts in Go. Big success, the scripts are much faster and are statically typed. Then they decide that for a new piece of functionality they'll write it as a service. Since Ruby and Go are both officially support grpc languages, it's easy to connect them using a protobuf schema, and have the RoR app call out to Go. Slowly over time, more new features are written as small Go services, until eventually everything in the RoR app is legacy, or can be replaced by any API gateway. Now if the company needs to switch again, they can just rewrite individual services in a different language.

treis 8y ago

You said: >we don’t get stuck in frameworks that become legacy (rails) And now advocate >Go has a massive ecosystem of third parties libraries What is so special about these libraries that prevent them from becoming legacy?

ilovecaching 8y ago
Framework != library. A framework is defined by a DSL or all encompassing architecture that has an opinion on how you structure your app. Frameworks trade choice for supposed convenience. Libraries are just collections of functionality that you can mix or match. Good libraries are framework or paradigm agnostic and are very unmagical in their interface. Libraries are replaceable, frameworks are usually not. In Go, if you use an interface to abstract the library calls you need (which is trivially easy to do) you can easily replace any library in your code. But ditching Rails is a ground up rewrite of your entire application and chances are you have read entire books on Rails so switching is going to cost you a lot.
- treis 8y ago
  This doesn't accurately represent what Rails is today (or has been for quite a while). Most of its functionality comes from libraries that you can replace as you see fit. You can easily build your own "Rails" if you want by using libraries. >Frameworks trade choice for supposed convenience. It's not just convenience. By coalescing on one standard set of libraries it becomes much more likely that those individual libraries will be maintained. >Libraries are replaceable, frameworks are usually not. In Go, if you use an interface to abstract the library calls you need (which is trivially easy to do) you can easily replace any library in your code. But ditching Rails is a ground up rewrite of your entire application and chances are you have read entire books on Rails so switching is going to cost you a lot. What you describe in the first half is effectively recreating Rails. Expending that initial cost in order to avoid the possibility of expending it later doesn't make sense. And you're not right about the cost of switching from Rails. You can use pretty much all the code you write without Rails. The effort will come in creating whatever it is you want to use to replace Rails.