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

Go 1.27 Interactive Tour

victoriametrics.com

Post reply on HN
Print view View original

141–150 of 219 posts

Re: Go 1.27 Interactive Tour

#141

Post by _dain_ »

inigyou wrote: post #127
ckcheng wrote: post #18

Earlier quoted context omitted.

Took a few more years to get really bug free. > Fast forward to 2006. I was shocked to learn that the binary search program that Bentley proved correct and subsequently tested in Chapter 5 of Programming Pearls contains a bug. ... Lest you think I'm picking on Bentley, let me tell you how I discovered the bug: The version of binary search that I wrote for the JDK contained the same bug. It was reported to Sun recentl…

403 error. What was the bug?

IIRC it was overflow when you do (a + b) / 2 for the midpoint. It took so long to find because you need a >billion item array to overflow the 32-bit integer, and that much RAM wasn't common until the 00s.

The right way is a + (b - a)/2.

Re: Go 1.27 Interactive Tour

#142

Post by yladiz »

red_admiral wrote: post #123
zerr wrote: post #118

Earlier quoted context omitted.

We often forget that our profession (computer programming) belongs to STEM. Some (like Go 1.0 :)) wish to think it is Arts & Humanities. The sooner we realize that yes, it is OK and actually expected to bear a cognitive weight of "(b Box[T]) Map[U any](f func(T) U) Box[U]" the sooner we get back to reality... :)

Just because we can, doesn't mean we have to. I'd prefer to have some more brain-cache free to concentrate on the problem I'm trying to debug rather than doing type resolution in my head.

Please. I’m sorry, but you kind of can’t avoid needing to think about types unless you use a language like JavaScript which is super loose with its type conversions, and you especially can’t avoid in a language like Go. With generics in Go you don’t even need to prefill the types like you go with a lot of other cases, so I’m dubious about the cognitive overhead.

Re: Go 1.27 Interactive Tour

#143

Post by zerr »

twsted wrote: post #63
baalimago wrote: post #42

This: "(b Box[T]) Map[U any](f func(T) U) Box[U]" is the type of cognitive weight I was happy that Go avoided.

I really understand your feeling, I escaped from C++ years ago when I was overwhelmed by meta programming (initially i loved it). But anyway I find this in Go much more bearable.

As a C++ (including modern) developer for more than 20 years, I had written a "template" keyword only for a handful of times. Maybe once in every 5 years on average... :)

Unless you are a compiler/stdlib vendor or contributing to Boost, there are features that you just don't use it daily.

Re: Go 1.27 Interactive Tour

#145

Post by fooooor »

asdf88990 wrote: post #108
Altern4tiveAcc wrote: post #96

>func (b Box[T]) Map[U any](f func(T) U) Box[U] {} That's completely unreadable.

Yes, thinking in higher order abstractions is hard for most people.

On the contrary, linq in C# is a killer function that other languages still fail to replicate.

How many sloc are required for this?

var max = mycollection.Max();

Probably 5-10 if you’re missing higher order functions. And the risk of bugs will be 10x.

Re: Go 1.27 Interactive Tour

#146

Post by fragmede »

inigyou wrote: post #127
ckcheng wrote: post #18

Earlier quoted context omitted.

Took a few more years to get really bug free. > Fast forward to 2006. I was shocked to learn that the binary search program that Bentley proved correct and subsequently tested in Chapter 5 of Programming Pearls contains a bug. ... Lest you think I'm picking on Bentley, let me tell you how I discovered the bug: The version of binary search that I wrote for the JDK contained the same bug. It was reported to Sun recentl…

403 error. What was the bug?

Load in an incognito window?

Loads fine for me:

> The bug is in this line:

6: int mid =(low + high) / 2;

Re: Go 1.27 Interactive Tour

#147

Post by fooooor »

Cthulhu_ wrote: post #78
ad_hockey wrote: post #51

Earlier quoted context omitted.

As of June last year[1] the Go team have pretty much drawn a line under this issue, with a very small amount of wiggle room to possibly reopen it at some point: "For the foreseeable future, the Go team will stop pursuing syntactic language changes for error handling. We will also close all open and incoming proposals that concern themselves primarily with the syntax of error handling, without further investigation.”…

Yeah a few years ago there was a lot of buzz around it, but ultimately when presenting and polling all the options to the community, the general consensus was that existing error handling was actually fine. The other options added complexity and were harder to read.

[flagged]

Re: Go 1.27 Interactive Tour

#148

Post by golem14 »

fooooor wrote: post #137
treyd wrote: post #126

Earlier quoted context omitted.

You've already been able to badly implement monads in Go for 10+ years. Why wouldn't you be able to implement them in a way that the compiler can enforce correctness of? If you don't want it don't use it. It's that simple.

No it’s definitely not that simple. Code are read more often than written, no one works in a vacuum, especially not in open source. Also, when in Rome...

If a project's owner feels that strongly about not using generics, that's a choice. No dependencies using generics, no generics allowed in PRs etc. Perfectly doable.

Also, screw those Romans ;)

Re: Go 1.27 Interactive Tour

#149

Post by theptip »

hnlmorg wrote: post #100
fauigerzigerk wrote: post #94

Earlier quoted context omitted.

I understand that this is true for a lot of application code. It's not true for library authors though, and every language needs libraries.

I’ve written a lot of libraries too. The problem is generics only solve a very small part of the equation: compile time checks for composite types. But to use composite types in anything non-trivial in Go, you then need reflection. Which is slow. And if you then need reflection, you’re already passing interface types anyway plus you’re back to having to handle type-handling errors in the runtime. So if you’re writing…

Interesting, thanks - is the problem you’re describing solved by Rust’s macros (eg derive) or are there further issues you see even there?
Post reply on HN