[erlang-questions] Erlang concurrency - On Go (dehora.net) - ycombinator

[giovanni_re]

On Go (dehora.net) 
http://dehora.net/journal/2013/06/01/on-go/
139 points by ishbits 19 hours ago | 98 comments
https://news.ycombinator.com/item?id=5806970

2 erlang mentions:
-----

graue 15 hours ago | link The lack of exceptions just seems like a total
bear to me. I wrote C for 10 years and did tons of stuff like:

Open file "foobar.dat". If that fails, abort with this error. Read the
first 4 bytes into x. If that fails, abort with a different error. Seek
to byte x. If that fails, abort with yet another error.

and so on, and so on, over and over again. Python's exceptions are a
huge improvement over this pattern of timidly asking permission to do
anything. The fact is there are so, so many occasions where you want to
abort a computation if one of the many steps along the way goes wrong.
Something like Haskell's Maybe monad is a good way of attacking the
problem too.

But Go has neither. It seems to just offer the bad old clumsy C way and
say, "Deal with it." To those who have written real Go programs, I'm
honestly wondering: how is this not a pain in the ass?

reply

MetaCosm 15 hours ago | link Unlike C, Go isn't overloading what is
returned, it has an extra param, and the language has been baked to
handle doing like initialization and checks in single line if
statements. It does force the developer who might actually have a clue
what the exception is and how to fix it to handle it, but IMHO this is a
good thing. Go forces lots of things like this (not using an import,
won't compile; not using a variable, won't compile).

Honestly, compared to the exception hellscapes I have had to deal with
in Java and C++ --- it seems like the path of least surprise. Which
incidentally has been my favorite things about Go, the low number of
surprises.

A lot of using Go in real work has gone against my expectations. There
are a lot of things I initially saw as huge warts (lack of exceptions,
generics and import versions), but I liked channels enough (Erlang
background) to give it a shot. So far, I have been delighted by using it
as a stack (build cycle, deploy method, terse C'ish syntax).



-----

hcarvalhoalves 17 hours ago | link Everybody compares Go and Python. How
is it so? Go compiles to a binary, implements static typing, got rid of
classes, got rid of exceptions, and added lots of special purpose
keywords on top of reinventing C's syntax. The only similarity I see is
the "import" statement.

reply

jlgreco 17 hours ago | link They both approximately match up on mental
effort /friction/hassle for me, which largely seems to be coincidence
since they do have dissimilar feature sets. For example, it use to be
that I would use Python when I thought that C (my language of choice)
was going to be too much of a hassle; now I use Go when I think that C
will be too much hassle.

I think this accounts for a large portion of the Go<->Python talk you
see.

reply

SiVal 15 hours ago | link When app(lication)s meant desktop apps, most
of us used C as an app dev language. Over the years, the platform
changed and most app developers switched to Java and C# and, more
recently, to Python and Ruby. Those who still use C these days mostly
use it to deal with unusually demanding constraints (performance,
memory, etc.) They use C when only C will do, which usually is not for
apps. C is not the default app programming language; it's a
special-purpose language of sorts.

Go is not very competitive with C at what people mostly use C for these
days: tightest constraints and maximum customization. Go is very
competitive with Python (& Ruby), though, as a high-productivity app
development language, being almost as productive as those two but with
much higher performance, lower memory requirements, and no need to
install a big runtime. It's biggest shortcoming, vis-a-vis Py & Ruby, is
the immaturity of its environment (libraries, toolchains, web
frameworks, etc) due to its relative newness. As that changes, many will
switch from P&R to Go, but fewer will switch from C to Go, because most
who don't absolutely need C have already switched away from it.

reply

pjmlp 13 hours ago | link What I always find interesting is that the
Python and Ruby developers are willing to loose abstraction power to
delve down in Go, while they would be able to keep it if they would move
to PyPy, JVM/.NET based languages or FP languages with native compilers
instead.

reply

coldtea 9 hours ago | link Yes, but in return they get something more
mature than PyPy, something with less hassle that bringing along a VM
(JVM/.NET), and something less alien and marginal than FP languages with
native compilers.

They might not get the best technical experience, but they DO get:

1) mostly imperative (and most LIKE it that way), 2) nice concurrency
support, 3) a lot of niceties (first class functions, implicit
interfaces, maps, etc), 4) quite full batteries included, 5) lots of
other kids using it 6) regular success posts on HN 7) nice, and mostly
predictable, reasoning about speed and memory

reply

pjmlp 58 minutes ago | link > Yes, but in return they get something more
mature than PyPy, something with less hassle that bringing along a VM
(JVM/.NET), and something less alien and marginal than FP languages with
native compilers.

There are commercial native compilers for Java and .NET if you are
willing to pay for them. Language != Implementation

As for what one gets,

1) Offered by C++, JVM, .NET languages, D, Rust, ...

2) Scala, Haskell, OCaml, F#, D, Rust, Erlang, ....

3) Almost any modern language with exception of C and Java.

4) Java and .NET have more batteries

5) Yes, because big boys have better tools

6) Fortune 500 companies don't use languages based on HN posts

7) Tooling still behind what big boys use for other languages

reply

MetaCosm 20 minutes ago | link You kinda made his point for him didn't
you? He said all these are benefits of Go, and you pointed out he would
need to use lots of different languages to get them elsewhere.

Notice the lack of overlap in your own points(1-4), that right there is
the crux of the issue. Beyond that, on (5) I simply respond... what? I
think you are flat out wrong about (6) and how they pick languages (I
contract for them), they "hear" node.js is super fast and will double
output and want to use it. (7) is part of what Go was designed to
enable, building tools for it is AWESOME (Go AST!).

If anything you made a killer post, maybe just not for the reasons you
think.



---  Join the BerkeleyTIP-Global mail list -   http://groups.google.com/group/BerkTIPGlobal. All Freedom SW, HW & Culture.