Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Half a decade with Go

blog.golang.org

Post reply on HN
Print view View original

131–140 of 257 posts

Re: Half a decade with Go

#131

Post by ansible »

Animats wrote: post #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…

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.

If I could go back in time, and discuss one thing with the designers, it would be to fix this.

I'd rather see some kind of Option type (like in Rust) baked deep into the language. Maybe there would be a scheme where you could use these Option types as regular values. The moment you try to use one of them that is actually an error (trying to pass it as an argument to another function without inspecting it first for example), it causes your current function to return an error.

Or something like that. Maybe that's a language design change that isn't going to be worked out in a social media post.

The "defer" mechanism is clunky.

I like defer. Open a file? Defer close it right afterwards in the code. Bam, done! That's nice, and works even if there was a panic deeper in the call stack somewhere.

The idiomatic way to do that in Go, however, can mask errors, like say if Close() returned an error, you might not see it if you just did a 'defer foobar.Close()' Those errors should go somewhere... somehow.

Re: Half a decade with Go

#132

Post by Svip »

stinos wrote: post #127
MetaCosm wrote: post #102

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…

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…

I think the point here is implicit inheritance. There are many interfaces in Go, but you don't need to specify which interface you are implementing. So you can easily implement io.Reader and io.Writer among many others, without extending your type declaration for lines on end.

This means that many standard types in Go implements either io.Reader and/or io.Writer. That's neat. The implicit interface implementation is definitely a language feature, and the libraries are making good use of it.

(That is not to say, you could not do the same in other languages, but you would have to specify the interface they implement rather than just adding a method with a specific layout.[0])

[0] I am not remembering the right term right now.

Re: Half a decade with Go

#133

Post by lmm »

enneff wrote: post #111
reverius42 wrote: post #90

Earlier quoted context omitted.

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?

Consider e.g. traverse, which is a function you simply can't write in a language without higher-kinded types. Several times I've written half a page of code only to realize "that's just traverse" or "that's just foldMap" or so on. In a less expressive language I would've had to leave that half-page as is. Surely that means the expressiveness results in more readable, less complex code?

Re: Half a decade with Go

#134

Post by _pmf_ »

MetaCosm wrote: post #102
wwweston wrote: post #39

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…

> Now what makes this little function so darn useful is it takes anything fulfilling its interfaces (io.Writer and io.Reader).

I've implemented InputStreams from byzantine transport layers in Java that work with the standard library. I don't quite understand what is special about this concept in Go (maybe it's nice for people coming from typeless, messy dynamic languages or nice languages with horribly inflexible and ad-hoc standard libraries like Python and Ruby).

Re: Half a decade with Go

#135

Post by lmm »

timtadh wrote: post #27
wcummings wrote: post #18

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

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…

Languages without decent compile-time type systems are pg's own blub.

Re: Half a decade with Go

#137

Post by lmm »

jshen wrote: post #126
wwweston wrote: post #44

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. 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?

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

We are. WhatsApp generated a flurry of interest around Erlang. Heroku uses it. I'm sure there are more examples.

Google is at this point already a large corporation and probably already in decline (IMO). The tools they use are optimized for interchangeability of mediocre programmers, not for high productivity from a small team. Go is a perfectly good Java 1.4.

(There's Docker using Go, but I think their whole approach is a bad idea).

Re: Half a decade with Go

#138

Post by Elrac »

wwweston wrote: post #39

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…

Maybe unlike other respondents, I'm a Go amateur. I've written three projects in Go, one of a few thousand lines and two of a few hundred. Also unlike many others, I consider Go un-elegant to the point of being ugly. In other words, I'm no expert and no fanboy.

What makes Go my go-to language for certain kinds of projects (I'll doubtless be using it again) is that it gets shit done. It has the brutal simplicity and hardware proximity (and raw speed) of C combined with the small handful of things that most significantly contribute to make Java better than C: A simple type system, garbage collection, usable string handling and dynamic data structures (arrays and hash maps). Go also has a fairly large, useful library.

Multiple return values often including errors make error/exception handling very explicit and in-your-face. When something can go wrong, you the programmer are forced to recognize that and deal with it as soon as the function returns. That's a Good Thing IMO. Java-style exception handling, by comparison, looks to me like an elaborate language hack for passing the buck.

There's a ruthless kind of efficiency in Go's surrounding philosophy. There's one way to format Go code, you let the utility take care of it and never worry about formating again. The compiler won't tolerate various kinds of sloppiness, such as unused imports.

As somebody else mentioned, in Go, writing elegant code is not a consideration because it's nearly impossible. Well, I'm sure there are "better" and "worse" ways to write Go code, but not so obviously that I'd be tempted to give it a lot of thought. So I tend to just sit there and write code by the bucketful until I'm done.

Finally, the tooling gets the job done, and quickly. I can compile for and across various hardware environments and ship executables that don't rely on a JVM or other external dependencies.

Re: Half a decade with Go

#139

Post by ExpiredLink »

Why are language discussions so futile? Because people choose platforms, not languages. Platforms have one main language (in some cases two) which becomes the language of (no) choice for the developers.

Platform examples: Host (Cobol, PL/1), Unix (C), Embedded (C), classic Windows (C++, VB), .NET (C#, VB.NET), Java EE (Java), Android (Java), ... Rails (Ruby), PHP (PHP), Browser (JavaScript).

The choice is always between platforms, not between languages. Languages without linking to a platform (Go, Python, Scala, D, Rust, ...) have little chance to succeed.

Re: Half a decade with Go

#140

Post by gaius »

ExpiredLink wrote: post #139

Why are language discussions so futile? Because people choose platforms, not languages. Platforms have one main language (in some cases two) which becomes the language of (no) choice for the developers. Platform examples: Host (Cobol, PL/1), Unix (C), Embedded (C), classic Windows (C++, VB), .NET (C#, VB.NET), Java EE (Java), Android (Java), ... Rails (Ruby), PHP (PHP), Browser (JavaScript). The choice is always betw…

Because people choose platforms, not languages.

No, because a language is not (just) a technology, it's a community, and as such, people invest their identities in it. If possible you make an enlightened choice about joining a community that shares your ideas and values and is doing similar kinds of work to you, so they are producing libraries and documentation and hosting relevant and interesting conferences. I often feel that people who lash out at other languages, are people who have come to regret their own choice of community.

Post reply on HN