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…
Half a decade with Go
61–70 of 257 posts
Re: Half a decade with Go
#62Earlier 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?
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
#63OK, 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…
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
#64Earlier 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.
Re: Half a decade with Go
#65Earlier 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.
Re: Half a decade with Go
#66Earlier 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.
Re: Half a decade with Go
#67Earlier 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").
But to call someone a "blub programmer" does come off as quite rude.
Re: Half a decade with Go
#68Earlier 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.
Re: Half a decade with Go
#69Earlier 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.
Re: Half a decade with Go
#70Earlier 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.