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

151–160 of 402 posts

Re: The State of Go

#151

Post by Groxx »

cdelsolar wrote: post #148
Groxx wrote: post #91

Earlier quoted context omitted.

> check if err != nil, prepend a descriptive message, and return it. That'd be the RuntimeException equivalent, sure. But what do you do for the equivalent of checked exceptions? Errors are frequently recoverable, "err != nil" alone does nothing to help you there, and string manipulation is a horrific alternative to types.

You can have typed errors too. This is fairly common in Go. As long as it implements the Error interface.

At which point you're back to the original complaint of:

  - 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?
  - Am I exposing implementation details via my interface? 
    (eg I don't want to throw an SQLException from GenericDataSourceWidget.connect())
(except for "- Should I throw a checked or unchecked exception?" since that's fairly Java-specific)

To me, those questions seem unavoidable, and sweeping them under the rug is a false simplicity. You're exposing things - what do you expose? How should the caller deal with it? Is it the same as [other thing]? I'd much rather have the type system involved, since error handling is pretty critical to correctness/stability. If go's giving up the safety, what does it get in return?

Re: The State of Go

#152

Post by jiaweihli »

nicolast wrote: post #61
hlandau wrote: post #22

Earlier quoted context omitted.

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.

Also Akka for Java/Scala.

Re: The State of Go

#153

Post by ashark »

Taek wrote: post #137
ptero wrote: post #21

IMO the Go goal is to be an enhancement of C. It is not as expressive as some existing languages (i.e., Go programs may be longer), but it is very good for translating clearly thought through logic into efficient machine code. It supports some of the features that original C lacks (networking, parallelism, channels, etc.), which to me is a very good thing. With minimal forethought this allows writing programs that ca…

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…

The legibility and simplicity are my favorite things about Go. I know that I can fearlessly dive into other people's source to figure out what's going on without running into 15 levels of indirection hell and a bunch of language features/idioms that I'm not familiar with for one reason or another.

Re: The State of Go

#154

Post by kuschku »

bitexploder wrote: post #73
rpercy wrote: post #23

Earlier quoted context omitted.

To each their own. I enjoy writing Go almost as much as writing Python. But more importantly I find reading Go easier than any other language - mostly due to its explicitness and consistency between authors. That has made it much easier to dig into code bases that solve some very complex and interesting (to me, anyway) problems. Also, I assume the 'no type safety' statement is just hyperbole?

They probably mean you can use interface{} and create a typing black hole if you really wanted to. Otherwise, I don't know.

Or maybe they mean that you HAVE to use interface{} for any reasonable kind of generics, such as developing generic data structures, or generic handlers for RPC interfaces allowing arbitrary nesting?

Even the stdlib uses interface{} everywhere now: https://tip.golang.org/pkg/sort/#Slice

Re: The State of Go

#155

Post by vvanders »

IshKebab wrote: post #77
rpercy wrote: post #30

Earlier quoted context omitted.

I'm with you. IMHO, Go's simplicity is its biggest virtue. It has fostered a community that values consistency and clarity over syntactic sugar. And, as a result, I find each new codebase extremely accessible.

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.

Re: The State of Go

#156

Post by hota_mazi »

rpercy wrote: post #28
aczerepinski wrote: post #8

Earlier quoted context omitted.

But if you like typing `if err != nil` it's actually the most fun language.

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.

> I'm happy to avoid the cognitive load from deciding how to most politely generate/propagate an exception

This is like saying "I'm happy to avoid the cognitive load of having to specify how my code should behave in case of an error".

Sure, your code is simpler as a result. It's also more buggy.

Re: The State of Go

#157

Post by _ak »

aczerepinski wrote: post #8
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…

But if you like typing `if err != nil` it's actually the most fun language.

It makes cyclomatic complexity explicit that is otherwise hidden by exceptions.

Re: The State of Go

#158

Post by niuzeta »

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…

> and having it readily available with a Ctrl+click in VS Code

I haven't used VS Code since the beta, but it can do that now? Wow. I should give it a try.

Re: The State of Go

#159

Post by chias »

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.

Not sure why this is being downvoted without comment, considering that it is what accounts for the example that the parent comment chose.

Re: The State of Go

#160

Post by omginternets »

aeturnum wrote: post #86
artursapek wrote: post #20

Earlier quoted context omitted.

What on earth is a "good" language? > you're clearly pitching for that vast bulk of mid-quality developers that make up the huge middle chunk of corporate devs That was actually something Google aimed for with Go, and I don't see what is shameful about it. It's a simple language on purpose. It is meant to be easily learned by any developer, and similarly Go code is meant to be easily read. Also, what sets Go apart fo…

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…

>Go is a useful language, but it's a language that has purposefully stripped out all the magic. People like magic, they miss it.

Agreed, and I'd further argue:

1) most people driving Ferraris aren't skilled enough to drive them properly

2) most people driving Ferraris have no need to corner at 120 MPH

3) most people driving Ferraris are just trying to show off

4) most people driving Ferraris are more likely to hurt themselves and others than to save the day through the car's performance and handling

(To be clear: I think we're in agreement, but the metaphor is worth explaining in depth)

Post reply on HN