Toward Go 2 • Hacker News Board

Re: Toward Go 2

#381

Post by 43224gg252 » Thu, Jul 13, 2017, 10:30 PM UTC

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…

Those supervisors don't always handle the errors the way you want and can't always be implemented without diminishing overall performance. It's a trade-off.

Re: Toward Go 2

#382

Post by 43224gg252 » Thu, Jul 13, 2017, 10:40 PM UTC

kasey_junk wrote: post #369

43224gg252 wrote: post #304

Earlier quoted context omitted.

Same, and to add: Go 2 has been planned for a while (since the beginning?) and I'm pretty sure the core developers tend to defer major new feature ideas (e.g. generics) to Go 2. If they implemented everything everyone asked for they'd have another screw-up like C++ or Java.

Calling those languages screw ups is one of the funnier things I've seen in awhile.

I know that both Java and C++ have a lot more issues than Golang ever will. I've used all three languages. Java has mile long class hierarchies, massive try-catch blocks, indentation as thick as my neck, and runs in a JVM. It's so bad there are already other implementations that people would much rather use. I also really don't like the file/project naming conventions.

C++ is a whole other animal. The whole system of a Go program is typically very penetrable. You can trace the code down to the bottom of the stdlib or even the compiler builtins in seconds with ease (thanks to the excellent Guru and vim-go). In my experiences of C++, I doubt how many C++ programmers have ever had a look to the implementation of STL or iostream, which is hard to do ergonomically. Although some people occasionally call the opaqueness encapsulation and see it a good practice (which I don't agree). There are lots of cross compilation and static linking problems that don't arise with Go. There is the problem that one C++ code base will look completely different from others because no one in the C++ world follows conventions the way people in the golang world do.

Compared to them Go is a very well thought out and elegant language.

Re: Toward Go 2

#383

Post by XorNot » Thu, Jul 13, 2017, 10:41 PM UTC

kccqzy wrote: post #330

erikpukinskis wrote: post #323

Earlier quoted context omitted.

This suggests that both generics and inheritance are unnecessary.

It only suggests you can't easily give an example because the language is forcing a design where such things aren't needed. Sort of like linguistic relativity.

Which still proves the parent's point: it's not necessary. The question is what absolutely can't be done without them (probably nothing) so a better question is how much design/engineering/test time could be saved with them?

On the latter part I'm fairly cynical these days, since I'm presently on a team where the lead embraced a Scala-DSL heavy, functional design and the net result has been a total loss of project velocity because when we need to prototype a new requirement, the push back has been paraphrasing "oh, could you not do that in and handle it somewhere else?" - so we end up with a bunch of shell scripts cobbled together to do so.

Re: Toward Go 2

#384

Post by nuggien » Thu, Jul 13, 2017, 10:44 PM UTC

johansch wrote: post #172

nuggien wrote: post #156

Earlier quoted context omitted.

Just use an editor that has goimports hooked up to run on save.

Or pick a language where you don't have to jump through arbitrary hoops.

depends on which editor you use, but i'd say there's a high chance it has a go package that has all this configured for you.

In any case, every language has a hoop to jump through. Good luck finding one without.

Re: Toward Go 2

#385

Post by nuggien » Thu, Jul 13, 2017, 10:45 PM UTC

johansch wrote: post #179

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.

Funnily enough: I've never found that to be a big problem with other languages in practice. Actually, on a scale of problems in other people's code I'd probably put this very far down the list.

Have you worked with code where unused variables actually have a side effect?

Re: Toward Go 2

#386

Post by ryanplant-au » Thu, Jul 13, 2017, 10:50 PM UTC

pebers wrote: post #194

andrewprock wrote: post #145

Earlier quoted context omitted.

I think you're confusing stable with "done". The C language has been getting updates about once every 10 years: Original (~1970) K&R (~1980) ANSI C (~1990) C99 (~2000) C11 (~2010) I would not be surprised to see a C22.

To what degree are those being used though? Major projects (e.g. Linux, CPython) are still on ANSI C.

CPython switched to C99.

Re: Toward Go 2

#387

Post by ethbro » Thu, Jul 13, 2017, 10:51 PM UTC

XorNot wrote: post #375

pmarreck wrote: post #351

Earlier quoted context omitted.

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.

> In any language I can always just eat the error and keep going, or eat the error and restart.

Defer to pmarrek on what they meant, but to me it's an issue of practical programming.

In a choice between "I will tell you what to do about errors" vs "I will assume you only crash and restart on any error", I've found the later to be far more efficient.

The former generally leads to a rat's nest of never ending error specialization as unexpected or rare stuff bubbles up in UAT or down the road in prod.

Which isn't to say there's a right answer. There's always going to be particular situations where of course you should use one or the other.

But on the whole, as a philosophical default, fail-and-recycle-on-all-errors is a helluva lot easier to spec, code, test, and maintain for me.

Re: Toward Go 2

#388

Post by smegel » Thu, Jul 13, 2017, 10:53 PM UTC

elliotmr wrote: post #233

I must say that whenever there is a discussion about the merits of the Go programming language, it really feels hostile in the discussion thread. It seems that people are seriously angry that others even consider using the language. It is sort of painful reading through the responses which implicitly declare that anybody who enjoys programming with Go is clueless. It also really makes me wonder if I am living in some…

To be fair, forcing \t on people was a douchebag move.

Re: Toward Go 2

#389

Post by Animats » Thu, Jul 13, 2017, 10:55 PM UTC

kevinconaway wrote: post #138

jasonwatkinspdx wrote: post #118

Disclaimer: I mean this with love This post really frustrates me, because the lengthy discussion about identifying problems and implementing solutions is pure BS. Go read the years worth of tickets asking for monotonic time, and see how notable names in the core team responded. Pick any particular issue people commonly have with golang, and you'll likely find a ticket with the same pattern: overt dismissal, with a he…

> asking for monotonic time His anecdote about Google/Amazon using leap smears to solve the problem is telling. I suspect that they were unable to see outside their own bubble to think about how others may be impacted. > We did what we always do when there's a problem without a clear solution: we waited The original problem described the issue and the potential consequences very well and the problem didn't change bet…

Given Google's orientation towards server-side web applications, it makes sense. On the other hand, the real-time OSs such as QNX have had monotonic clocks available for decades, and they use them for all delay and time interval measurements. (In real-time, you use the monotonic clock for almost everything that matters, and the day clock for logging and display only. You don't want the clock used for delays and time intervals to "smear"; it might have physical effects if it's being used to measure RPM or something and seconds got slightly longer.)

Go is great for server-side web applications. The libraries for that are all there and well debugged. Anything else, not so much.

Re: Toward Go 2

#390

Post by Jare » Thu, Jul 13, 2017, 10:56 PM UTC

hota_mazi wrote: post #300

kevinconaway wrote: post #138

Earlier quoted context omitted.

> asking for monotonic time His anecdote about Google/Amazon using leap smears to solve the problem is telling. I suspect that they were unable to see outside their own bubble to think about how others may be impacted. > We did what we always do when there's a problem without a clear solution: we waited The original problem described the issue and the potential consequences very well and the problem didn't change bet…

> We did what we always do when there's a problem without a clear solution: we waited And this is exactly why the Go designers don't understand language design, and how this ignorance shines through every single place in their language. Language design is about compromises. There is never a perfect solution, only one that satisfies certain parameters while compromising others. You, the designer, are here to make the…

You are being deliberately negative here. Choosing to forego generics in favor of simplicity (and its impact along several axes) is a postcard example of a compromise. It is a tough choice that many people will be unhappy with, but there are also many Go programmers that are extremely satisfied with that direction.

As for acknowledging, well, they have always been very clear about their position. It makes no sense to spend a decade answering the same question over and over with a long and elaborate response which the person asking has already seen and dismissed. I can understand them becoming condescending after a decade of facing people who act with a deliberately obtuse and holier-than-thou attitude.

It's not like they have been lazy - every release of Go has had a large amount of improvements that matter. Working on generics would have meant sacrificing a (probably large) amount of them.

(for the record, I dearly miss generics too!)