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

The State of Go

talks.golang.org

Post reply on HN
Print view View original

201–210 of 402 posts

Re: The State of Go

#201

Post by nvarsj »

chimeracoder wrote: post #189
yawaramin wrote: post #180

Earlier quoted context omitted.

> But I strongly reject the criticisms that Go is meant for "mediocre" programmers, for programmers without experience in functional languages, ... It's not a criticism, it's literally how the Go language creators themselves describe it. See the Rob Pike quote at http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-in...

> It's not a criticism I'm responding to criticisms in this and other HN threads about Go, so yes, I'm talking about a criticism. > it's literally how the Go language creators themselves describe it. See the Rob Pike quote Unless you think Rob Pike is saying that Google is hiring mediocre programmers (hint: he's not), that statement is intended as a criticism of academics ("researchers"). He's saying that the same th…

> Unless you think Rob Pike is saying that Google is hiring mediocre programmers (hint: he's not),

Actually that's exactly what he's saying - although "inexperienced" is probably a better word than mediocre.

Golang is the modern blub language. It's really great for large companies and big code bases used by many people who want to get quickly up to speed. A decent, even new, programmer can get up to speed and be very productive in Golang in a matter of weeks. I can go and read the Kubernetes code base, which is huge, and know exactly what's going on pretty quickly, despite the complexities in that codebase like code generation and massive concurrency.

A language like Rust on the other hand would take months before someone can be seriously productive in it. That has a very real cost. It's sacrificing short term productivity for the long term benefits.

I think for a big company like Google, with so much staff, many inexperienced, and relatively high turnover (lots of people leaving and going constantly), a language like Golang is perfect.

At a small hedge fund, where you have maybe a dozen or two lifers, investing in a more strategic language like Haskell, Rust, OCaml, etc. starts to become viable.

Re: The State of Go

#202

Post by twic »

Keyframe wrote: post #196

One thing I never understood with Go was what's the deal with multiple return values in functions? Why would you do this? What was the reasoning?

One of Go's other design decisions is signalling failures by returning errors. Multiple return values makes it possible to do that and also return a real value.

If you didn't have multiple return values, you would have to do something ugly: C-style pseudo-return via a passed-in pointer, or returning an error or a value as an interface{} and requiring the caller to type-switch on it. Or add a special case to the language to somehow allow an error return alongside a normal return. Multiple return makes this straightforward and uniform.

Re: The State of Go

#203

Post by nvarsj »

Keyframe wrote: post #196

One thing I never understood with Go was what's the deal with multiple return values in functions? Why would you do this? What was the reasoning?

My guess is it comes from its C language roots, where every method returns an error code. With multiple return values, you can return an error code and the return value. This is a nice improvement over having to do my_func(in, &out).

Re: The State of Go

#204

Post by jrs95 »

prodigal_erik wrote: post #146
bboreham wrote: post #71

Earlier quoted context omitted.

Container as in "Docker container"

That's just a jailed process. There's no reason to need a completely different language, especially one without any specific support for running untrusted code.

Well clearly that isn't a requirement, it just so happens that Docker, rkt, and most related technologies are all built with Go. etcd even uses grpc

Re: The State of Go

#205

Post by Retric »

dvirsky wrote: post #162
hota_mazi wrote: post #150

Earlier quoted context omitted.

> When I moved from Python to Go not only did my code become more safe, I actually became a better programmer. This is probably more due to the fact that you moved from a dynamically typed language to a statically typed one rather than this new language itself.

But Go really does encourage good practices. I came to Go after programming in C, C++, Java and a bunch of dynamically typed languages. After a couple of years with Go I returned to C (and a bit to Java). And I'm writing better code in those languages now. Now, part of it is natural progress probably. But especially when I'm writing C, I can tell that I'm writing it much better than before because I'm adopting back s…

I suspect every time you move to a different language family you learn new things. I did C/C++ and Java then worked with an old Pascal codebase of all things that IMO taught me more than most other languages. Even XSLT taught me quite a bit.

Re: The State of Go

#206

Post by jrs95 »

twic wrote: post #195
Qerub wrote: post #110

Earlier quoted context omitted.

I usually get rid of @EnableAutoConfiguration and then selectively import the auto-configuration classes I actually want with @ImportAutoConfiguration.

A Spring developer once mentioned, on a mailing list post i have long since lost, that the autoconfiguration stuff is pretty much demo-ware. It's good for getting a simple app up and running fast, but for anything serious, you should import the configurations manually, exactly as you say. Fortunately, that's an easy enough transition to make at any point in a project's lifetime.

I don't think I'll be working with it again in the near future but I'll definitely have to keep that in mind in the future.

Re: The State of Go

#207

Post by chimeracoder »

yawaramin wrote: post #200
chimeracoder wrote: post #189

Earlier quoted context omitted.

> It's not a criticism I'm responding to criticisms in this and other HN threads about Go, so yes, I'm talking about a criticism. > it's literally how the Go language creators themselves describe it. See the Rob Pike quote Unless you think Rob Pike is saying that Google is hiring mediocre programmers (hint: he's not), that statement is intended as a criticism of academics ("researchers"). He's saying that the same th…

OK. I should have said, it's not inherently a criticism, it's just a fact. That others may choose to use it as a criticism--well, that's upto them. Personally I don't think there's such a thing as a 'mediocre' programmer, I think there are programmers who have studied and trained in concepts, techniques and idioms and those who haven't. It seems pretty clear from that quote that Google is hiring kids fresh out of col…

> I think there are programmers who have studied and trained in concepts, techniques and idioms and those who haven't

Which is really just talking in circles, because as I've now said in three consecutive comments, I have quite extensive experience with functional programming, and so I'm rejecting the argument that Go is simply for people who don't have that experience.

> And in fact, I also don't see how you can derive a criticism of academia out of those quotes when they mention 'researchers' only in passing, as a point of comparison to talk about their coders' skill level.

It's probably because, in five years of writing the language, I've had the opportunity to hear Pike (and others) talk about the topic. So when I'm responding, I'm drawing on that body of knowledge to inform what I'm saying, rather than limiting myself to a single quotation cited on a blog post written by someone who (by his own admission) is very new to the language.

Re: The State of Go

#208

Post by andrewprock »

pvg wrote: post #166
vvanders wrote: post #155

Earlier quoted context omitted.

Normally it's the other way around, Go gets compared to other "Systems Programming" languages because somehow services got lumped in with that name over the last few years. To me they're very discrete things, if you can't manually manage memory(raw pointers and the like) then it's not a System Programming language.

I think you have this backwards. 'Systems programming' has never meant 'operating systems'. To believe that Go is misdescribed as a 'systems programming' language you have to believe Rob Pike doesn't know what 'systems programming' means.

Given Pike's extensive experience inside a world of his own making (Plan 9 and Go), it's entirely reasonable to attribute the misconception that Go is a system language to Pike's idiosyncratic use of the phrase.

If I understand things correctly, Go came about as fallout related to the non-scalability of Python and the massive technical debt associated with Python within Google. The projects to automagically port Python code to Go code are a clear indicator that Go was at least in part imagined as a replacement for Python.

I personally wouldn't describe Python as a systems language, but some might.

Re: The State of Go

#209

Post by twic »

geoka9 wrote: post #184
kuschku wrote: post #161

Earlier quoted context omitted.

Because the stdlib is using them more and more? As someone mentioned, even closing an already closed channel can panic. Calling the random number generator with a negative limit panics. And there’s nothing like checked Panics so you’d know if one will happen or not.

I see nothing wrong with that - those _are_ fatal conditions that indicate that something is dangerously wrong in the program. And those panics do give you a helpful stack trace, complete with source code line numbers, so it's easy to find the culprit (as opposed to "bubbling up" exceptions).

These uses of panic look a lot like the canonical use of unchecked exceptions in Java: the programmer has made an error, which they could have avoided. It's a bug. There's no point returning an error and letting the program try to recover, just blow up with as much information as you can, so the bug can be fixed.

The canonical use of checked exceptions in Java is for unpredictable events - almost always related to interaction with the outside world, like IO, networking, parsing, etc. These are things the programmer can't prevent, and must defend against, so the type system allows, and in fact forces, the programmer to explicitly address them.

This is all explained beautifully, and at length, in this monograph:

http://joeduffyblog.com/2016/02/07/the-error-model/

Re: The State of Go

#210

Post by fnl »

Golang really seems to have come a long way. But what holds me back from using it are the dangers of deadlocks and segfaults (due to forgotten error handling) that might be introduced even inadvertedly if applied to industrial-scale projects (say, 1M+ LOC, 10+ developers). That is, I see many small (server/microservice) projects flourish with Golang, and it seems an excellent replacement for certain types of C projects, but I wonder how Go enthusiasts believe it could scale to compete with Java or C++, due to the way it does error handling, and deadlocking issues with channels.
Post reply on HN