Hacker News Reader

Comment by voidlogic | Hacker News Reader

>The story is, a variety of complex programs are being built and deployed in Golang without generics, which makes it an open question as to whether they're required at all.

This. The same can be said for C as well, but C is not memory safe and Go is- so it wasn't immediately obvious the same would hold for Go.

I used to use generics/templates in Java/C#/C++ a lot, and at first I missed them in Go, but now, after writing Go full time for 2+ years- I no longer miss them more than once or twice every few months... I think generics are great, but also greatly overused.

View on HN

I work with some old Java code that's a mix of generic-ised and not. Every time I see a method that returns a Collection I want to shout "COLLECTION OF WHAT?!?!".

Comprehending other people's non-generic code is a giant pain in the ass compared to reading code with generics.

> Every time I see a method that returns a Collection I want to shout "COLLECTION OF WHAT?!?!"

The method was named something like "getCollectionOfSomething()"? If so, you might want to put some of the blame on the method naming choices.

A method might return, say, some URIs. These might be represented as URI objects or strings, depending on your preference (in some tighter areas of the code we might use String objects, because URIs can be expensive-ish to create, and we might know for sure that the strings in question are valid). If I have a method called getURIs, does it return URIs or Strings? Should the method be called getURIsAsStrings? Perhaps, but it makes for some pretty awkward (and long) method names.

Even if you do have a sensible naming scheme that makes the return type clear, it's rather beside the point. If I have a choice between relying on coding convention or generics, I know what option I'm going to pick.

I'm not arguing the point that generics are unuseful.

But imho the method should not be named for the compiler-type of it's return value (unless it's a type converter like int2string or similar).

It should be named for the bizlogic/semantic type:

So..not "getURIs()", but better "getBackendPoolMembers()" or "getBackendPoolMemberURIs()" if you have more than one way of representing them.

Long method names are fine. Everyone uses autocomplete. Choose good names and rename them often as the meaning of the code changes over time.

That's fair enough - I'm always happy to have descriptive methods names. I still want to know the compiler type of what I'm getting back though.

Naming conventions are often used as (IMHO) poor substitutions for type systems. A name is for the programmer. A type is for the computer AND the programmer.

Generics notwithstanding, Go's slices are typed.

var stuff []MyType

Genuinely interested: do you have a trick for making sorting a collection less copy-and-pasty?

I made a bash script for this purpose, but I have actually only used it twice to be honest.

could you elaborate - what is this about ? Go newbie here.

To sort an array/collection in Go, you must implement an interface with 3 methods: https://gobyexample.com/sorting-by-functions

It's boilerplate, which generic methods would avoid.

There are shortcuts for sorting common types by their natural order in Go, so you only have to write this for custom types or custom orderings.

I am not sure I understand why you need generics for this, doesn't C get by passing a single function pointer?

Could you explain why Go needs an interface with 3 methods?

Type safety, and the lack of fields in interfaces. In C you have to pass the size of the elements to quicksort, but in Go you can't do that without using the unsafe module. So you need a virtual Swap() method. And because Go needs to take a single interface, and interfaces in Go can't have fields, you need a Len() method as well.

thanks I think I understand now.

great, but also greatly overused.

This should be a book or a blog. Seems like the most powerful features of languages are often the downfall of a project. Proxies based on #doesNotUnderstand: or method_missing can be awesome and they can also be misused to render a project incomprehensible. The same goes for macros in C, macros in Lisp, and generics.

Couldn't disagree more with this.

Generics makes code far more readable, maintainable and testable.

C precompiler macros can be (and are) used to provide generic-like semantics.

Go has no such "blessed" precompiler-macro system.

Templates/macros are an ugly solution, but they are a solution.

The simplicity of Go's syntax makes it really easy to use as a target for compile-time generated code, and all of the built-in parsing libraries in the standard lib make it really easy to interface such generated code with human-generated code and at the end of all of this you end up with something much more type-safe than you do with C macros.

So yeah, the toolset may not have anything like the C's preprocessor (the lack of which is a blessing, not a curse, IMO), but that's fine, if you're sure you really need such a thing just spend half a day writing your own in Go that is specific to your project's needs and make that a part of your local build process.

Are there any good examples of this kind of approach? Any tooling support for this?

None that is publicly available that I'm aware of, unfortunately.

No real tooling either other than whatever you choose to use for the build process. For the projects I've done this for that ends up being a very simple Makefile which does a 'go run' on the code generation engine code prior to a 'go build' of the resulting combined package of generated & hand-written code.

Do you use some custom code generation engine or gen[1]?

[1] http://clipperhouse.github.io/gen/ ("A library for bringing generics-like functionality to Go")

Custom -- most of the code generation I've done has been about binding Go functionality into UI markup languages (similar to the way ActionScript binding in Flex works, for those who have used that) as opposed to generics-like functionality.

I've never used gen, it looks pretty nice though, at least based on the linked docs and it is probably a good answer to Pxtl's question about publicly available examples.

> macros are an ugly solution, but they are a solution

Tangential, but a decent example of that sort of thing, a generic red-black tree written entirely in the C preprocessor: http://www.canonware.com/download/rb/rb_newer/rb.h

queue.h is pretty widely used as well: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/sys/queue.h?re...

Reply on news.ycombinator.com