Live data from Hacker News

Half a decade with Go

blog.golang.org

121–130 of 257 posts

Re: Half a decade with Go

#121
post #92
post #12

Earlier quoted context omitted.

What do you think is worthwhile about Go? I agree that the tooling is nice, but beyond that, there is nothing interesting to me. Goroutines aren't interesting; languages like Erlang and Haskell got green threads right many years before Go was on the scene.

The difference is I can read Go code while having no experience with it. Erlang and Haskell are inscrutable to 90% of programmers. If you think this isn't important, I will point out that Rust has been frantically trying to look more like Go and less like garbage in every release. Or, I will also point out that the Elixir project exists, which basically does the same thing for Erlang.

Rust is not "frantically trying to look more like Go". There are places where Rust's syntax deliberately differs from that of Go (for example, putting colons between values and types), and that will not change.

Re: Half a decade with Go

#123
post #12
post #10

At launch, there was a flurry of attention. Google had produced a new programming language, and everyone was eager to check it out. Some programmers were turned off by Go's conservative feature set—at first glance they saw "nothing to see here"... This was totally me. I am very much a programming language aficionado (or maybe just a dilettante), and when I first read about Go, I dismissed it quickly. I'd mostly been…

What do you think is worthwhile about Go? I agree that the tooling is nice, but beyond that, there is nothing interesting to me. Goroutines aren't interesting; languages like Erlang and Haskell got green threads right many years before Go was on the scene.

What do you think is worthwhile about Go?

Simplicity - the main feature is all the interesting things they left out.

Re: Half a decade with Go

#124
post #17

You still need a Makefile if you use things like godep, or their new `go generate` stuff. They have a long way to go on tooling; however, getting to say that is a luxury, due to just how "right" golang has been for systems work. Golang has been amazing to work with, and has just been stupidly productive. I miss debugging (gdb) and generic compile tools like tup, but that's about it!

Do people prefer not using Makefiles? I ask because Makefiles are a standard part of my workflow, and while I know I can 'go build' or 'go [whatever]' I still cling to my Makefiles as a preferred tool.

I like make, and get a kick out of possible interesting successors, like tup and redo. I forced myself to stick to "go build" when starting out with go, and I'm glad I did...more time working on what I'm working on, less time fiddling with the build system. I'd recommend it, at least until you really hit its limitations.

Re: Half a decade with Go

#126
post #16

Earlier quoted context omitted.

You should ponder why Erlang or Haskell achieved a fraction of Go's adoption despite being on the market 20+ years longer. Some people see languages as a bag of features (immutability! generic programming! laziness! operator overloading! algebraic types! hindley-miller type inference! pattern matching! exceptions! manual memory management!). See http://yager.io/programming/go.html for an example of that line of think…

> You should ponder why Erlang or Haskell achieved a fraction of Go's adoption despite being on the market 20+ years longer. This line of thinking serves more to call in to question the engineering and management cultures we have than it does to reflect poorly on Haskell and Erlang, and if it's true that Go's essential strength compared to them is that it is well-fitted to these cultures, that's not particularly flat…

If languages like Haskell and Erlang gave a competitive advantage, wouldn't we see companies which used them succeeding over those that don't?

Maybe Go is fitting into the cultures that succeed, and if that's the case, well it's the better choice, right?

Re: Half a decade with Go

#127

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…

Composition. That is the single biggest thing that has impressed me as my codebase has grown. Concurrency and messaging is nice, but I come from Erlang... I am not easily impressed by concurrency and messaging. Composition, the power of interfaces in complex systems is the key for me. It is what makes me stay with Go, and why I will probably stick around for a long time. It is so obnoxiously useful, without ever gett…

Composition

I read your comment, but this seems more like A sane standard library with proper interfaces and not a language feature per se (also composition to me sounds like the pattern where you create objects which are composed of other objects but that's not what you mean, right)? What you display here can be done in pretty much any language suporting inheritance (or I'm missing something), so your point is those languages don't have io.Copy out of the box?

Re: Half a decade with Go

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

Go seems to be an iteration of Rob Pike's previous languages, Limbo and Newsqueak - perhaps with a sprinkling of other ideas, but not much.

Rust on the other hand has been a far more ambitious project, with very lofty goals. This has meant that the Rust team has needed to do a huge amount of experimentation and iteration, culminating in the tight set of core semantics that you see in the language today. It's not been an easy journey for the them, but a great deal has been learned in the process, and even if Rust never 'makes it' into widespread usage, its contributions to the field of programming language design will be felt for years to come.

This is not to diminish the efforts of the Go team - they have produced a really tight, polished language, with an excellent set of bundled libraries. All I'm saying is that they weren't starting from scratch, and had different goals to the Rust team. That has meant they could get to a stable language much faster.

Re: Half a decade with Go

#129

Earlier quoted context omitted.

Composition. That is the single biggest thing that has impressed me as my codebase has grown. Concurrency and messaging is nice, but I come from Erlang... I am not easily impressed by concurrency and messaging. Composition, the power of interfaces in complex systems is the key for me. It is what makes me stay with Go, and why I will probably stick around for a long time. It is so obnoxiously useful, without ever gett…

I NEED to work Go into one of my projects, but dammit I love Python so much. it is a warm and safe and comfortable cocoon. :)

I loved python and wouldn't've given any of it up. Then I switched to Scala and discovered how much I could get the computer to do for me, without giving up the conciseness, readability and expressiveness of Python.

Re: Half a decade with Go

#130
post #42

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…

What weaknesses of Pascal are being repeated in Go?

There is no escape. The language thinks it knows better than you. The standard library is allowed to do things that your code isn't.
Post reply on HN