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

Go 1.18

go.dev

Post reply on HN
Print view View original

611–614 of 614 posts

Re: Go 1.18

#611

Post by cellularmitosis »

stouset wrote: post #241
CraigJPerry wrote: post #228

Earlier quoted context omitted.

>> generics reduce complication That goes against the definition of the word complication. To complicate something is to combine and intertwine it with other concerns. To fold them together is to complicate them. To generify a function is to complicate it with the ability to accept multiple types rather than just one. There are totally great use cases for generics but all the cases I’ve seen are in library code not i…

As a general rule, if you're referencing the dictionary definition of a word to make your point, you're just playing semantic games. You know what people also find complicated? Hundreds of lines code being repeated with superficial edits because of golang's lack of ability to abstract higher-level ideas. It's a stupid toy example, but for a very large number of people nums.take(20).select(&:odd).reduce(&:+) is less c…

> As a general rule, if you're referencing the dictionary definition of a word to make your point, you're just playing semantic games.

Before dismissing this as silly semantic games, you should watch the talk which they were very likely referencing: https://www.infoq.com/presentations/Simple-Made-Easy/

Re: Go 1.18

#612

Post by randomswede »

yencabulator wrote: post #608
randomswede wrote: post #588

Earlier quoted context omitted.

I would say that "exists in the set" is determined only and exactly by "mySet[thing]" returning true, not that there happens to be a key in the map. But, that's one of those "requires extensive documentation" (and ideally, wrapping in a custom type and provide methods for checking and manipulating the set(s)).

Now every range over your set is likely to be a bug. `map[T]bool` is simply a bad design to use.

How? Why? If you use the map[T]bool, you obviously need to pay attention to the bool value, even in a range. Whereas in map[T]struct{} you don't need to pay attention to the values.

In either way, even with that type of data type underlying a set, I would (probably) provide a functional API to interact with it.

Re: Go 1.18

#613

Post by yencabulator »

randomswede wrote: post #612
yencabulator wrote: post #608

Earlier quoted context omitted.

Now every range over your set is likely to be a bug. `map[T]bool` is simply a bad design to use.

How? Why? If you use the map[T]bool, you obviously need to pay attention to the bool value, even in a range. Whereas in map[T]struct{} you don't need to pay attention to the values. In either way, even with that type of data type underlying a set, I would (probably) provide a functional API to interact with it.

    m["x"] = foo()
    for k := range {
        // if foo returned false, this is buggy
    }

Re: Go 1.18

#614

Post by randomswede »

yencabulator wrote: post #613
randomswede wrote: post #612

Earlier quoted context omitted.

How? Why? If you use the map[T]bool, you obviously need to pay attention to the bool value, even in a range. Whereas in map[T]struct{} you don't need to pay attention to the values. In either way, even with that type of data type underlying a set, I would (probably) provide a functional API to interact with it.

m["x"] = foo() for k := range { // if foo returned false, this is buggy }

Yes, as I said, if you use a map[T]bool, you need to use something like:

for k, v := range m { if v { } }

But it also allows you to use "if m[key] { ... }". It is literally a trade-off for what convenience you want. And in both cases, you should (probably) wrap an abstraction around the raw map.

Post reply on HN