Live data from Hacker News

Half a decade with Go

blog.golang.org

71–80 of 257 posts

Re: Half a decade with Go

#71
post #22

Earlier quoted context omitted.

That's a reductive summary of goroutines. I don't doubt other languages have competitive features, but let's be clear about what the feature is: * Lightweight threads with a scheduling and state overhead low enough to run hundreds of thousands of threads at a time. * Seamless integration with the language, without any rituals or incantations needed to invoke them; you can, for instance, trivially pass closures from g…

Yeah, you could have said the same about Haskell. 'forkIO' in Haskell and 'go' in Go are essentially identical. You could also argue that Haskell's STM is even safer than using CSP channels (which also exist in Haskell) since you greatly decrease your chance of data races (while sacrificing some performance in cases where a transaction is often retried.) But in the end it doesn't really matter that much. Go and Haske…

>You could also argue that Haskell's STM is even safer than using CSP channels (which also exist in Haskell) since you greatly decrease your chance of data races

We actually have transactional and non-transactional channels as well, which is pretty cool.

Also the reason for using STM instead of channels is that they compose without the possibility of deadlock. You can have deadlocks with channels.

Re: Half a decade with Go

#72

Shameless promotion in case you don't read OP. We're posting an article every day on blog.gopheracademy.com celebrating the use of Go around the world. http://blog.gopheracademy.com/birthday-bash-2014/go-turns-5/

The RSS feed of this Blog is broken :(

Thanks. Should be fixed now.

Re: Half a decade with Go

#73
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 encourage you to look a the benchmarks published here: http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask03... which includes Haskell beating nginx and Haskell beating SDN controllers written in C++ and in Java.

Re: Half a decade with Go

#74
post #49

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…

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.

For the record, Go does not allow you to operate on fd, so some fine tuning TCP parameters does not happen unless you do reflection magic and use SysCall. Which is PITA compared to Python.

Re: Half a decade with Go

#75

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…

Going by Paul Graham's "Blub" essay (http://www.paulgraham.com/avg.html), I'd say the problem is that languages like Go and Java are simply not high in the rankings when it comes to power.

Re: Half a decade with Go

#76
post #49

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…

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.

There are numerous options for writing very scalable TCP servers on the JVM e.g. Vertx.

Then you have the option of using Java, Clojure, Scala, Ruby, Python, Javascript or Groovy languages.

Re: Half a decade with Go

#77
post #56
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 0.1 came out in the beginning of 2012, about 3 months before Go 1.0 game out (or go1). In the meantime, Rust has changed a lot and is only now close to a 1.0 release.

FWIW, Rust has been on github since June 2010.

Re: Half a decade with Go

#78
post #55

Earlier quoted context omitted.

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 ?

Externally, it certainly seems that Go was open sourced in a far more finished state, with only relatively small tweaks after the initial release, while Rust was quite raw and has had most of its fundamental design work done in the open (with significant contribution from volunteers, both code and design) after being placed on github in 2010.

Re: Half a decade with Go

#79
post #21

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

Most Go programmers I know, including the language designers themselves, have a lot of experience in more feature rich and expressive languages. What appeals is the simplicity of Go, which gives you a lot less of a language to think about, so you can just think about solving problems instead. “I like a lot of the design decisions they made in the [Go] language. Basically, I like all of them.” – Martin Odersky, creato…

Martin has something nice to say about everyone's project. I seriously doubt he likes that a new language was created in 2009 that allows null references. But we'll never hear about it if he doesn't. Still, that doesn't make him a Go programmer.

Re: Half a decade with Go

#80
post #51
post #27

Earlier quoted context omitted.

I feel like you haven't met a lot of Go programmers in that case. The programmers I have met who use Go or are interested in it are often genuinely good programmers. Of course there are "crowd" followers in any language as popular in Go but Go is not a "Blub" language nor does it attract Blub programmers. Do I as a Go programmer sometimes wish that Go had feature X. Of course I do! I want that feature when I want tha…

>Macros are of course enormously useful but also very difficult to shoe horn into a c-family language properly since they need to be expanded at compile time (unless you just go ahead and embed you compiler backend into the runtime system of your language. No, that's not necessary at all, with Rust-like macros which are simple pattern->template things. Macros have zero runtime cost.

I totally agree I made this point badly.
Post reply on HN