Live data from Hacker News

The March Towards Go

zef.me

51–60 of 217 posts

Re: The March Towards Go

#51
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?

There's a difference between "the language has long compile times" and the implied "you spend a lot of time waiting during development".

It is true that Scala's compile times are long, but the tooling provides ways so that you don't have to wait so much during development.

Re: The March Towards Go

#52
post #9

There are a couple of things which have stopped me getting into go which I am ignorant about. - Lack of decent IDE with intellisense/good refactoring support. - Libraries seem to be globally shared between projects like rvm rather than in the project like nvm. Am I wrong, misguided or out of date on these things?

LiteIDE is nice, gosublime also. There is GO plugin for IntelliJ, but I haven't tried it yet.

Libraries can be vendored in many ways(virtualenv(gopm), bundler like patching env(goop) or simply by manipulating GOPATH)

Re: The March Towards Go

#53
post #19
post #13

Earlier quoted context omitted.

As far as I know, Go already has a really strong static type system (int32 cannot be assigned to int for example). Which parts are weak?

No generics (parametric polymorphism), no algebraic data types. You should learn some Haskell or Ocaml even if you don't plan on using it in production. Go's type system is weak. Edit: I don't think there's anything like type classes either but I'm not 100%.

[deleted]

Re: The March Towards Go

#54
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…

It's not surprising that people motivated by performance would arrive to Go from languages that are slower. C/C++ developers would certainly not use that argument in favour of a switch given that matching C/C++ performance is a non goal for Go.

There are other reasons C++ developers might have to switch to Go; that's what Rob Pike was referring to when he said that he was surprised that Go wouldn't replace C++. He didn't mean that Go failed to replace C/C++ as the target of optimization from slower languages, but failed to replace C/C++ for those who were already using it.

Go has been explicitly designed to avoid the perceived pitfalls of C/C++ from their experience at Google. It's not a language that fixes C++ like D or Rust, but tries to get to the root of the problem, and the problem they identified was complexity.

Re: The March Towards Go

#55
TL;DR It is very likely that TJH is a hive mind.

FYI some question TJ Holowaychuk's 'person.' A glance at his github commits would lead you to believe he is some open source prodigy, but there is a curious case being built (share=1 trick, no Quora login needed): http://www.quora.com/TJ-Holowaychuk-1/How-is-TJ-Holowaychuk-...

Re: The March Towards Go

#56
post #8
post #4

Go may well be better for many apps than js or C++, but there are other languages out there. If you're looking for a new language it's worth considering more possibilities, e.g. see http://roscidus.com/blog/blog/2013/06/09/choosing-a-python-r...

Go has a larger and more active eco-system for today's world.

Larger than...? It's comparable to Node's, certainly smaller than JS in general, much smaller than either python's or C++'s.

Re: The March Towards Go

#57
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…

I could get behind the Go compiler to forcing people to write "_ = errReturningFunc()" instead of simply "errReturningFunc()" if they want to explicitly ignore errors. In my recent experience, it actually bothers me a lot that funcs in the standard library would often rather return nil or the zero-value of a type than change the signature of the func to return (T, err). I don't really care that the docs describe that…

The thing is, compilers can force people to refer to error variables, but they can't prevent people from returning array[0] when i is out of array[]'s bounds, an empty list given an empty JSON string, etc. And forcing the former unfortunately only encourages the latter.

Re: The March Towards Go

#58
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 communi…

Or: It doesn't fit the parents taste.

Re: The March Towards Go

#59

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 wit…

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.

Re: The March Towards Go

#60
post #19
post #13

Earlier quoted context omitted.

As far as I know, Go already has a really strong static type system (int32 cannot be assigned to int for example). Which parts are weak?

No generics (parametric polymorphism), no algebraic data types. You should learn some Haskell or Ocaml even if you don't plan on using it in production. Go's type system is weak. Edit: I don't think there's anything like type classes either but I'm not 100%.

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

Post reply on HN