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

211–220 of 402 posts

Re: The State of Go

#211

Post by Keyframe »

twic wrote: post #202
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 langu…

Alright, that actually makes sense. Thanks.

Re: The State of Go

#212

Post by tigershark »

oscargrouch wrote: post #147
Taek wrote: post #137

Earlier quoted context omitted.

In my experience writing go is very fast and reading go is also very fast. The language was designed to be very comfortable, and they did a great job with that. You sit down to write something and you don't have to think too much about the best way to tackle the problem, the lines of code just flow from your fingertips. There's mostly one way to do everything, which makes doing things easy. Code review is much the sa…

And those are the secret ingredients of a great language for team programming. And thats why Go will dominate the market that once was meant for Java.

I really hope not, there is already a lot of awful code around written in Java. I can't imagine codebases on the MLOC range written in a language even worse than java 1.4 (it didn't have generics, but at least it had exceptions)

Re: The State of Go

#213

Post by cube2222 »

leshow wrote: post #168
cube2222 wrote: post #69

Earlier quoted context omitted.

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 us…

> Errors are just a worse Either monad after allm they're much more pleasant to use than exceptions. How are errors in Go at all monadic? They just have a convention where you return a tuple and manually check if something isn't nil. Either type will inhabit one variant or another, not both with one having a value of nil. The 'monadic' part of Either (or Result in something like Rust, where try! is sort of like >>= i…

As I said, in practice they're a worse either monad. With which I meant -> they were inspired by them, but lack the monad part and having the value with the error in one object interchangeably. It's the same treating errors as values though.

Re: The State of Go

#214

Post by cube2222 »

kuschku wrote: post #161
geoka9 wrote: post #101

Earlier quoted context omitted.

> 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) That's it. I think OP just assumed panics in Go are what exceptions are in other languages.

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.

As I said, if your code is plainly wrong then I see no problem in it going haywire. The channel rules are widely known -> you know, it takes more than a few days to learn a language, there are a few rules to learn too.

Calling a number generator with a negative limit is also a programmer fault, so no reason to provide an error here.

Re: The State of Go

#215

Post by bsg75 »

geoka9 wrote: post #95
aeturnum wrote: post #86

Earlier quoted context omitted.

When I think about Go in comparison to other languages, I think of car metaphors. Lots of people talk about cars that are good. Some people think a good car is fast, some people think a good car is low maintenance, some people think a good car is eye-catching. They are all right, those are all descriptors of good cars. Go, however, is like a Toyota Corolla or a Honda Civic. It's dependable, but relatively plain. It's…

Using a similar metaphor, I'd compare Go with a jet that's high performance but easy to fly - i.e. it doesn't have the numerous gotchas and quirks high performance jets usually have that the pilot has always have to keep in mind to avoid shooting themselves in the foot (aka making a hole in the ground :)). E.g. it won't let you overload your engine by using a very special feature that lets you get away with it, but i…

Maybe a turboprop metaphor?

https://warisboring.com/stop-disrespecting-the-turboprop-c00...

https://news.ycombinator.com/item?id=13461948

Re: The State of Go

#216

Post by bsg75 »

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

Java reigns supreme because there is nothing which come close to its characteristics in terms of capabilities, libraries supports, tooling, performances, easiness to learn, simplicity and maturity. If you want faster or lower level, you gotta move to C++, which is uber-hardcore in terms of non-simplicity and impossible-to-learn. If you want easier, you gotta move to python/ruby/node.js, which are a joke in terms of p…

That is due to maturity / age, and at one point Java was the new kid on the block.

Re: The State of Go

#217

Post by bsg75 »

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…

> It lacks any kind of purity

Example of lack of purity?

Re: The State of Go

#218

Post by _arvin »

notforgot wrote: post #115

Question: who is going to remember all these conversion rules? By the second bullet you lost me. Simply run the command below: go tool fix -diff -force=context state-of-go/tools/gofix.go How is typing 59 characters simple?

How lazy are you?

Re: The State of Go

#219

Post by bsg75 »

greg7mdp wrote: post #38
jrs95 wrote: post #12

Earlier quoted context omitted.

It's used very heavily for everything container related. It seems to be an excellent fit there, at the very least. It's also becoming an increasingly popular choice for startups when they need performance, which used to be something Java or C++ were typically used for. Personally I've had a lot of fun using it, but prior to starting with it I'd mostly done Java and Node, so that may have something to do with it.

How can you write an efficient container without generics?

Use a language that has generics.

Snarky, but its such a tiresome argument. If you need something Go does not supply, use a language that fits your needs. There are a lot of programmers happy in Go, and thus happy without generics.

There are programmers who are happy using generics, thus write in Rust, Java, etc.

There is no language to bind them all.

Re: The State of Go

#220

Post by JepZ »

j2kun wrote: post #56

I'm concurrently learning Go and Node, which might not be a fair comparison but I'm going to make the comparison anyway. Node feels like a flesh wound with delicately layered bandaids. The ecosystem is a mess, you have to jerry rig basic packages to work together, the syntax and semantics of closures and context is ridiculous, and despite that callback mania is like this cool-aid that's supposed to feel great once yo…

Hehe, I have to underline this aspect as npm killed half an hour of my work yesterday, when I redownload some package in a sibling directory (for diff purposes).

Never had this experience with go. The comparison is a little emotional for me, but when I realized npm just killed my code, I was emotional...

Nevertheless, Javascript/Ecmascript is the result of years of development in a living environment (the web) while go was designed from scratch, by some of the most capable programming language designers on this planet, to enhance their previous work. Who wonders about the result?

Post reply on HN