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

351–360 of 670 posts

Re: Toward Go 2

#351

Post by pmarreck »

43224gg252 wrote: post #313
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.

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 Go, it would actually be the unhappy path, because you'd have silent errors resulting in indeterminate state (read: horrible bugs to troubleshoot). If you believe programming is mostly about managing all possible state (as I do), then Go's strategy is way too explicit. In Erlang/Elixir/BEAM's case, as soon as state goes off the rails (read: encounters something the programmer didn't anticipate), it's logged and restarted by its supervisor process almost instantly. (and there are of course strategies for repeated restarts)

Re: Toward Go 2

#352

Post by pmarreck »

grogenaut wrote: post #341
bboozzoo wrote: post #267

Earlier quoted context omitted.

Unless you're writing in Erlang, in which case you program the success path and 'let it crash' in a controlled manner.

You're assuming that it faithfully crashes in all error states as opposed to incorrectly continuing on it's merry way.

Why wouldn't it, if you're pattern-matching correctly? And in any event, it seems far easier to get into that situation in Go (which ignores errors unless you explicitly check for them) than in Erlang (which crashes on every error because restarting is cheap)

Re: Toward Go 2

#353

Post by dragonwriter »

notheguyouthink wrote: post #211
dragonwriter wrote: post #107

Earlier quoted context omitted.

Breaking things aren't want makes people want to move; it's a cost, not a benefit. Now, you need to offer benefits to get people to pay the cost for those benefits. The Python 2/3 problem was because there was too much breakage for the perceived benefit (especially early on) for many users, not because there was too little breakage.

Fwiw, I think breaking implies improving. Arguing that breaking doesn't inherently mean improving is.. well, duh. So in the case of many peoples comments here, "not breaking enough" means not improving enough. I know this is an obvious statement, but I feel like you're arguing a moot argument.. i.e., being a bit pedantic. As an aside, since you're making the distinction, can you have meaningful benefit without breaka…

> As an aside, since you're making the distinction, can you have meaningful benefit without breakage?

Sure, in two ways:

(1) Performance improvements with no semantic changes.

(2) New opt-in features that don't break existing code (such as where code using the new feature would have just been syntactically invalid in the old version, so the new feature won't conflict with any existing code.)

There be no reason for SemVer minor versions if you couldn't make meaningful improvements while maintaining full backward-compatibility.

Re: Toward Go 2

#354

Post by FRex »

civilitty wrote: post #239
notjack wrote: post #185

Earlier quoted context omitted.

Note that at no point in the post whatsoever were any contributions to these specific issues from outside the core maintainers thanked or even acknowledged.

Which is quite surprising. With open source projects it's usually the other way around...

Google already had incident with Guava where they didn't give a shit about the patches: https://news.ycombinator.com/item?id=3691587

Re: Toward Go 2

#355

Post by olivierva »

osteele wrote: post #217
pmarreck wrote: post #141

Earlier quoted context omitted.

I'm still sitting here shocked that a language where "err" (and the keywords that check around it) are used an order of magnitude more frequently than all other syntax in that language, has achieved this much popularity: https://anvaka.github.io/common-words/#?lang=go

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 ;-)

Re: Toward Go 2

#356

Post by vram22 »

abiox wrote: post #347
jimjimjim wrote: post #246

Here be Opinions: I hate generics. also, I hate exceptions. Too many people are wanting "magic" in their software. All some people want is to write the "Happy Path" through their code to get some Glory. If it's your pet project to control your toilet with tweets then that's fine. But if it's for a program that will run 24/7 without human intervention then the code had better be plain, filled with the Unhappy Paths an…

in a sense, generics just let you provide parameters to your types, just like you give parameters to functions. it's not all that magical.

Yes, I had read in an article about/by Walter Bright about D, that that was the insight he had, when working on the design of generics or templates for D:

To paramet(e)rize the types (of a class or function or method), just like you parametrize the arguments of a function or method.

Update: searched for and found the article that mentions that:

https://dlang.org/blog/2016/08/30/ruminations-on-d-an-interv...

Excerpt (italics mine):

[ Walter: We nailed it with arrays (Jan Knepper’s idea), the basic template design, compile-time function execution (CTFE), and static if. I have no idea what the thought process is in any repeatable manner. If anything, it’s simply a dogged sense that there’s got to be a better way. It took me years to suddenly realize that a template function is nothing more than a function with two sets of parameters –compile time and run time–and then everything just fell into place.

I was more or less blinded by the complexity of templates such that I had simply missed what they fundamentally were. There was also a bit of the “gee, templates are hard” that predisposes one to believe they actually are hard, and then confirmation bias sets in.

I once attended a Scott Meyers presentation on type lists. He took an hour to explain it, with slide after slide of complexity. I had the thought that if it was an array of ints, his presentation would be 2 minutes long. I realized that an array of types should be equally straightforward. ]

Re: Toward Go 2

#357

Post by johansch »

Orangeair wrote: post #193
ahacker15 wrote: post #146

Earlier quoted context omitted.

I like that Go don't allows unused import and variables. If you're working with inexperienced programmers (and some experienced but bad programmers), you should be certain that they WILL let that code garbage there if the compiler allow it.

That's the kind of thing that should be detected by a linter and stop code submission though, not necessarily stop it from even compiling. What if you just want to comment something out quickly? I don't program in Go, but it seems like it would be annoying to have to repeatedly add and remove the main dependencies while I was iterating on something.

It is absurdly annoying. It's the one thing that put me off golang development, despite all of its nice aspects relating to concurrency.

Having custom functionality in editors to work around this apparently dogmatic design decision in the core language.. is also just absurd.

Re: Toward Go 2

#358

Post by twblalock »

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.

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.

Re: Toward Go 2

#360

Post by why-el »

baq wrote: post #322
jimjimjim wrote: post #246

Here be Opinions: I hate generics. also, I hate exceptions. Too many people are wanting "magic" in their software. All some people want is to write the "Happy Path" through their code to get some Glory. If it's your pet project to control your toilet with tweets then that's fine. But if it's for a program that will run 24/7 without human intervention then the code had better be plain, filled with the Unhappy Paths an…

there's nothing magic about generics. every time you make a channel or a map in go, you're using a generic function even if go people don't want you to call it that. there's nothing magic about exceptions, too, it's that it's harder than necessary to use them correctly and that's why it's not as big of a deal to not have them in go - as evidenced by this thread.

Curious, how is a map generic?
Post reply on HN