4 ms·

+1. I love golang, because for the most part, there is only 1 way to do something. With ruby, there are a billion ways to do the same thing, with some being slo

by itake 2y ago

+1. I love golang, because for the most part, there is only 1 way to do something. With ruby, there are a billion ways to do the same thing, with some being slower than others.

the_gastropod 2y ago
I've just started learning Go as a very long time Rubyist. I really enjoy both languages for very different reasons. In Ruby, I can write code that really makes me happy to read. Enumerable is just wonderful. You can go a long way in Ruby without writing a single if statement. It's great. If I'm working on a solo-project, it's the language I'd choose every time. But working with inexperienced or people who "know" Ruby, but never adopted "the Ruby way" is a nightmare. Ruby code, written poorly, can be extremely brutal to follow. When the great deal of freedom Ruby offers isn't handled responsibly, a hot mess can ensue. Go is the opposite. It's great, as you say, because it's dirt simple. It's a brutalist get-the-job-done kind of language, and I think if I were to start a company working with other engineers, I'd absolutely choose Go for that reason. It's easy to read. It's easy to reason about. And there's very little implicitness in it.
ffsm8 2y ago
> +1. I love golang, because for the most part, there is only 1 way to do something. Are you aware that you're referencing the Python mantra with that? Feel free to Google it, it's from 2004. There should be one-- and preferably only one --obvious way to do it.
- JohnBooty 2y ago
  the Python mantra with that? Offtopic but, I switched from Ruby to Python for a new job about six months ago. While I love Ruby, I was looking forward to some of that "one way to do things" simplicity I'd been promised by Python. Boy... were my hopes crushed. There are a lot of possible ways to do any given thing, from iteration to package/import structures, etc. For the most part it seems like the proliferation of options in Python is pretty sane; I can generally see why each choice was made to address existing pain points. So kudos to Python for that. But man, did they leave "one way to do it" behind a loooong time ago.
  - ffsm8 2y ago
    That they did, indeed. And they honestly never really adhered to it either. It was just a knee-jerk reaction to a (I believe Haskell) presentation that said something like "we got n ways to do x", where n was in the double digits and x was something extremely uninteresting like looping over an array. Can't really recall details though, it was old knowledge by the time I Heard about it around 2010 and a quick Google didn't help me dig it up
JohnBooty 2y ago
with some being slower than others. Do we all agree that in practice, these sort of micro-optimizations almost never matter? It's certainly easy to think of situations where they do matter, but unless your project is FaaS (Fibonacci As A Service) probably not.
- itake 2y ago
  I've seen that more than a few cases where people used the wrong data structure (like array, for O(N)) look ups, instead of a hash. All the inefficiencies add up, at scale. a 3% inefficiency means you're spending ~3% more on compute. CI takes longer. Dev velocity decreases.

by itake 2y ago

+1. I love golang, because for the most part, there is only 1 way to do something. With ruby, there are a billion ways to do the same thing, with some being slower than others.

the_gastropod 2y ago

I've just started learning Go as a very long time Rubyist. I really enjoy both languages for very different reasons. In Ruby, I can write code that really makes me happy to read. Enumerable is just wonderful. You can go a long way in Ruby without writing a single if statement. It's great. If I'm working on a solo-project, it's the language I'd choose every time. But working with inexperienced or people who "know" Ruby, but never adopted "the Ruby way" is a nightmare. Ruby code, written poorly, can be extremely brutal to follow. When the great deal of freedom Ruby offers isn't handled responsibly, a hot mess can ensue. Go is the opposite. It's great, as you say, because it's dirt simple. It's a brutalist get-the-job-done kind of language, and I think if I were to start a company working with other engineers, I'd absolutely choose Go for that reason. It's easy to read. It's easy to reason about. And there's very little implicitness in it.

ffsm8 2y ago

> +1. I love golang, because for the most part, there is only 1 way to do something. Are you aware that you're referencing the Python mantra with that? Feel free to Google it, it's from 2004. There should be one-- and preferably only one --obvious way to do it.

JohnBooty 2y ago
the Python mantra with that? Offtopic but, I switched from Ruby to Python for a new job about six months ago. While I love Ruby, I was looking forward to some of that "one way to do things" simplicity I'd been promised by Python. Boy... were my hopes crushed. There are a lot of possible ways to do any given thing, from iteration to package/import structures, etc. For the most part it seems like the proliferation of options in Python is pretty sane; I can generally see why each choice was made to address existing pain points. So kudos to Python for that. But man, did they leave "one way to do it" behind a loooong time ago.
- ffsm8 2y ago
  That they did, indeed. And they honestly never really adhered to it either. It was just a knee-jerk reaction to a (I believe Haskell) presentation that said something like "we got n ways to do x", where n was in the double digits and x was something extremely uninteresting like looping over an array. Can't really recall details though, it was old knowledge by the time I Heard about it around 2010 and a quick Google didn't help me dig it up

JohnBooty 2y ago

with some being slower than others. Do we all agree that in practice, these sort of micro-optimizations almost never matter? It's certainly easy to think of situations where they do matter, but unless your project is FaaS (Fibonacci As A Service) probably not.

itake 2y ago
I've seen that more than a few cases where people used the wrong data structure (like array, for O(N)) look ups, instead of a hash. All the inefficiencies add up, at scale. a 3% inefficiency means you're spending ~3% more on compute. CI takes longer. Dev velocity decreases.