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

Six years of Go

blog.golang.org

Post reply on HN
Print view View original

281–290 of 327 posts

Re: Six years of Go

#281

Post by tptacek »

matthewmacleod wrote: post #170

I have a bit of a love-hate relationship going on with Go. On one hand, it addresses many of the pain points I've experienced with other languages. It's easy to build and deploy, reasonably performant, and has a powerful and consistent standard library. On the other… developing in it feels like a total slog. It manages to be simultaneously far too anal and overly forgiving about syntax. Visibility definition using up…

It's like most languages: if you go in hoping to write in the style of your favorite previous language, the language is going to resist you. Python does the same thing to you if you want to write in functional style. Ruby also punishes you if you want custom data structures (it's the Rails community that coined the term "golden path", right?). If you've got loads of duplicated code due to lack of generics, you may not be leaning as much on the design of the standard library as the language wants you to.

We've got a limit-order-book market with a FIX API and an HTTPS/JSON API, a bunch of market makers, an AVR emulator, a dispatcher to handle thousands of AVRs concurrently, a C compiler, HTTPS/JSON APIs to implement debug stubs for all of that, and a bunch of other random stuff --- and we have one (1) custom data structure --- the red-black tree we use for the order books themselves.

I'm a recovering C++ programmer and do not doubt for a moment that if Go had generics, I'd have availed myself of them. I'm not sure my code would be better for it, though.

Re: Six years of Go

#282

Post by tptacek »

tptacek wrote: post #141
aws_ls wrote: post #117

Earlier quoted context omitted.

Lets just put it this way, I bought onto the basic proposition which was offered, after having read Rob Pike's original blog introducing it, and having watched lots of Go team videos. Some points which also went into decision making: 1) I am not a functional language programmer. No disrespect, just stating fact, after having noticed a Lisp programmer having questioned my choice regarding "boredom". So languages like…

If everyone thought this way, our realistic professional choices of languages would be C, C++, and Perl. The exact same things you're saying about Go were things people said about Java --- a language, by the way, with much more harrowing ownership issues than Go, which is an open-source project top-to-bottom.

Gah! I just noticed that I replied to the wrong comment; I meant that for the grandparent. Sorry!

Re: Six years of Go

#283

Post by lobster_johnson »

tptacek wrote: post #280
lobster_johnson wrote: post #193

Earlier quoted context omitted.

I'm in the same boat. Go's simplicity is initially refreshing, then a huge pain once you find yourself writing the same thing over and over again. A good example is errors being values — which is a great idea. But then you realize every single function needs to be littered 1-10 cases of if err != nil { return nil, err } It's an extremely common pattern. It's tiring to write, over and over. Tiring to refactor, too: If…

I felt very much the same way about Go's error handling; that, coupled with straight-line synchronous-style socket programming, made me feel like I was writing the same dumb C code I did when I was a teenager in the mid-90s. I've come to believe that slicker error handling is a bit of a false economy, at least compared to other "informal" languages like Java, Ruby, and Python (all bets are off if you want to compare…

I think history has absolutely shown that exceptions are not the best solution; they don't scale, as you point out. And I agree with Go that errors are values, and should be passed around as such.

Go basically tells us that errors are as really important — they should be in your face and handled by the caller. And then it goes ahead and makes it a second-class citizen that is really awfully laborious to work with. Why not make error-handling a first-class construct?

Most code needs to just pass the error on to the caller, for example. Go would benefit from an easy way to just "bounce" the error off to the caller. Something like my naive, hypothetical macro in my previous comment.

Some sum-type-based solution like Rust's Result enum would also have made the whole problem pretty much moot.

Re: Six years of Go

#284

Post by jimbokun »

coldtea wrote: post #102
aws_ls wrote: post #64

It was early 2013, when we adopted Go as a default language for all our server side (micro or not) services. Before that we had been using Java for some years. The reason for the move were few: 1) Ambivalence on Java roadmap, in my understanding (gradual build up, since after the Oracle's Sun acquisition). Even the earlier clean java docs, suffered from Oracle branding efforts. Downloading older versions were confusi…

> It was early 2013, when we adopted Go as a default language for all our server side (micro or not) services. (...) The reason for the move were few: 1) Ambivalence on Java roadmap So, because there was some "ambivalence for the Java roadmap", a language with multiple implementations, a huge community (including open source), and so entrenched in the industry that will be there in 2100 too, you switched to a 3-4 yea…

You left out the key reason cited:

"2) Boredom after nearly a decade with Java programming."

Re: Six years of Go

#285

Post by coldtea »

artursapek wrote: post #266
coldtea wrote: post #260

Earlier quoted context omitted.

> It's funny that you mention Java because I have always avoided learning Java. Even from afar it grosses me out as a language. May I guess you're either some old Lisp/Smalltalk etc veteran, or, much more probably, someone who entered IT after, say 2005? Because back in the day very few thought of Java as "gross" -- it was greeted as a welcome change from the existing landscape which at its best was something like C+…

I'm 23, I haven't been around that long :)

Yeah, so the second case, someone who entered IT after 2005!

I guessed so, because back in the day (1995-early 00's) most devs outside of seasoned functional etc veterans (who were extremely few) or hardcore systems guys, saw Java in mostly positive light, and never considered it "boring" back then.

The change (for new devs to consider Java "boring" and lacking in features) happened sometime after 2005, with Rails entering, Javascript catching up, C# getting more features with 2.0 and 3.0.

(Consider than back then Scala, Go, Clojure et al weren't even started, and AJAX had just been made mainstream).

Re: Six years of Go

#286

Post by pcwalton »

lobster_johnson wrote: post #283
tptacek wrote: post #280

Earlier quoted context omitted.

I felt very much the same way about Go's error handling; that, coupled with straight-line synchronous-style socket programming, made me feel like I was writing the same dumb C code I did when I was a teenager in the mid-90s. I've come to believe that slicker error handling is a bit of a false economy, at least compared to other "informal" languages like Java, Ruby, and Python (all bets are off if you want to compare…

I think history has absolutely shown that exceptions are not the best solution; they don't scale, as you point out. And I agree with Go that errors are values, and should be passed around as such. Go basically tells us that errors are as really important — they should be in your face and handled by the caller. And then it goes ahead and makes it a second-class citizen that is really awfully laborious to work with. Wh…

> Go basically tells us that errors are as really important — they should be in your face and handled by the caller. And then it goes ahead and makes it a second-class citizen that is really awfully laborious to work with. Why not make error-handling a first-class construct?

Not only that, it's very easy to just dump errors on the floor, which is why Golang needs tools like errcheck.

For an easy example of this in practice (os.Setenv returns an error): https://github.com/search?l=go&q=os.Setenv&type=Code&utf8=%E...

Re: Six years of Go

#287

Post by Roboprog »

arbe wrote: post #129
aws_ls wrote: post #64

It was early 2013, when we adopted Go as a default language for all our server side (micro or not) services. Before that we had been using Java for some years. The reason for the move were few: 1) Ambivalence on Java roadmap, in my understanding (gradual build up, since after the Oracle's Sun acquisition). Even the earlier clean java docs, suffered from Oracle branding efforts. Downloading older versions were confusi…

honestly I have hard time comparing go to java and finding any valuable reason to switch from one to another. Go in my opinion was not mean for writing large/distributed web applications. But instead for writing tools (and fits very nicely in that space) and therefore replace C code base. If I had to write something like docker, go of course would be a natural choice for it. But If I had to write the next big social…

MAYBE. But maybe not: what if your app has a Javascript based rich client, and the back end is primarily micro-services? Does Java still shine for that kind of a stack? (OK, I would still avoid C, but that's not saying much)

Re: Six years of Go

#288

Post by jaytaylor »

chimeracoder wrote: post #114
aws_ls wrote: post #64

It was early 2013, when we adopted Go as a default language for all our server side (micro or not) services. Before that we had been using Java for some years. The reason for the move were few: 1) Ambivalence on Java roadmap, in my understanding (gradual build up, since after the Oracle's Sun acquisition). Even the earlier clean java docs, suffered from Oracle branding efforts. Downloading older versions were confusi…

> 1) Json/XML parsing is the easiest with no work (or minimal) required, you can just have the field names capitalized (or use stereotypes) and it gets done, with a line of code. Obligatory plug - if you're sick of writing out the struct definitions yourself, you can generate them from sample JSON: https://github.com/ChimeraCoder/gojson This is especially useful when implementing REST servers/clients, because you can…

I've used gojson several times and highly recommend it. Originally I'd planned to make the tool myself but found you'd already created precisely what I envisioned!

/me tips hat to you :)

Re: Six years of Go

#289

Post by Roboprog »

tptacek wrote: post #91
kasey_junk wrote: post #17

Earlier quoted context omitted.

> The prevailing feeling of Go is "getting things done". This is a common refrain amongst go proponents and I find it quite distasteful. It either implies those of us who prefer other languages aren't "getting things done" or those who feel productive in Go aren't smart/hard-working/educated/etc enough to "get things done" in other languages. I don't think either is true. I think a more accurate way to look at Go is…

I agree with you, but there is something to the argument; it's just poorly phrased as "getting things done". gofmt, for instance, is uncontroversial. Taking the decisions about how to format code away from developers and standardizing it is widely seen as a win (a win Python flirts with as well). Well, there's a lot of other things in Go that have been pre-decided for you, not just the formatting. The net effect is t…

Not a big fan of gofmt, but oh well. (I prefer more whitespace, both spaces and newlines, than K&R formatting would like)

Otherwise, the go built-ins are usually the "get on with it" win.

Re: Six years of Go

#290

Post by jgome »

forgotAgain wrote: post #276
jonesb6 wrote: post #244

Earlier quoted context omitted.

If there a paradigm for handling multiple potential errors in a function? I'm usually stuck using: reply, err := redis.Givemethevalue(key) if err != nil { return err } thing, err2 := postgres.getById(reply) if err2 != nil { return err2 }

I use var err error at the beginning of the function if needed.

This helps prevent variable shadowing when using :=, which is yet another weird feature of the language...

BTW, if you really want to make sure you don't make mistakes, use the compiler tools, or, better yet, https://github.com/alecthomas/gometalinter .

Post reply on HN