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

Toward Go 2

blog.golang.org

Post reply on HN
Print view View original

371–380 of 670 posts

Re: Toward Go 2

#371

Post by fixermark »

dmit wrote: post #234
johansch wrote: post #142

Earlier quoted context omitted.

You mean have the compiler modify the source code files destructively? Then I'll have to disagree, that just doesn't make sense.

There was a precedent in Haskell land: https://twitter.com/bos31337/status/116372971509121025 A more modern implementation: https://github.com/munificent/vigil

`gofmt -w` also already exists, it just (a) has to be run as a separate step and (b) doesn't have full cross-file understanding of the program.

Since we have version control now, I don't see any threat from an optional capacity for the compiler to destructively mutate the source as an optional feature. Let the same toolchain that converts input to output suggest improvements to the input.

Re: Toward Go 2

#372

Post by kibwen »

the_duke wrote: post #148
saghm wrote: post #35

Earlier quoted context omitted.

I haven't programmed in Go, but from what I understand, Go's explicit error handling isn't enforced by the type system, as you can leave off an `if err { ... }` check and everything still compiles. I think adding a generic result/error type (like the Result type in Rust or the Either type in Haskell) would be a pretty useful feature, as currently the error handling sits in kind of a weird place between forced handlin…

I have no idea why you are being downvoted. In Rust, this was handled the right way. The Result type forces you to at least actively dispose of the error. In Go, it's just way too easy to leave an error unhandled.

> The Result type forces you to at least actively dispose of the error.

Sort of: by default, an unused value of the `Result` type produces a compiler warning. Like all warnings in Rust, this category of warnings can be promoted to a hard error for all users with a single line of code. And unlike other languages where compiler warnings are uniformly ignored, there is a strong culture in Rust of making sure that code compiles warning-free (largely due to the fact that the compiler is rather selective about what to issue warnings about, to help avoid useless false positives and warning spew (there is a separate project, called "clippy", for issuing more extensive warnings)).

Re: Toward Go 2

#373

Post by threeseed »

olivierva wrote: post #355
osteele wrote: post #217

Earlier quoted context omitted.

That's what kept me from looking at the language for the last five years. I finally broke down and wrote my first Go program. Yeah, the errors (and lack of generics) are annoying, but it gets enough else right – tooling, runtime speed, compilation speed, type inference, parametric polymorphism (on interface types) – that I enjoyed it anyway. Every language has some annoyances; it's nice when there are only a few.

And don't forget simplicity as a core design feature of the language. That alone is worth sacrificing generics for ;-)

Who gets to decide what is simple or not though ?

Coroutines seem like something that is more complex to me than generics.

Re: Toward Go 2

#375

Post by XorNot »

pmarreck wrote: post #351
43224gg252 wrote: post #313

Earlier quoted context omitted.

Not only that, but you can just ignore errors during prototyping and with a little editor magic you can go back easily generate at least 85% of the if err != nil {... etc. statements. As much as people complain about it, explicitly checking errors like this (and checking them all) is almost essential for production quality enterprise code and any code running on mission critical systems (and to most project managers,…

I think the "embrace failure" supervisor model in BEAM is a superior design for mission-critical systems (such as cell networks, where it originated) while resulting in literally a ton less boilerplate. You just code the "happy path" and done. Any errors are logged and the process instantly restarted by the supervisor, you can follow up on them if they present a problem. If you were to code just this "happy path" in…

People keep saying this and I struggle to understand how this represents good design. In any language I can always just eat the error and keep going, or eat the error and restart.

That doesn't fix the error, and it doesn't imply the program will work correctly.

Re: Toward Go 2

#376

Post by threeseed »

jalfresi wrote: post #188
logingone wrote: post #174

Earlier quoted context omitted.

I've described Go programs as often looking like a listing of things that could go wrong.

In my opinion and experience, that is exactly what programs are

Not in Java, Scala, Clojure etc. it isn't.

You can wrap all your code in an unchecked exception and never again have to worry about errors. It's bad practice obviously but there are many situations in which you don't care what error occurred but that an error itself occurred.

Re: Toward Go 2

#377

Post by Thaxll »

twblalock wrote: post #317
Thaxll wrote: post #260

Earlier quoted context omitted.

Still better that try / except: pass from other languages.

No, it's way worse, because you have to write the error handling multiple times even if it is all the same (and it usually is). For example, in Java, I can make as many method calls I want inside of a try block, and catch an exception from any one of them in the catch block. In Go, I would need the equivalent of one catch block per method call, in the form of "if err != nil { return err }". Why repeat yourself? If yo…

I remember in Python some class / module would have different fields in the error object, so it was really difficult to do something meaningful with those errors.

There is also the switch case you need to make when catching an error, like tcp connection then dns resolution and so on, you have to know every time any kind of sub errors.

Re: Toward Go 2

#378

Post by 43224gg252 »

jcadam wrote: post #81
bad_user wrote: post #48

Java`s generics have had issues due to use site variance, plus the language isn't expressive enough, leading its users into a corner where they start wishing for reified generics (although arguably it's a case of missing the forest from the trees). But even so, even with all the shortcomings, once Java 5 was released people migrated to usage of generics, even if generics in Java are totally optional by design. My gue…

After some initial enthusiasm due to its gentle learning curve (actually, the Golang learning curve is nearly non-existent for an experienced programmer), I got sick of Go programming pretty quickly. Writing anything non-trivial will have you fighting against the limitations of the language (e.g., lack of generics which is particularly aggravating when trying to write a library). I've mostly moved on to Clojure for p…

I've programmed scores of libraries in Go and found it pleasant, in fact it's more pleasant writing a library in Go than in any other language I've used.

I've never once even considered the fact that I might need generics because I've never run into an unsolvable problem or an extremely inelegant engineering solution. I see a lot of people claiming that the lack of generics is a big problem but no one is actually showing a concrete case where generics are necessary.

C doesn't have generics but we never have this discussion when we talk about C.

Re: Toward Go 2

#379

Post by laumars »

twblalock wrote: post #358
laumars wrote: post #338

Earlier quoted context omitted.

> Why repeat yourself? Because you can put more meaningful error messages due to the granularity of the checking. This has made debugging things a lot easier at times.

You can , but you should not be forced to do so. I could easily do that in Java if I wanted to, but I also have the flexibility to handle them all in the same way, or pass them back to the caller (which the right thing to do 99% of the time), with a very small amount of code.

To be honest moaning about Go idioms is like moaning that Java is object orientated or Lisp has too many braces. If you don't like the idioms of a particular language then don't use that langauge. There's plenty of others to choose from. But moaning that language x should be more like language y is just daft as it misses the point of why language x decided to do something different in the first place.

I'm not saying Go's error handling is better than Java's. But I've written some relatively large and complicated projects in Go (like the Linux $SHELL and REPL scripting language I'm currently coding this very moment) and error handling really is the least of the problems I've been having. Sure, Go's idioms do get in my way from time to time. But on balance Go's idioms save me more time than it wastes. Which is why I keep coming back to Go despite having used more than a dozen other languages in anger. But that's my workflow and my personal preference. Others will find the reverse to be true and I wouldn't be complaining that their language should be more like Go.

Frankly I think people waste too much time comparing languages. Just try something and if it doesn't work, move on. Don't assume your personal preference is a benchmark for how all languages should be designed as there will be a million other developers whose personal preference will exactly oppose you.

Re: Toward Go 2

#380

Post by threeseed »

laumars wrote: post #338
twblalock wrote: post #317

Earlier quoted context omitted.

No, it's way worse, because you have to write the error handling multiple times even if it is all the same (and it usually is). For example, in Java, I can make as many method calls I want inside of a try block, and catch an exception from any one of them in the catch block. In Go, I would need the equivalent of one catch block per method call, in the form of "if err != nil { return err }". Why repeat yourself? If yo…

> Why repeat yourself? Because you can put more meaningful error messages due to the granularity of the checking. This has made debugging things a lot easier at times.

Maybe you haven't used exceptions on the JVM before but you can wrap them so it's possible to still have localised error messages if you want them.

But in most cases it is unnecessary since you always have the line number and type of exception printed out as part of the stack trace.

Post reply on HN