undefined | Better HN

0 pointsVeraticus2y ago0 comments

For sure — a lot of language features need to be generic. But most people aren’t coding language features, and giving them the ability to do so can lead to, well, CodeFactoryFactoryMakerGenericMethodHelpersFactory, rather than good, clear, usable code.

0 comments

pie_flavor2y ago

There is no language feature for a tree map. Many problems require a tree map. Either inclusion of generics was a good thing, or it is worth sacrificing static typing or requiring codegen for these use cases. Repeat for numerous collections and APIs.

Disallowing someone from using easy statically typed tree maps is not accomplishing any of the simplicity virtues people trumpet Go for having. While the much-warned-of castles of inappropriately applied generics have yet to be found in any codebase I've worked with in any language, including Rust.

VeraticusOP2y ago

This is a pretty arbitrary benchmark. I would guess, again, that 95% of programmers have never and will never need to create a tree map. Repeat for numerous collections and APIs that are totally irrelevant to most programmers' actual experience of programming.

Go is optimized for use, not computer science edge cases. And as a result it is widely used, and some of the most complicated and widely-used open-source projects out there are built in it, even before it had generics. For example, Kubernetes.

This is because of Go's simplicity, not in spite of it.

pie_flavor2y ago

    > rg BTreeMap monorepo/ --type rust --no-filename | awk NF | wc -l
    1656

You may not have ever encountered a use case for a tree map, but there is quite a wide gray area between 'computer science edge cases' and cookie-cutter CRUD apps. For example, deterministic map ordering, or sets for map keys, or fast map equality.

Funny that you mention Kubernetes. This is the tree map implementation Kubernetes depends on https://github.com/google/btree

valenterry2y ago

It's not about creating a tree map, it's just about using one. Maybe even one provided by a library, doesn't matter. I'm sure that 95% of the developers will need a tree map at least once in their career.

1 more reply

maccard2y ago

I've spent a lot of time writing library-level C++, a reasonable amount of time writing application-level C++, and a reasonable amount of time writing both library and application-level golang.

> But most people aren’t coding language features

It's definitely a tough lever, but supporting generics for the people who are means that the people who aren't can write cleaner code. I think go got it right, eventually.

kaba02y ago

You are writing a Turing complete language. If someone wants to be stupid architecture astronauts, you can’t help them, beside better filtering people who work on your project.

j / k navigate · click thread line to collapse

0 comments

pie_flavor2y ago

VeraticusOP2y ago

This is because of Go's simplicity, not in spite of it.

pie_flavor2y ago

    > rg BTreeMap monorepo/ --type rust --no-filename | awk NF | wc -l
    1656

Funny that you mention Kubernetes. This is the tree map implementation Kubernetes depends on https://github.com/google/btree

valenterry2y ago

1 more reply

maccard2y ago

I've spent a lot of time writing library-level C++, a reasonable amount of time writing application-level C++, and a reasonable amount of time writing both library and application-level golang.

> But most people aren’t coding language features

It's definitely a tough lever, but supporting generics for the people who are means that the people who aren't can write cleaner code. I think go got it right, eventually.

kaba02y ago

You are writing a Turing complete language. If someone wants to be stupid architecture astronauts, you can’t help them, beside better filtering people who work on your project.

j / k navigate · click thread line to collapse