Live data from Hacker News

The March Towards Go

zef.me

31–40 of 217 posts

Re: The March Towards Go

#31
post #25
post #12

Earlier quoted context omitted.

Incidentally, your link includes a great example of Go's error handling - which is inevitably what actually happens in languages without exceptions: errors are silenced and the program marches on, each step making less sense than the previous. It's a good talking point that you can always check error values - but it never really happens, in part because library designers try to avoid putting the burden on themselves…

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 to come by. But getenv and JSON parsing are pretty basic functionality and in most languages with exceptions they would not silence errors. (say, Python's json.loads barfs and os.getenv returns None which unlike the empty string will almost certainly lead to an exception if the code won't account for None). So it's a good anecdote in the absence of hard data.

Re: The March Towards Go

#32
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 don't understand why people like go. It seems to be missing a lot of features and be pretty ugly and painful.

In other words, you have been reading about it, but never tried to learn it.

Go is incredibly easy to learn and prevents bugs and cruft as much as possible, makes writing documentation and testing painless and has good performance and concurrency support.

It also has a friendly, practically-minded community.

Re: The March Towards Go

#33
Zef writes this as if it's completely amazing that people are leaving Node for Go. Node is based on JavaScript. There are arguably more things wrong with JavaScript than with any other popular programming language, as evidenced by book titles like "JavaScript, the good parts". This is common knowledge; we're all trying to do good work despite JavaScript, seldom because of it. So Node: it's fast, we can share code with the browser, but it's a bitch to use. We knew that when we signed up.

Conversely, Python is a great language but it's not as easy to make it go fast. It's slow, but it's great to use. We also knew that when we signed up.

It's great that Go is getting more mainstream adoption! Deservedly so. But it's probably still easier to be super-productive developing a CRUD app in Ruby or Python. And it's still easier to share code between backends and web frontends with Node. If you don't need either of that, and you do need performance, then, yes, maybe you shouldn't pick Python or Node.

I agree that Go is a great option to consider, but Zef is framing it a little as a silver bullet, and well, of course it isn't.

Re: The March Towards Go

#34
post #11

Earlier quoted context omitted.

Scala? Strong static types, lots of quality libraries both for Scala and 'inherited' from Java. Fits well among the languages you already mention.

Nice. I've heard some complaints about compile times -- are they founded?

Yep. Compile times are comparatively long - the larger the project, the more this is an issue. For me it's not a deal breaker.

Re: The March Towards Go

#36

So I understand there isn't a go package manager like pip/npm/cpan. Is that correct?

go get behaves in some ways as package manager (installs packages), it's up to the developer how it will vendor them or lock versions.

Re: The March Towards Go

#37
I was kind of expecting this. Although I like Go (and prefer it to NodeJS), I hope forthcoming feedback on TJ's "life choices" does not degrade into a "Let's move from Node to Go" echo chamber.

More importantly, I hope the Node community's self-centred "holier than thou" doesn't bleed over, given that Go has (at least so far) kept a fairly high standard of discourse.

That said, I, for one, welcome more contributors to the Go ecosystem. It is a good systems programming language, but it needs a few more "horizontal" libraries to make humdrum tasks (like parsing, accessing databases, etc.) more palatable.

(edit: removed incorrect double negative)

Re: The March Towards Go

#38
post #5

> Statically linked binaries make for easy deployment They certainly do, but have we solved the problem of statically linked bugs yet? What happens when the next heartbleed happens?

Redeploying your entire infrastructure should take on the order of minutes.

Re: The March Towards Go

#39
"In the past week I’ve rewritten a relatively large distributed system in Go"

Maybe I don't have any programming talent at all, but I cannot even imagine to rewrite a 'large distributed system' in a week. The not-too-large distributed systems I worked with had years of thinking behind them, I could not even type in the characters of the code in a week.

Re: The March Towards Go

#40
post #14

I've often heard that Go founder were surprised that Go seemed to replace python more than C++ or C which were the initial targets. By judging from the given examples it seems that it isn't the case : people seem to come to Go when they start looking for performance. Instead of writing C modules and using them from python, they just switch everything to Go. I'd be curious to know how many start ups prototype their fi…

Dropbox switch to Go? Where did you read that? If anything they seem to be "investing" in the Python ecosystem[1].

[1] https://tech.dropbox.com/2014/04/introducing-pyston-an-upcom...

Post reply on HN