Hacker News Reader

Comment by baby | Hacker News Reader

Security consultant here. I have audited many codebases in many languages. Go is by far the easiest language to audit: it always looks the same, it's not too verbose, there are no generics or OOP. Coincidentally it's always the most secure as well. My take on this is that it is easier to see logic problems because it is easier to read, understand and reason about. On top of that the standard library does so much for you with crypto and security.

Generics and zero-cost abstraction can and are concepts that are often abused instead of used when it makes sense. I hope thay Go will never support generics because I sincerly believe it might mean the end of the language

View on HN

I'm curious, how will they end Go itself? My understanding is that they always planned to have generics, they just didn't make 1.0 and now the Go community has sort of adopted the lack of them like a badge of honor.

Also, I have no expertise in your field so forgive me if this is a stupid question but wouldn't generics be easier to check over since they allow there to be only one implementation of something for all types versus in Go, a bunch of different implementations of the same thing that you have to check and might have subtle errors?

> "My understanding is that they always planned to have generics, they just didn't make 1.0 and now the Go community has sort of adopted the lack of them like a badge of honor."

As soon as Go adopts generics the community will turn on a dime and pretend they always loved generics (and perhaps even invented them.) That's how these sort of things typically play out. See also, copy/paste on iphones. When only android had it, copy/paste was a misfeature for idiots. When iOS implemented it, copy/paste became the best thing since sliced bread.

See also: Java Generics.

Also see javascript and static typing.

I think there is generics proposal under discussion.

There is! As soon as it is implemented in the language, I will consider Go.

> it's not too verbose

that's a really puzzling statement to me, maybe aside from C, C++, and Java, (and maybe rust) Go is certainly on the "more verbose" side.

Pretty sure those are almost all of the most popular statically typed languages (absent C#, which has about the same verbosity as Java). I'm sure I'm wrong if you're willing to lower the threshold for "popular" enough.

I’ll opine that C# is much less verbose than Java in practice - language features like properties, reified generics, functional-like programming with Linq, tuples and its jilt-in support for async APIs mean you can be surprisingly succinct.

Agreed 1000%. Java is backward compared to C# - bolted on half baked features that are the opposite of elegant, a standard library that is built on the principle of 'why use 10 lines when a 1000 will do' and the tools/IDEs are a generation behind C#. As is the runtime speed.

I agree. It is very easy to learn and inspect. Sometimes I just look at function definition and it is immediately clear. This is so far the easiest to read language I've seen. I don't think generics has to be a problem if their use is very limited. I would like to see generics to work like code generators, something like using m4 to generate the similar type, sharing common methods but having a different core type in their implementation. It would be nightmware to have full C++like generics or even preprocessor macros.

Could it be because Go is newer and handles buffer overflows correctly?

Go already supports generics - the hashmap is generic, and the array is generic.

It's just you can't implement your own hashmap in Go, and make it compile time type safe.

> It's just you can't implement your own hashmap in Go, and make it compile time type safe.

Then it doesn't support generics. That is the entire point of the feature.

C also supports generics - just use void * !!

no, Go doesnt' support generics.

void * is the C's equivalent of interface {} it has little to do with generics although it can be used to work around lack of it.

Perhaps there are other ways, but in C you have parametric polymorphism functionality through macros. That's why min() and max() are not functions but macros and they work with any type that can be compared, not just float64.

Reply on news.ycombinator.com