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

441–450 of 670 posts

Re: Toward Go 2

#441

Post by pmarreck »

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.

I think you need to try it out to see what the big deal is. It's pretty liberating.

The thing is, there will always be the "unknown unknown" bugs, the ones you didn't even think to anticipate, and Erlang/Elixir/BEAM will always win out in a behavior contest on those vs. in Go, because it is built to anticipate any possible error, not just the possibilities you're aware of.

Re: Toward Go 2

#442

Post by dgacmu »

I should send this to rsc, but it's fairly easy to find examples where the lack of generics caused an opportunity cost.

(1) I started porting our high-performance, concurrent cuckoo hashing code to Go about 4 years ago. I quit. You can probably guess why from the comments at the top of the file about boxing things with interface{}. It just got slow and gross, to the point where libcuckoo-go was slower and more bloated than the integrated map type, just because of all the boxing: https://github.com/efficient/go-cuckoo/blob/master/cuckoo.go

(my research group created libcuckoo.)

Go 1.9 offers a native concurrent map type, four years after we looked at getting libcuckoo on go -- because fundamental containers like this really benefit from being type-safe and fast.

(2) I chose to very tightly restrict the initial set of operations we initially accepted into the TensorFlow Go API because there was no non-gross way that I could see to manipulate Tensor types without adding the syntactic equivalent of the bigint library, where everything was Tensor.This(a, b), and Tensor.That(z, q). https://github.com/tensorflow/tensorflow/pull/1237 and https://github.com/tensorflow/tensorflow/pull/1771

I love go, but the lack of generics simply causes me to look elsewhere for certain large classes of development and research. We need them.

Re: Toward Go 2

#443

Post by wruza »

mohamedattahri wrote: post #334
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.

Which is exactly what software engineers should spend most of their time doing.

  , err = 
  if err != nil { return nil, err }
  , err = 
  if err != nil { return nil, err }
Is not what software engineers should spend time on, definitely.

Not automating ubiquitous trivial propagations with at least explicit "rie " (rie for "return if error") is a complete engineering fail under any philosophy.

Oh, I have an idea. If ", err" part is missing from lvalue, insert that mantra automagically under #pragma ARIE=on. This workaround will give designers some stats to embrace.

Re: Toward Go 2

#444

Post by treehau5 »

EngineerBetter wrote: post #170

I suspect the authors of Golang got drunk, and challenged each other to see how many times they could get people to type 'if err != nil' in the next decade.

Actually what really happened was instead of trying to catch em 'all with pokemon try/catching, they decided to treat errors like it was part of the actual code. Errors are values. You can actually code with them. Amazing, right?

Re: Toward Go 2

#445

Post by treehau5 »

beliu wrote: post #374

This was announced at GopherCon today. FYI, if folks are interested in following along other conference proceedings, there is no livestream, but there is an official liveblog: https://sourcegraph.com/gophercon

It's on twitch I believe

Re: Toward Go 2

#447

Post by concede_pluto »

why-el wrote: post #360
baq wrote: post #322

Earlier quoted context omitted.

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?

If you declare a map[string]int, Go will guarantee that keys are always strings and values are always ints, and it's a compile-time error to pass it to someone expecting a map[string]float64. Without generics, the only way to do that is to generate and compile a MapStringInt struct and a MapStringFloat64 struct and a...

Re: Toward Go 2

#448

Post by wwweston »

skybrian wrote: post #438
wwweston wrote: post #433

Earlier quoted context omitted.

"low resolution" is a perfectly accurate description of "fuck generics", which like any two-word phrase can't entirely capture the attitude of the golang team, but nevertheless does seem to capture something of gestalt of their approach. Finer resolution would be if fusiongyro had characterized the golang team as saying "fuck off developers who want generics," which wouldn't have been as polite as the phrase "I don't…

No. Unless someone finds a quote, the low order bit is that they didn't use the word "fuck" or any other swear word at all. You can't use the word "fuck" to accurately quote someone who didn't use that word.

Bringing TOOWTDI from the realm of Python and Go to English, I see.

I suppose the argument I'm making does indeed depend on the premise that essential semantics of "fuck" can be conveyed in other ways. If you like, we could explore this by example.

Re: Toward Go 2

#449

Post by jules »

kevhito wrote: post #428
wwweston wrote: post #121

Earlier quoted context omitted.

While "fuck generics" might be a low-resolution characterization, it's not entirely inaccurate, and the efforts of Taylor (and perhaps others) notwithstanding, as long as anyone is writing things like "I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve," there's reason to believe it's apt enough. As other respondents to the GP comment show, it's not at all…

Counting the weasel words.... 1. "might be" 2. "not entirely inaccurate" 3. "perhaps others" 4. "things like" 5. "the's reason to believe" 6. "apt enough" And that's just in your first sentence. My impression has always been that the Go core team is very open to the possible addition of generics, but also very wary of the very real downsides that generics have. Nothing I've ever seen from Rob or other core team membe…

What are the very real downsides that generics have?

Re: Toward Go 2

#450

Post by slantedview »

weberc2 wrote: post #242
slantedview wrote: post #204

Earlier quoted context omitted.

The idea that we don't need generics because we can generate code is kind of ridiculous, and certainly doesn't pass the simplicity smell test.

He wasn't making that argument...

Neither did I say he was. He was linking to a library that works around the lack of generics by generating code.
Post reply on HN