Live data from Hacker News

Half a decade with Go

blog.golang.org

111–120 of 257 posts

Re: Half a decade with Go

#111
post #88

Earlier quoted context omitted.

The underlying assumption is that the problem that modern programming languages should solve is lack of power. But I don't see that problem in modern codebases. In my experience, the problem is complexity.

I think in this case more power might be a good proxy for less complexity: power should correlate positively with expressiveness, and expressiveness should correlate negatively with complexity. More expressiveness lets you build more powerful abstractions with less code.

> expressiveness should correlate negatively with complexity

I don't see why that would be true. In my experience, the most expressive languages often produce the most impenetrable spaghetti code. Can you explain your reasoning?

Re: Half a decade with Go

#112
post #4

> , we were calling Go a "systems language" And maybe in another 5 years, people will stop bickering over whether that description is/was appropriate. :)

They won't stop, they will only pause... so that they can spend some time bickering over whether or not lack of generics makes Go unusable.

Re: Half a decade with Go

#114
post #99

Earlier quoted context omitted.

your "should" and "should" should be replaced with "doesn't" and "doesn't" or at best "may" and "may". more code has been written in Go than Haskell, Rust and Ocaml combined.

So what? More code has been written in C and Java than Go and Rust and Ocaml and whatever-else combined. A language's popularity says little about its complexity or how good of a language it is. Powerful languages let you grapple with problems, weak languages first make you grapple with the language before tackling problems. Some people feel like Go gets in the way. I have not written any Go, but I understand both th…

You're being a little vague. Can you give a couple examples where software projects were done in "powerful languages?" I can certainly appreciate that higher level languages are better. However, it seems like in practice they are not used as often as you would hope.

Re: Half a decade with Go

#115
post #22
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.

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…

Clojure has all of this in core.async - which is just a library, it doesn't need special support from the underlying language.

goroutines are certainly nice and CSP is a good mental model for solving many problems, but I don't think a feature like this should be used to justify switching to a whole new language.

Re: Half a decade with Go

#116
post #115
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…

Clojure has all of this in core.async - which is just a library, it doesn't need special support from the underlying language. goroutines are certainly nice and CSP is a good mental model for solving many problems, but I don't think a feature like this should be used to justify switching to a whole new language.

What? No. You could not be more wrong. core.async does not support the first point in the least.

Don't believe me? Make a go block in core.async and have it call another function, then have that function block. Do it 10,000 times. I'll wait. And wait. And wait. And wait...get the picture?

Clojure has this in Pulsar, which is a library...that happens to perform bytecode modification to support this (which I consider to be on the same level as special support from the underlying level). Pulsar is an absolutely amazing project and I'm not trying to take anything away from it with this comment, but merely trying to illustrate how far off you are.

Re: Half a decade with Go

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

Rust is avoiding the contrib problem by shipping a robust package manager from the beginning and pushing much of the Rust stdlib (and language features) into libraries.

http://crates.io/

Re: Half a decade with Go

#119
I would really like to see go binaries that is not like a 1mb in size.

In practice is not like I don't have space for 1MB

But I still want proper linking to a shared "golib"

Re: Half a decade with Go

#120

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…

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. :)
Post reply on HN