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

161–170 of 402 posts

Re: The State of Go

#161

Post by kuschku »

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

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

Re: The State of Go

#162

Post by dvirsky »

hota_mazi wrote: post #150
seagreen wrote: post #136

Earlier quoted context omitted.

Maybe it's because I don't have the "depth" of some of the HN users, but Go feels great to me. I doubt I have any more depth than you as a programmer, but I've gone one step farther than you down the language safety progression, so maybe my thoughts from here will be interesting. When I moved from Python to Go not only did my code become more safe, I actually became a better programmer. There are a lot of silly thing…

> 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 some idioms that Go encouraged me to adopt in the first place.

Also, because Go's standard library is so well written, you can learn from the best very easily, and understand what's going on. It's certainly not the case with other languages I write in.

Re: The State of Go

#163

Post by niftich »

vvanders wrote: post #155
IshKebab wrote: post #77

Earlier quoted context omitted.

Definitely. Simplicity, and fantastic standard library. Go is like a much faster and more reliable version of Python. People comparing it to C++ and Rust miss the point.

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.

Go gets compared to "systems programming" languages because its designers specifically intended it to be used as such [1][2], albeit the definition of 'systems' they are using is deliberately evolved from the original shade of meaning as suggested by low-level languages that are sometimes deemed to be for 'systems programming' to illustrate that the nature of environments has changed, and a new approach is advantageous.

[1] https://talks.golang.org/2012/splash.article [2] https://golang.org/doc/faq

Re: The State of Go

#164

Post by sidlls »

vvanders wrote: post #155
IshKebab wrote: post #77

Earlier quoted context omitted.

Definitely. Simplicity, and fantastic standard library. Go is like a much faster and more reliable version of Python. People comparing it to C++ and Rust miss the point.

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.

And further, in my view, if manual memory management is extraordinarily difficult a language is not necessarily a good candidate for systems programming.

Re: The State of Go

#165

Post by Cthulhu_ »

skybrian wrote: post #83
MichaelGG wrote: post #65

Earlier quoted context omitted.

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…

The preference for maps and folds looks like a fad to me. I can use them but I don't think it makes the code any easier to understand, just different.

It does though. Maps and folds - and functional programming in general - focuses on the /what/. For-loops on the other hand tell the compiler / cpu the /how/.

Summing is a nice example. A naive for-loop will just iterate through the list, keep a variable around, add the next item in the list to it. In functional programming (or with a reduce), you tell it to sum in a more concise way - but more importantly, you don't tell the compiler how exactly it should do it. It's trivial with functional programming to make the task (for example) multithreaded or to use advanced underlying cpu tricks, without you as a developer needing to know how exactly it does what you ask it to.

Re: The State of Go

#166

Post by pvg »

vvanders wrote: post #155
IshKebab wrote: post #77

Earlier quoted context omitted.

Definitely. Simplicity, and fantastic standard library. Go is like a much faster and more reliable version of Python. People comparing it to C++ and Rust miss the point.

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.

Re: The State of Go

#167

Post by Buttons840 »

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

I've been thinking about a two way compiler with a primary focus on producing readable code. If such a compiler targeted Go or Java, you could white your "Go+" code (for lack of a better name) in a higher level language with more features, and have it compiled to readable Go code. I don't know to what extent this is possible, but if it was good enough you could be a Go developer while rarely writing actual Go code.

Re: The State of Go

#168

Post by leshow »

cube2222 wrote: post #69
candiodari wrote: post #59

Earlier quoted context omitted.

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 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 >>= if you squint) is the ability to chain Either types together and have the boilerplate abstracted, that feature is completely absent from Go. Errors in Go are neither the Either type nor monad, IMO.

Re: The State of Go

#169

Post by prodigal_erik »

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

> Maybe it's because I don't have the "depth" of some of the HN users, but Go feels great to me. I've been writing Go full-time as my primary language for nearly five years. Before that, my languages of choice were Lisp[0] and Python, with R as a very distant third choice[1]. I have always been a polyglot and enjoyed experimenting with any new language I could try out - you'd be hard pressed to name a non-esoteric la…

>I strongly reject the criticisms that Go is meant for "mediocre" programmers

I don't know how else to describe people who don't resent being second-class citizens under the library designers, who don't insist on being able to create their own abstractions and use them with the operators that slices or maps support. The language has extensible interfaces but doesn't use them for things like iteration and equality.

Re: The State of Go

#170

Post by Cthulhu_ »

sidlls wrote: post #72
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.

I'm not convinced that using startups as a metric for anything programming related is a good idea. At least not startups here in the Bay Area, which seem to me to be very fad driven.

Today's startups are tomorrow's huge stack of legacy software that Nobody Wants To Touch Because It's Our Core Business though; I'd say Go is a pretty good choice for those due to its simplicity and shunning of 'clever' code. Companies like Paypal, Ebay, and probably a few others have (had?) a huge load of old Java code and only recently spent a lot of time cleaning that up (iirc Paypal went with Node, at least for its forward-facing things)

I don't know how maintainable 10-year old Ruby code is though, on the other hand.

Post reply on HN