Live data from Hacker News

The March Towards Go

zef.me

101–110 of 217 posts

Re: The March Towards Go

#101

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.

> Python falls through because it doesn't have real lambda.

No it doesn't. Been using it for about 10 years can't remember being bothered by lacks of "real lambdas"

> There are minor details wrong with JavaScript. Normally you don't encounter them in daily use.

If there would be minor detail we wouldn't have had the "Good Parts" book. And trying to deals with variables in Javascript is pain, var vs no var, what does this do. Really strange weak typing rules.

Adding [] to {} should not produce some random value (what is it NaN or Object), it should throw an exception.

> Few other languages can match it's simplicity.

Wait, were you being sarcastic?

Re: The March Towards Go

#102
post #31

Earlier quoted context omitted.

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…

JSON parser does return an error on empty string. http://play.golang.org/p/DE0soRRRBp

Bam!

Re: The March Towards Go

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

> Lack of decent IDE with intellisense/good refactoring > support. Sublime Text + GoSublime; vim + go-vim. > Libraries seem to be globally shared between projects > like rvm rather than in the project like nvm. There's no fixed rule. If you need dependable reproducible builds, current best-practice is to vendor your libraries in your repo.

Is VIM considered an IDE?

I am aware it is powerful and has as many features as an IDE but seems like it will take a fair bit of time to learn (on top of learning a new language). Eclipse is fairly intuitive by comparison.

Re: The March Towards Go

#104

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.

Your username is very apt

Re: The March Towards Go

#105
post #94
post #66

Earlier quoted context omitted.

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.

Go's type system being weak is a factual statement. Haskell's type system being overcomplicated is an opinion. Calling one weak and the other overcomplicated are both completely subjective, biased statements. And no, some random blog doesn't count as a citation: There are zero legitimate, agreed to sources that will back up your definition. Instead it's people painting broad strokes to bias the world towards their ow…

Are you aware that the notions 'weak' and 'strong' are actual terms used to describe type systems [1] ? Did you bother to look that up before going overboard and immediately accuse me of bias? I don't program in either Go or Haskell.

Now whether Go's type system actually has the property of 'weak'ness is very debatable. But whether it is true or false, it remains a factual statement.

[1]: http://en.wikipedia.org/wiki/Strong_and_weak_typing

Re: The March Towards Go

#106
post #94
post #66

Earlier quoted context omitted.

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.

Go's type system being weak is a factual statement. Haskell's type system being overcomplicated is an opinion. Calling one weak and the other overcomplicated are both completely subjective, biased statements. And no, some random blog doesn't count as a citation: There are zero legitimate, agreed to sources that will back up your definition. Instead it's people painting broad strokes to bias the world towards their ow…

[deleted]

Re: The March Towards Go

#107
post #87

Earlier quoted context omitted.

> 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

You could call the compiler slow, but at runtime it's comparable to Java (= fast!).

Re: The March Towards Go

#108
post #64

Earlier quoted context omitted.

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

Scala 2.12 will have a new compiler backend which should speed things up considerably. [1] Other than that, as an avid Scala fan, I've been long wondering why people favour Go so much. Arguably, if you've started out with RoR, then Node.js was a great improvement (dynamic typing with awesome speed). Then came Go, which solves many of the issues you tend to encounter with Node.js. So now, after it has reasonably matur…

Compared to Scala, Go is incredibly simple, both to learn and to use. If you don't have a lot of experience with Java and the JVM, Go also avoids that whole avalanche of complexity, apart from Scala itself.

Re: The March Towards Go

#109
post #105
post #94

Earlier quoted context omitted.

Go's type system being weak is a factual statement. Haskell's type system being overcomplicated is an opinion. Calling one weak and the other overcomplicated are both completely subjective, biased statements. And no, some random blog doesn't count as a citation: There are zero legitimate, agreed to sources that will back up your definition. Instead it's people painting broad strokes to bias the world towards their ow…

Are you aware that the notions 'weak' and 'strong' are actual terms used to describe type systems [1] ? Did you bother to look that up before going overboard and immediately accuse me of bias? I don't program in either Go or Haskell. Now whether Go's type system actually has the property of 'weak'ness is very debatable. But whether it is true or false, it remains a factual statement. [1]: http://en.wikipedia.org/wiki…

You should read the first sentence in the page you linked. To make matters even worse, none of the "weak" notions even apply to Go, and I thought you were talking about something entirely different altogether given that Go is by zero definitions, colloquial or not, "weakly typed".

The post that set this off called Go's type system "weak". They were not saying that it was weakly typed.

Post reply on HN