5 ms·
In the other hand, it helps prevent people to build needlessly complex abstractions. That's what I like about go: relatively straight-forward code to read in mo
by zimbatm 12y ago
In the other hand, it helps prevent people to build needlessly complex abstractions. That's what I like about go: relatively straight-forward code to read in most project that I have seen.
- seanmcdirmid 12y agoI think it is worth the time to figure out how to do generic code better than it is currently done with parametric polymorphism and templates. And yes, I think going simple on the type system is a valid direction (vs. Scala which focuses on power and expressiveness). But I don't buy the argument that we don't need them, and that we will necessarily write worse code with them.
- 4ydx 12y agoYeah I have to second this, a lot of people are really off the mark about how "useful" their abstract solutions to a problem are. Often something is very over-engineered. Once you have to build anything complex on that type of foundation, well, good luck to you! Besides from what I understand the lack of generics is mostly about compile time speed. I love how fast go compiles and would rather that not change.
- seanmcdirmid 12y agoTemplates are slow to compile, most modular parametric polymorphism solutions are pretty fast (C#, Java). Barring Scala...but to be fair they have a lot of other things going on in their type system!
- spotman 12y agoagree. when it's 3:42am and you get called in to debug something in a production system in the middle of the night, it's a hell of a lot quicker to visually and mentally parse and digest golang without all these abstractions and "elegant" ways to do things. (than some languages like java) yes go lends code to be verbose and simple, at times feeling like you must make things too much so, but the rate at which I can understand what someone else is trying to accomplish and vice versa, I keep choosing golang, and it's verbosity. at the end of the day, for me, verbose and simple is preferred to elegant and clever. to an extent, of course.
- danieldk 12y agoagree. when it's 3:42am and you get called in to debug something in a production system in the middle of the night, it's a hell of a lot quicker to visually and mentally parse and digest golang You think this that functions returning interface{} are easier to debug than functions that return a specific type? Because that's exactly what you are throwing away with generics. Allowing specification of the element type of a container data structure is not unnecessary abstraction, it's type safety!
- howeyc 12y agoIt's more than likely the function will return an object of type blah type interface blah { behavior() }
- danieldk 12y agoNot in a container, where generics are typically used. Of course, blah could be an interface requiring a comparison or hash method, but the effective result is the same: you have to do reflection to find out what is in the container, there are no compile-time guarantees.
- spotman 12y agowhile that's an example that I do see in the wild, not every function returns interface. but it doesn't really hurt my argument. if I have a function that returns an interface I can grep who is calling it and probably digest what it is within a few moments and probably 2 or 3 files of code. with java I find its so once you get through the factories, abstractions, and more, I have never found what I'm looking for in 2-3 files until I am more intimate with the code base.
- danieldk 12y agowith java I find its so once you get through the factories, abstractions, and more Most of the typical design patterns do not hinge on generics or even inheritance and can be implemented easily in Go too.