undefined | Better HN

0 pointsotikik11y ago0 comments

> visual basic

Bringing The Language Which Shall not Be Named to the discussion is a low blow. But I deserve it. My phrase about overcomplication was flamebaity and uncalled for, and I apologize.

> you're missing out on simple beautiful abstractions like map and filter

The thing is, in Go, those take almost as much space as a plain for loop.

I know, you will tell me "that's because Go's too verbose". I will grant that it's more verbose than Haskell.

But I am not doing maps and filters all the time in my code.

> It's not possible to write a generic container without casts to interface{}, which is a shame imo.

My point is that generic containers are the feature where generics are genuinely needed. And in those cases interface{} makes it possible. Not super-awesome, but possible. I actually like that the language doesn't bend over to fulfill something that looks almost like an edge case. It is not "programming with mathematics". It's still "moving bits around". But the bits can be moved with ease.

0 comments

jacques_chester11y ago

interface{} doesn't give you generics. The point of generics is to give you two distinct things:

1. You can write code that performs identical logic for a range of different data types, without having to know what they are.

2. That code can be checked for type safety.

interface{} gives you half of 1. You can write code that performs common logic and takes an interface{}, but then that code has to manually switch on type, or convert type before running.

Which gives you trouble with 2. Once you don't have a distinct type, you can't check for safety. All the compiler can do is check that an interface{} is passed in; which is a pretty weak guarantee. Meanwhile, in languages with generics, the you can write a generic method that uses the + operator and the compiler can check whether it works for numbers (OK), strings (OK), HTTP servers (uh oh, stop the bus!)...

j / k navigate · click thread line to collapse