Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The March Towards Go

zef.me

Post reply on HN
Print view View original

81–90 of 217 posts

Re: The March Towards Go

#81

Post by avz »

candl wrote: post #70
jbb555 wrote: post #3

I don't understand why people like go. It seems to be missing a lot of features and be pretty ugly and painful. I guess compared to javascript I can see the advantages though

I tried to like Go. I was allured by the native compilation and quite low memory footprint while still being quite high level, but I just can't. I can't stand it forces you to use K&R style. I can't stand the verbose error handling. I can't stand the inconsistency in the built-in types and libraries. I hate that unused variables and imports are a compile error which is just stupid and kills all the fun in programming…

I'd argue placing error handling in a spotlight is a feature, not a bug.

Years of hiding error handling resulted in cultural biases that sanction focus on features without sufficient consideration for failure modes and unexpected conditions. Merely throwing an exception when something goes wrong may give you a peace of mind, but often leads to software which isn't robust against simple failures.

Re: The March Towards Go

#82

Post by bsdetector »

otikik wrote: post #16
jbb555 wrote: post #3

I don't understand why people like go. It seems to be missing a lot of features and be pretty ugly and painful. I guess compared to javascript I can see the advantages though

> missing a lot of features Not a lot of them - just some. And the missing ones, a lot of people don't miss anyway. It also has things others languages don't - fast compilation, a big company behind it (while staying opensource), and simplicity. > be pretty ugly and painful Subjective. I like how it looks and have no pain. > compared to javascript I can see the advantages though It is not just "better than javascript…

> has things others languages don't - fast compilation

Never understood this talking point. What language other than C++ (and C to some extent) doesn't have fast compilation? And compared to these languages Go gets most of its compile speed simply by doing a really poor job optimizing. Compare times for -O0 and -O3 on other languages to see most compile time is dominated by optimizations.

Is this supposed to convince C/C++ programmers? Like "sure your program will run 50% slower and have garbage collection pauses, but it compiles faster!". This just boggles my mind.

Re: The March Towards Go

#83

Post by adamlett »

otikik wrote: post #16
jbb555 wrote: post #3

I don't understand why people like go. It seems to be missing a lot of features and be pretty ugly and painful. I guess compared to javascript I can see the advantages though

> missing a lot of features Not a lot of them - just some. And the missing ones, a lot of people don't miss anyway. It also has things others languages don't - fast compilation, a big company behind it (while staying opensource), and simplicity. > be pretty ugly and painful Subjective. I like how it looks and have no pain. > compared to javascript I can see the advantages though It is not just "better than javascript…

> It is as expressive as ruby or python

I like Go too, but lets not kid ourselves here. Ruby is vastly more expressive than Go. (I'm sure Python is too, but I am not a Python programmer, so I am not in a position to say).

Re: The March Towards Go

#84

Post by nawitus »

adamors wrote: post #59
facepalm wrote: post #42

Earlier quoted context omitted.

There are minor details wrong with JavaScript. Normally you don't encounter them in daily use. Apart from that JavaScript is brilliant. Few other languages can match it's simplicity. Python falls through because it doesn't have real lambda.

If you normally only do a couple lines of jQuery per day then I agree that you don't encounter the warts very often. If however you want to do even some OOP you cannot miss the world of hurt that is coming your way. Then there's the horrible weak type system which makes maintenance of anything needlessly complex, not to mention the global variables, unused reserved words, anything that has to with numbers etc.

TypeScript solves JavaScript's type problems pretty well, it's worth a look.

Re: The March Towards Go

#85

Post by otikik »

DCKing wrote: post #66
otikik wrote: post #60

Earlier quoted context omitted.

> Go's type system is weak. It is strong enough for me. I see the lack of algebraic data types and type classes as a feature, honestly. It means I can learn the things I need and start working in 2 days instead of in 2 weeks or a month. I sometimes need generics, but not frequently enough to miss them. You think Go's type system is weak. I think Haskell's type system is overcomplicated. So, there.

Go's type system being weak is a factual statement. Haskell's type system being overcomplicated is an opinion. One might prefer a weak type system over a strong type system, but that's a different discussion. The parent clearly expressed that he wants a static strong type system.

> weak is a factual statement

I disagree. "Weakly typed" does not even have a precise definition.

Defining "strongly typed" as "the way Haskell does it" and anything less as "weakly typed" is an opinion.

I agree that Haskell types are stronger than Go. That does not does not mean that Go is "weakly typed". It's "less strongly typed than Haskell".

> The parent clearly expressed that he wants a static strong type system.

I was not contesting that, only the classification of Go as "weakly typed".

Re: The March Towards Go

#86

Post by djs55 »

peterhunt wrote: post #30
silentOpen wrote: post #20

Earlier quoted context omitted.

You're missing that OCaml isn't stuck in 1999. OCaml now has an excellent package manager, cool new features, lots of system libraries, and a growing community. What do you find out-dated about it? Check out http://www.realworldocaml.org

I want to serve a JSON response over HTTP, preferably from a standalone server (like django etc). Later I want to talk to Postgres and memcached. Do I use this thing? http://ocsigen.org/ocsigenserver/ All the docs either don't do what I'm looking for (i.e set up a web server to serve some static files) or are broken links! OCaml is actually what I'd prefer to use (since I had a blast with SML/NJ) I'll check out that…

For HTTP I always use 'ocaml-cohttp' (opam install cohttp):

https://github.com/mirage/ocaml-cohttp/blob/master/examples/...

For JSON I normally use 'Jsonm' but I've heard good things about 'Ezjsonm':

https://github.com/samoht/ezjsonm

I've not personally tried them but 'postgresql-ocaml' and 'ocaml-memcached' look plausible.

Re: The March Towards Go

#87

Post by Keats »

bsdetector wrote: post #82
otikik wrote: post #16

Earlier quoted context omitted.

> missing a lot of features Not a lot of them - just some. And the missing ones, a lot of people don't miss anyway. It also has things others languages don't - fast compilation, a big company behind it (while staying opensource), and simplicity. > be pretty ugly and painful Subjective. I like how it looks and have no pain. > compared to javascript I can see the advantages though It is not just "better than javascript…

> has things others languages don't - fast compilation Never understood this talking point. What language other than C++ (and C to some extent) doesn't have fast compilation? And compared to these languages Go gets most of its compile speed simply by doing a really poor job optimizing. Compare times for -O0 and -O3 on other languages to see most compile time is dominated by optimizations. Is this supposed to convince…

Scala is pretty slow

Re: The March Towards Go

#88

Post by andor »

ovi256 wrote: post #6
jbb555 wrote: post #3

I don't understand why people like go. It seems to be missing a lot of features and be pretty ugly and painful. I guess compared to javascript I can see the advantages though

Go could be improved in many ways. It lacks facilities that what we consider modern programming languages have, e.g. object-oriented programming, generics. The existing Goland solution to the generics problem is to have an almost duck typing approach of doing everything via interface{}. These are the cons. The pros are of such value that they more than compensate for the cons: first class facilities for building conc…

My personal dream endgame would be a dynamic language, such as Python or Ruby, that includes the concurrency features such as goroutines and channels

Erlang is dynamic and has all those features :-)

It's true that the GIL in Python prevents interpreter threads to run simultaneously. But for many use cases it's OK to use gevent or multiprocessing (which share the same interface!). Channels are there in the form of queues, but there's no built-in support for selecting from multiple queues. To emulate that, you need an extra greenlet for each queue.

Re: The March Towards Go

#89

Post by mappu »

_pmf_ wrote: post #76
facepalm wrote: post #42

Earlier quoted context omitted.

There are minor details wrong with JavaScript. Normally you don't encounter them in daily use. Apart from that JavaScript is brilliant. Few other languages can match it's simplicity. Python falls through because it doesn't have real lambda.

> There are minor details wrong with JavaScript. Normally you don't encounter them in daily use. Defaulting to doubles and not having native integral types is not a "minor detail".

Doubles do have 53 bits of int precision at least. Did you know libcurl uses doubles to represent file sizes? File sizes that are always integral? Don't ask me why they did that, guess it had better platform support than int64's a hundred years ago.

Re: The March Towards Go

#90

Post by bsdetector »

_yosefk wrote: post #31
enneff wrote: post #25

Earlier quoted context omitted.

The hundreds of high quality Go packages that do handle errors are an existence proof against your argument. Look at nearly anything on godoc.org. You didn't cite that quote. I am certain whoever said it is doing something silly.

I did cite it - it's from my parent comment's link: http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-r... Are you saying that: * Getenv doesn't return an empty string for a non-existent env var? * Go JSON parser doesn't return an empty list given an empty string? That you can handle errors without exceptions needn't have an existence proof... The question is how many errors are silenced. Stats will be hard…

And here I thought you were talking about the first example in the blog:

    fmt.Println("Hello, world")
Now what happens when program opens a file and is run without stdout:

    ./program >&-
The file it opens is fd 1 and the program prints to the file instead of printing to the console. An odd case that has caused security holes in the past. In languages that fail on errors if they print anything before opening the file then they don't corrupt the file.

The default and laziest case for errors should never be to just hide them and continue on.

Post reply on HN