Live data from Hacker News

The March Towards Go

zef.me

91–100 of 217 posts

Re: The March Towards Go

#91
post #65
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.

Even if it were true that it were overly complicated, that wouldn't change the fact that it's much more powerful than Go's. “When I work at this system up to 12hrs a day, I’m profoundly uninterested in what user interface a novice user would prefer.” —Erik Naggum Are you using visual basic because you could pick it up in 2 days instead of taking a month to learn Go? It's easy to learn because it doesn't do anything i…

> visual basic

Bringing The Language Which Shall not Be Named to the discussion is a low blow. But I deserve it. My phrase about overcomplication was flamebaity and uncalled for, and I apologize.

> you're missing out on simple beautiful abstractions like map and filter

The thing is, in Go, those take almost as much space as a plain for loop.

I know, you will tell me "that's because Go's too verbose". I will grant that it's more verbose than Haskell.

But I am not doing maps and filters all the time in my code.

> It's not possible to write a generic container without casts to interface{}, which is a shame imo.

My point is that generic containers are the feature where generics are genuinely needed. And in those cases interface{} makes it possible. Not super-awesome, but possible. I actually like that the language doesn't bend over to fulfill something that looks almost like an edge case. It is not "programming with mathematics". It's still "moving bits around". But the bits can be moved with ease.

Re: The March Towards Go

#92
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

People like Go because of all the things Go does well. Here is a few examples:

* benefits of static typing at low cost to the programmer thanks to type inference and duck-typing,

* intuitive and easy-to-use concurrency model based on channels and go routines,

* functions as first-class objects,

* very good performance,

* clean, concise and simple syntax,

* novel, low-overhead approach to build configuration based on the convention-over-configuration principle (your import statements express all there is to know about how to build your software),

* garbage collector.

I'm sure I forgot more.

Re: The March Towards Go

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

Because thanks to our experience with strong typed languages with native compilers and type inference, we know better.

Many of us have had the fortune to work with C, C++, Ada, .NET, Java, Delphi, Modula and Oberon derived languages, ML language family.

So we already know what modern strong typed languages, with native compiler toolchains, are capable of in terms of language features. And going Go feels a bit backwards.

Regarding Python, I never saw it more than a scripting language for system administration. ML based languages provided a better experience in terms of both performance and productivity.

Re: The March Towards Go

#94
post #66
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.

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

Just as unreasonably I could say that Go has a Clarified Type System, versus the Conundrum Type System found in Haskell.

Re: The March Towards Go

#95

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 is also slow.

Re: The March Towards Go

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

Thanks, sublime tex and vim with plugins are still a long way off what you get from a good ide. Just glancing there is no real refactoring support, its more around auto complete.

Re: The March Towards Go

#97
post #31
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…

JSON parser does return an error on empty string.

http://play.golang.org/p/DE0soRRRBp

Re: The March Towards Go

#98
post #29
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...

This blog post misses a very good Python replacement, namely Nimrod ( http://nimrod-lang.org ).

With the exception of speed, why does Python need a replacement?

I am using Python daily, and pretty much all performance problems (with my work) can be solved at the database or caching level. I get the impression that Numpy can produce reasonable performance for numeric problems.

In my experience developer productivity is of far more importance to business than language performance (obviously that depends on your domain). I do get asked to speed things up. But I get asked for "something working" by yesterday far more often.

Re: The March Towards Go

#99
post #62

Earlier quoted context omitted.

It is a rather vauge statement and could have used some clarification; however Go does make writing network protocols very simple, and building something like a gossip protocol based system with a leader election system is doable in a week. Even quicker if you use some of the existing distributed systems libraries for Go.

What does Go do that makes writing network protocols simple?

Go makes it straightforward to have one program efficiently communicating with many different servers and clients. It does this by having all network IO be event-based in such a way that it's effectively tied directly into the scheduler, and then communicating between the different goroutines managing all these connections is very easy.

Re: The March Towards Go

#100
post #93
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…

Because thanks to our experience with strong typed languages with native compilers and type inference, we know better. Many of us have had the fortune to work with C, C++, Ada, .NET, Java, Delphi, Modula and Oberon derived languages, ML language family. So we already know what modern strong typed languages, with native compiler toolchains, are capable of in terms of language features. And going Go feels a bit backwar…

.NET isn't a language.

The languages you list really suck compared to Go. They are ridiculously verbose. Goroutines in particular are really quite nice.

Post reply on HN