
Experiments with Ruby and Go - xatxat
http://jorin.me/textstat/
======
tomblomfield
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.

~~~
wiremine
> I ended up thinking about every possible error.

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.

~~~
twblalock
It's not just the try/catch thing. Ruby code can have a syntax error in a
conditional that is rarely true, which may crop up in production from time to
time. I've seen it happen many times, including in some popular Ruby
libraries. A compiled language would have caught that.

~~~
0x0dea
"Ruby code can have a syntax error in a conditional..."

No, it can't. If this is something you've seen "many times", would you mind
providing an example? Show me a program that Ruby tries to execute without
having been able to parse it.

~~~
TheDong

        if foo.something
          foo.instance_eval "SYNTAX ERROR"
        end
    

I know any form of eval is sort of cheating...

But perhaps what he meant was not a syntax error, but things like:

    
    
        if foo.something
          foo.something_misspelled = bar
        end
    

Which isn't technically a syntax error, but that code is invalid in a
statically typed language.

------
phamilton
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.

------
thomasahle
Totally have a look at Haskell next. It takes a while, but it's worth it :)

------
fobbof
Java is not that bad too:
[https://gist.github.com/anonymous/b5c2b77545157a89d0b9](https://gist.github.com/anonymous/b5c2b77545157a89d0b9)

~~~
jorin
Thank you for sharing, looks awesome! Can't believe this is Java code! I
definitely need to checkout Java 8 at some point :)

------
ExpiredLink
It's funny that many people don't distinguish between language and standard
(or default) libraries.

~~~
aikah
Not sure what you're talking about. Go provides No "methods" for arrays.

You have to remember all these tricks :

[https://github.com/golang/go/wiki/SliceTricks](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.

~~~
bigdubs
This is my biggest gripe with golang; I want to be able to write functional
extensions for the blessed generic types (slice, map etc.), but can't. Until
we can do things like this, or implement our own generic types, golang will be
a niche language.

~~~
virmundi
I don't think so. What you're saying is you want to apply a niche concept (fp,
I know it's getting traction, but still pretty niche in the business world) to
an OO language and have a hard time doing that. Golang is niche right now too,
but the lack of functional ability is probably not going to to hugely affect
anything.

~~~
davelnewton
I'd disagree that FP is niche; the concepts are used throughout business, and
more and more back ends are being written in an FP language. Front ends using
JS are being written more and more in an FP style as well.

------
bsaul
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) ?

~~~
pizza234
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.

~~~
phamilton
I would disagree and say the functional style is perfectly fine in its one-
liner form. I'd even say it is preferable in many cases over using
intermediate variables. Why? Because naming is hard and more often than not I
see the intermediate variables named things like "sorted_histogram" or
"sorted_reversed_histogram" which is hardly any clearer than
"@histogram.sort_by{..}.reverse" while being much more verbose.

Intermediate variables in functional languages are largely used for
memoization. Occasionally are they used for self-documentation but generally I
see "people.map(&:full_name)" over "full_names = people.map{ |p| p.first_name
+ ' ' \+ p.last_name }".

~~~
dbattaglia
For me the debugger tends to drive if I use one liners often or not. In C++ or
C# it tends to be easier to step thru code if it's broken out. In Ruby I think
it's probably less common to work with a source stepping debugger so it feels
more natural to write nice functional one liners that do a lot.

