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

61–70 of 402 posts

Re: The State of Go

#61

Post by nicolast »

hlandau wrote: post #22
greg7mdp wrote: post #7

My impression is that Go is a language that was cobbled together to simplify the coding of some specific applications, such as simple servers. It lacks any kind of purity, is not the best choice for any specific task, but is just good enough for some (many?) tasks. And poor type safety! Frankly, I can't help being disappointed by how bland this language is, and I have zero interest in using it. Maybe because I like c…

Personally I like Go; it's a very fun language for me. It's true that it sometimes feels like a language designed for the precise purpose of writing daemons, but that's exactly why I like it. The thing about Go is that its opinions on concurrency are ones I share, to the point where I was practically waiting for something like Go to be invented. Other than say, Erlang, I'm not aware of many alternatives which provide…

> Other than say, Erlang, I'm not aware of many alternatives which provide a) ultra-cheap coroutines (10,000 coroutines? fine!), b) an I/O system which is seamlessly integrated with that concurrency system (and in a totalitarian manner at that; if you're using Go, you're using its event-based I/O scheduler, no exceptions), and c) a rock-solid runtime.

GHC Haskell.

Re: The State of Go

#62

Post by rpercy »

stefano wrote: post #54
rpercy wrote: post #28

Earlier quoted context omitted.

Heh, it does feel repetitive. But after ~10 years with Java, I'm happy to avoid the cognitive load from deciding how to most politely generate/propagate an exception. Obviously, there's no perfect solution, and preference is subjective.

It's the same cognitive load, really. Instead of deciding how to best propagate exceptions, you're now deciding how to best propagate the error value.

Not really. In a language like Java, some of the questions I'd have to ask myself are:

  - Should I try to catch the exception, or just let it 
    bubble up and edit my interface to include it?
  - Should I create a new exception type or reuse an existing one?
  - Should I throw a checked or unchecked exception?
  - Am I exposing implementation details via my interface? 
    (eg I don't want to throw an SQLException from GenericDataSourceWidget.connect())
In golang, I know there's really just the one pattern: check if err != nil, prepend a descriptive message, and return it.

Re: The State of Go

#63

Post by closeparen »

user5994461 wrote: post #60
tyre wrote: post #55

Earlier quoted context omitted.

Ruby came out in 1995, 22 years ago. It is neither young nor immature.

Of course I mean ruby on rails when I say ruby. Initial release 2005. i.e. Young.

Are you using Struts or something?

How could a 12-year-old framework not be old enough for you?

Re: The State of Go

#64

Post by pythonist »

joaodlf wrote: post #14

I don't share some of the opinions I see in the comments here. I've recently started programming in Go and I am having a blast. Plus, I am making my systems faster and simpler with Go. I love concurrency in Go. I love the concept of Goroutines, the simple and intuitive use of Select. Channels still present a few mysteries here and there... But I'll get it at some point. But the n#1 thing for me in Go is: It's written…

I completely agree. Go made me enjoy programming again.

Re: The State of Go

#65

Post by MichaelGG »

rpercy wrote: post #10
grabcocque wrote: post #6

The best summary I read recently is that go isn't a bad language, nor is it a particularly good one. What fascinates me is the way the Golang community have concretised that essential middle-of-the-roadness as the language's prime virtue. That, of course, has long been Java's prime virtue as well. (see Blub Paradox) By putting "we're okay with being okay" as your Big Thing you're clearly pitching for that vast bulk o…

Do you have an example of the community celebrating mediocrity? My impression is of a community willing to go without some features, in order to preserve those it values. Namely simplicity, explicitness, terseness, and consistency.

Explicitness and terseness seem a bit at odds - I wouldn't call go code very terse at all. It seems verbose and repetitive. Consistency? Aren't only some built in types blessed with generic functions?

Mediocrity? The preference for writing loops over simple maps or folds is a bit mediocre. IIRC in Tim Sweeny's "Next Mainstream Programming Language"[1], he notes that around 90% of all the loops in Unreal are folds or maps. Maps and folds are just simpler than loops, without even appealing to terseness and elegance.

Hey I know I'm in no place to judge -- the creators of go and Google overall have accomplished more than I'll ever do. I just really cannot grasp the mindset and penchant for unexpressive languages.

1: http://lambda-the-ultimate.org/node/1277

Re: The State of Go

#66

Post by stefantalpalaru »

labrador wrote: post #41
greg7mdp wrote: post #38

Earlier quoted context omitted.

How can you write an efficient container without generics?

I keep reading this and I keep wondering what's stopping someone familiar with language design from writing generics code

You can have your generics and many other nice things combined with the gccgo goroutines, channels and garbage collector by switching to Nim: https://github.com/stefantalpalaru/golib-nim

Re: The State of Go

#67

Post by MichaelGG »

user5994461 wrote: post #58
rpercy wrote: post #35

Earlier quoted context omitted.

100% agree re: readability (as I've mentioned elsewhere). I've actually been very surprised at the near-ubiquity of Go in the modern infrastructure/tools space though. Seems like each new OSS product I evaluate is written in Go. See companies like Cloudflare, Hashicorp, InfluxData, CoreOS, and, obviously, big projects like Kubernetes.

Go is meant for distributed systems. All these companies, and generally speaking a lot of infrastructure thing is in that domain. They use the right tool for the job.

Can you elaborate on why Go the language is "meant for" distributed systems?

Re: The State of Go

#68

Post by sidlls »

grabcocque wrote: post #6

The best summary I read recently is that go isn't a bad language, nor is it a particularly good one. What fascinates me is the way the Golang community have concretised that essential middle-of-the-roadness as the language's prime virtue. That, of course, has long been Java's prime virtue as well. (see Blub Paradox) By putting "we're okay with being okay" as your Big Thing you're clearly pitching for that vast bulk o…

"Good" and "bad" aren't really useful descriptors without additional context. And what do you mean by "mid-quality" developers? That seems gratuitously insulting.

Re: The State of Go

#69

Post by cube2222 »

candiodari wrote: post #59
rpercy wrote: post #28

Earlier quoted context omitted.

Heh, it does feel repetitive. But after ~10 years with Java, I'm happy to avoid the cognitive load from deciding how to most politely generate/propagate an exception. Obviously, there's no perfect solution, and preference is subjective.

In reality Go makes it worse, if you truly keep track of all possible cases. After calling a method, in Go you have to 1) "if err != nil" after every statement 2) give some serious thought to whether the previous statement could panic or not Good luck if it's a library call that may get updated or call other libraries ! 3) Think about the non-error error cases that can't be abstracted out. Go is like C, in the sense…

Panic is pretty much never used (so you don't really have to think if the previous statement can panic. If it does it means something is SO wrong that your application can't continue anyways because it's broken)

You should really use a library like github.com/pkg/errors so you get to wrap the error you return with additional information. Errors are just a worse Either monad after allm they're much more pleasant to use than exceptions.

Re: The State of Go

#70

Post by sidlls »

MichaelGG wrote: post #65
rpercy wrote: post #10

Earlier quoted context omitted.

Do you have an example of the community celebrating mediocrity? My impression is of a community willing to go without some features, in order to preserve those it values. Namely simplicity, explicitness, terseness, and consistency.

Explicitness and terseness seem a bit at odds - I wouldn't call go code very terse at all. It seems verbose and repetitive. Consistency? Aren't only some built in types blessed with generic functions? Mediocrity? The preference for writing loops over simple maps or folds is a bit mediocre. IIRC in Tim Sweeny's "Next Mainstream Programming Language"[1], he notes that around 90% of all the loops in Unreal are folds or…

Maps and folds are implicit loops. For some explicit is simpler.
Post reply on HN