Live data from Hacker News

Half a decade with Go

blog.golang.org

61–70 of 257 posts

Re: Half a decade with Go

#61
post #53
post #50

Earlier quoted context omitted.

I don't think you're going to come around on it. It's not suddenly going to stop being terrible at abstraction. That essay seems very accurate and applies to Golang. The strengths of Go to me seem to be its extensive standard libary and the fact that you don't need to worry about writing elegant code because it's not really an option. That reduced decision making is actually really appealing to me on some level, but…

I dont know much about go, but I always thought that the problem with 'the standard library does everything' is that it starts to feel heavy and better alternatives pop up. Then you have these dark places in the library that most people avoid, and you cant really throw away. Clojure used to have something called, clojure contrib and it was kind of awsome, it did pretty much everything in just one jar. It was also a h…

I started using Clojure just after 1.3 came out so I could be wrong, but my impression was that while contrib was all in one place, it was still maintained by a bunch of random people who got their code into contrib, rather than being treated as a core part of the language the way (I believe) Golang's is.

Re: Half a decade with Go

#62
post #52
post #49

Earlier quoted context omitted.

Go is the only language that allows one to write very scalable TCP servers fast (i mean development effot). The servers are almost as fast as C (i.e. 15x Python), but the development time is like Python.

What about Julia?

Yeah, what about Julia?

which makes as much as sense as asking

- What about R? - What about GNU DAP? - What about FORTRAN?

for writing a TCP server.

Re: Half a decade with Go

#63

OK, I'll admit it. I've spent six months with Go. I keep waiting for the moment when I understand it, maybe even develop some enthusiasm for it, and reach Pike-enlightenment. And I pretty much hate the language. I feel like I'm writing in something that combines the worst weaknesses of Pascal and Java. In fact, Mark Dominus' comments about Java ( http://blog.plover.com/prog/Java.html ) approximate my experience Go fa…

> So I'll ask: What is it I need to read/work through in order to at least "get" Go and really understand its strengths (whether or not I end up liking it)?

I highly recommend to read this article where Rob lays out the motivation behind many aspects of Go: http://talks.golang.org/2012/splash.article

Re: Half a decade with Go

#64
post #41

Earlier quoted context omitted.

I'll try to represent Haskell here. 1. Totally, definitely. The new Haskell IO manager in GHC 7.8 completely blows this out of the water. It's wonderful. 2. You fork or async IO procedures which can be considered immutable values in their own right and passed around without the slightest concern. There is a small difficulty in that Haskell's laziness makes it a small trick to ensure that work gets done in the right p…

> The new Haskell IO manager in GHC 7.8 completely blows this out of the water. Go will still outperform Haskell by a huge margin and the typical Go process will have a much smaller memory footprint. I don't even like Go, but nobody choosing Go is realistically considering Haskell as an alternative.

I don't like go either, but I won't believe that a ghc webserver is a fast as a go webserver until we can see it in the techempower benchmarks.

Re: Half a decade with Go

#65
post #41

Earlier quoted context omitted.

I'll try to represent Haskell here. 1. Totally, definitely. The new Haskell IO manager in GHC 7.8 completely blows this out of the water. It's wonderful. 2. You fork or async IO procedures which can be considered immutable values in their own right and passed around without the slightest concern. There is a small difficulty in that Haskell's laziness makes it a small trick to ensure that work gets done in the right p…

> The new Haskell IO manager in GHC 7.8 completely blows this out of the water. Go will still outperform Haskell by a huge margin and the typical Go process will have a much smaller memory footprint. I don't even like Go, but nobody choosing Go is realistically considering Haskell as an alternative.

I'm not so sure that is true. I'd love to see some benchmarking, though.

Re: Half a decade with Go

#66
post #61
post #53

Earlier quoted context omitted.

I dont know much about go, but I always thought that the problem with 'the standard library does everything' is that it starts to feel heavy and better alternatives pop up. Then you have these dark places in the library that most people avoid, and you cant really throw away. Clojure used to have something called, clojure contrib and it was kind of awsome, it did pretty much everything in just one jar. It was also a h…

I started using Clojure just after 1.3 came out so I could be wrong, but my impression was that while contrib was all in one place, it was still maintained by a bunch of random people who got their code into contrib, rather than being treated as a core part of the language the way (I believe) Golang's is.

That's right. contrib was always the red-headed stepchild to core.

Re: Half a decade with Go

#67
post #60

Earlier quoted context omitted.

I get the impression some of the folks in the Golang crowd are "Blub" programmers [1]. It's not so much a matter of simplicity and trade-offs as it is a matter of "I don't need things I don't know about", which isn't a good argument to use Golang. [1] http://www.paulgraham.com/avg.html

"Blub" as a concept isn't really useful anymore. I've seen people attacked as "blub programmers" for criticizing Go for its lack of features. At worst it's a personal attack ("you are a short-sighted programmer"), at best it's kind of supercilious ("language X is great, it's just over your head").

I think "blub" is just another example of "you don't know what you don't know", which is always going to be relevant. And not everyone have tried, or intend on trying, obscure/sophisticated/mind-bending programming languages. And that's fine, since we all have different interests (as long as we don't try and pretend that we are very knowledgeable about something which we don't really have an interest in pursuing).

But to call someone a "blub programmer" does come off as quite rude.

Re: Half a decade with Go

#68
post #64

Earlier quoted context omitted.

> The new Haskell IO manager in GHC 7.8 completely blows this out of the water. Go will still outperform Haskell by a huge margin and the typical Go process will have a much smaller memory footprint. I don't even like Go, but nobody choosing Go is realistically considering Haskell as an alternative.

I don't like go either, but I won't believe that a ghc webserver is a fast as a go webserver until we can see it in the techempower benchmarks.

The Techempower benchmarks are using the old version of GHC, 7.6, and the Golang devs have been tuning Go's core libraries to win at this specific benchmark.

Re: Half a decade with Go

#69
post #55
post #48

Earlier quoted context omitted.

well, rust has all those powerful features. it's been out in the open for exactly as long as Go has.

Rust isn't nearly as stable as Go. It still hasn't reached the state that Go was in when it was released outside Google. That's not a judgment of Rust, just a result of it being developed in the open instead of inside a company, and it being much more ambitious than Go.

Go was released as an open source project on the 10th of November 2009. Which part of that is _not_ open to you in a way that Rust is ?

Re: Half a decade with Go

#70
post #55
post #48

Earlier quoted context omitted.

well, rust has all those powerful features. it's been out in the open for exactly as long as Go has.

Rust isn't nearly as stable as Go. It still hasn't reached the state that Go was in when it was released outside Google. That's not a judgment of Rust, just a result of it being developed in the open instead of inside a company, and it being much more ambitious than Go.

[deleted]
Post reply on HN