5 ms·
>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 requ
by voidlogic 13y ago
>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.
- justinsb 13y agoGenuinely interested: do you have a trick for making sorting a collection less copy-and-pasty?
- voidlogic 13y agoI made a bash script for this purpose, but I have actually only used it twice to be honest.
- sandGorgon 13y agocould you elaborate - what is this about ? Go newbie here.
- justinsb 13y agoTo sort an array/collection in Go, you must implement an interface with 3 methods: https://gobyexample.com/sorting-by-functions 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.
- riffraff 13y agoI 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?
- pcwalton 13y agoType 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.
- riffraff 13y agothanks I think I understand now.
- Pxtl 13y agoC 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.
- georgemcbay 13y agoThe 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.
- Pxtl 13y agoAre there any good examples of this kind of approach? Any tooling support for this?
- georgemcbay 13y agoNone 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.
- Matrixik 13y agoDo you use some custom code generation engine or gen[1]? [1] http://clipperhouse.github.io/gen/ http://clipperhouse.github.io/gen/ ("A library for bringing generics-like functionality to Go")
- stcredzero 13y agogreat, 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.
- threeseed 13y agoCouldn't disagree more with this. Generics makes code far more readable, maintainable and testable.
- AlisdairO 13y agoI 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.
- wreegab 13y ago> 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.
- AlisdairO 13y agoA 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.
- jbert 13y agoI'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.
- 13y ago