Two things jumped out at me when I switched from Ruby to Go
- Go speeds up my workflow since the compiler catches many of my errors. When I write Ruby, I'm about 75% confident it will be right first-time. With Go, that's about 95%.
- I ended up thinking about every possible error. With Ruby, edge-cases would often only crop up after a few weeks of running the code in production.
Exactly. In Go you can't just wrap code in a try/catch block and not deal with the fall out. You can ignore errors with _, but you still have to explicitly write out _, so you visually see what you're ignoring.
I think this is Go's simplicity is actually helpful. It feels like boilerplate at first, but there is something to being _forced_ to handle edge cases sooner rather than later.
'Every possible error' could you explain what you mean by every.
Additionally how many percentage of errors relate to typing and are solved by static typing? Don't get me wrong, I have really used C, C++, Java, C# and Ruby for a lot of projects. In my experience basic "types" are reminiscent of cpu architectures; they are a small subset of categories or classes. Beyond standard library you have a lot of risks in correctly programming the business domain. So atatic types don't help me much.
"I ended up thinking every possible error" sounds a bit bold..
Ok the more low-level a language is the more you will have control on everything, but hey, Go is not ASM and you will still risk making mistakes.
Even having just one error you didn't think of, then when it presents itself and you're coming back to the code after months, I'm not sure which language, Ruby or Go, will be more pleasant on you..
I'd highly recommend 7 Languages in 7 Weeks by Bruce Tate.
It doesn't have Go, but it walks you through Ruby, Io, Prolog, Clojure, Scala, Erlang, and Haskell. It will give you a wide basic understand of why design tradeoffs have been made.
You can't even wrap them into functions or you'd have to write type assertions everywhere.
Now,you could define a custom Array type with methods, but goodbye type safety. It's funny how sometimes Go works better as a "dynamically typed" language than as a statically typed one.
Ruby on the other hand provides loads of methods for every single "core" type.
It's because the distinction isn't meaningful for day to day use. People use and compare languages and their standard libraries as a whole.
I do think people recognize the fact that these two are different things (e.g. when comparing C to a language with a richer standard library it's one of the points that are often specifically and separately mentioned.), but it's just not very useful to separate them explicitely in a comparison of languages from a user's point of view (as opposed to a language designer's point of view).
anyone else actually found the go code easier to understand than the ruby one liner combining sort, maps, reverse a funny "&" syntax (of which, as a non-ruby developer, the meaning isn't really obvious) ?
Not me. I understand both code snippets, while being only passingly familiar with Ruby and not at all with Go. I can guess what the bits I'm unfamiliar with do.
Ruby's code is more declarative, and seems to use common functional idioms, which make it very easy to understand ("map", "sort", "reverse", "take" mean mostly the same in a wide variety of languages). In this case I do not need to know what the computer is doing "close to the metal", just as I do not need to know the physics of asking someone to fetch me a glass of water.
The Go snippet is also easy to understand, but it has more noise in the form of boilerplate. Here the name of the function is more helpful to understand what it's supposed to do. If the function was named GuessWhatThisDoes I'd figure what it does, but I'd have a harder time than with the Ruby version.
To be honest, both snippets can be understood, but unless I truly needed to understand the step-by-step performance implications, I'd rather read the more declarative Ruby snippet.
Well, it's not very meaningful to compare a good example of something with the bad example of something else (one lines are generally considered bad practice also for this reason).
If that line would be "optimized for readability", there would be at least one or two intermediate variables.
[+] [-] tomblomfield|10 years ago|reply
- Go speeds up my workflow since the compiler catches many of my errors. When I write Ruby, I'm about 75% confident it will be right first-time. With Go, that's about 95%.
- I ended up thinking about every possible error. With Ruby, edge-cases would often only crop up after a few weeks of running the code in production.
[+] [-] wiremine|10 years ago|reply
Exactly. In Go you can't just wrap code in a try/catch block and not deal with the fall out. You can ignore errors with _, but you still have to explicitly write out _, so you visually see what you're ignoring.
I think this is Go's simplicity is actually helpful. It feels like boilerplate at first, but there is something to being _forced_ to handle edge cases sooner rather than later.
[+] [-] diminish|10 years ago|reply
Additionally how many percentage of errors relate to typing and are solved by static typing? Don't get me wrong, I have really used C, C++, Java, C# and Ruby for a lot of projects. In my experience basic "types" are reminiscent of cpu architectures; they are a small subset of categories or classes. Beyond standard library you have a lot of risks in correctly programming the business domain. So atatic types don't help me much.
[+] [-] MrBra|10 years ago|reply
Ok the more low-level a language is the more you will have control on everything, but hey, Go is not ASM and you will still risk making mistakes.
Even having just one error you didn't think of, then when it presents itself and you're coming back to the code after months, I'm not sure which language, Ruby or Go, will be more pleasant on you..
[+] [-] andresmanz|10 years ago|reply
[+] [-] phamilton|10 years ago|reply
It doesn't have Go, but it walks you through Ruby, Io, Prolog, Clojure, Scala, Erlang, and Haskell. It will give you a wide basic understand of why design tradeoffs have been made.
[+] [-] thomasahle|10 years ago|reply
[+] [-] fobbof|10 years ago|reply
[+] [-] jorin|10 years ago|reply
[+] [-] ExpiredLink|10 years ago|reply
[+] [-] aikah|10 years ago|reply
You have to remember all these tricks :
https://github.com/golang/go/wiki/SliceTricks
You can't even wrap them into functions or you'd have to write type assertions everywhere.
Now,you could define a custom Array type with methods, but goodbye type safety. It's funny how sometimes Go works better as a "dynamically typed" language than as a statically typed one.
Ruby on the other hand provides loads of methods for every single "core" type.
[+] [-] throwaway125|10 years ago|reply
I do think people recognize the fact that these two are different things (e.g. when comparing C to a language with a richer standard library it's one of the points that are often specifically and separately mentioned.), but it's just not very useful to separate them explicitely in a comparison of languages from a user's point of view (as opposed to a language designer's point of view).
[+] [-] bsaul|10 years ago|reply
[+] [-] the_af|10 years ago|reply
Ruby's code is more declarative, and seems to use common functional idioms, which make it very easy to understand ("map", "sort", "reverse", "take" mean mostly the same in a wide variety of languages). In this case I do not need to know what the computer is doing "close to the metal", just as I do not need to know the physics of asking someone to fetch me a glass of water.
The Go snippet is also easy to understand, but it has more noise in the form of boilerplate. Here the name of the function is more helpful to understand what it's supposed to do. If the function was named GuessWhatThisDoes I'd figure what it does, but I'd have a harder time than with the Ruby version.
To be honest, both snippets can be understood, but unless I truly needed to understand the step-by-step performance implications, I'd rather read the more declarative Ruby snippet.
[+] [-] pizza234|10 years ago|reply
If that line would be "optimized for readability", there would be at least one or two intermediate variables.
[+] [-] fobbof|10 years ago|reply
[deleted]