Live data from Hacker News

Half a decade with Go

blog.golang.org

91–100 of 257 posts

Re: Half a decade with Go

#91
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'm digging into cmake, because it's the one supported by clion, and I don't think I'm going back to make.

Re: Half a decade with Go

#92
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.

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.

Re: Half a decade with Go

#93
Sometimes I wonder: if Apple's new language had been Go, and Google's new language had been Swift, how would reaction by developers and adoption have differed? (You can also run this thought exercise with Go and Rust, if you prefer a different competition between self-proclaimed systems languages.)

Re: Half a decade with Go

#94

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…

It may just not fit for you. I feel the same way about C++ -- I understand the strengths of a pay-for-what-you-use language with a ridiculously powerful template library, but it just never came naturally to hand for me.

Re: Half a decade with Go

#96
Go has a rather specific purpose. It's intended for writing server-side web systems that will run fast and scale well. Since that's what Google does to make money, that makes sense. The available libraries reflect this - good support for dealing with many network connections at once, no GUI support.

It's not suitable for writing an OS, hard real time, highly generic libraries, or GUI programs. Within its niche, it's far better than the alternative, which is usually C++. Just the fact that it eliminates buffer overflows without running slow is enough to justify it.

There are lots of problems with Go. The concurrency isn't safe. The lack of generics forces overuse of reflection and "interface{}", Go's all-purpose type. The lack of exceptions forces far too many lines of "if err != nil { return err}", (or worse, a goto) which takes 3 lines of text every time. The "defer" mechanism is clunky. Lots of modern bells and whistles, from functional programming to generators, were omitted. Other than the lack of safe concurrency, those things don't cause operational problems in your data center. They just require more typing by the programmers. That's an acceptable cost. It beats spending time in a debugger.

Re: Half a decade with Go

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

Erlang has the first two concepts nailed down. I don't know what "data sharing ... with promiscuous threading" is, but Erlang is functional and immutable, so data sharing only exists in the sense of passing immutable data structures around. Synchronization issues associatied with mutations don't exist for in-memory structures since it's all read-only access. I don't know Haskell's concurrency tools very well, but I b…

Also don't ets tables do that, #3 I mean? Where different processes can access the same data structure? You can even control what process read or write to it. It is pretty neat.

Re: Half a decade with Go

#98
post #89

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…

If you have spent six months, is that just occasionally tinkering and reading things online, or actually using it fairly regularly? If you have developed software in go, and after a couple months you aren't finding its saving you time, or at least pleasant to work with, maybe its not for you. I feel like it is similar to C, but more opinionated, with much less rope to hang yourself, and often things I would have used…

> I find the code is also pleasant to read

This, to me, is what he's missing. On the continuum between readable and expressive, Go falls decidedly on the readable side. If you're working on a project by yourself for 6 months, you might not like Go. But if you work on a team or return to code you wrote 6 months ago and haven't touched since, that's when you'll appreciate Go.

Evaluating languages based on simple solo projects will always favor the more expressive languages, but it's a short-sighted evaluation.

Re: Half a decade with Go

#99
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.

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.

Re: Half a decade with Go

#100
post #77
post #56

Earlier quoted context omitted.

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.

rust was announced the same week Go was. it took a while to bring to the open, but it got the "swoon" demographic under its wing almost immediately.
Post reply on HN