The lack of generics in Go is a non-starter for me. There's polymorphism in built-in types, but these throw out compile time correctness guarantees.
I think generics will come, honestly, but not in an easily-recognizable form. The "go generate" is a small step into the direction this will take, IMO
If you're trying to solve problems caused by your language, maybe the solution is to switch languages.
> I think generics will come, honestly, but not in an easily-recognizable form. The "go generate" is a small step into the direction this will take, IMO
Static code generation is what people tried before templates, which were then improved upon by generics, and that's only looking at mainstream languages--if you're willing to look outside that, there's Hindley-Milner type inference and typeclasses.
The rest of the language design world went down this path decades ago and already made the mistakes Go is making and learned from them. `go generate` is a fucking terrible idea. People aren't saying this because they're afraid of change, they're saying it because they've seen it before. We know how the story ends and it's not a happy ending. The fact that Go's designers can't be bothered to read the book only goes to show that they shouldn't be designing a language, and Go's popularity is only due to a combination of ignorance and hype.
No. `go generate` is great for what it was invented for:
Programs that write programs are therefore important elements in software engineering, but programs like Yacc that produce source code need to be integrated into the build process so their output can be compiled. When an external build tool like Make is being used, this is usually easy to do. But in Go, whose go tool gets all necessary build information from the Go source, there is a problem. There is simply no mechanism to run Yacc from the go tool alone.
Source: https://blog.golang.org/generate
It's not meant as a substitute for generics, it's for running tools such as yacc.
But while we're at it, `go generate` as a substitute for lexer/parser generators is another example of Go being decades behind programming language research. C# and clang have both innovated a lot in this space by writing sophisticated functional parsers by hand using libraries which in C#s case is then exposed in the language. You could go even farther and look into combinator parsers.
Yet again Go ignores decades of programming language research.
Nobody wrote that `go generate` is a substitue for lexer/parser generators. `go generate` is just a mechanism to automate the execution of the generator, as explained by the comment you replied to.
Repeating ad nauseum that Go is "decades behind programming language research" is not enough to make your point :-)
> C# and clang have both innovated a lot in this space by writing sophisticated functional parsers by hand using libraries which in C#s case is then exposed in the language.
Sounds interesting. Any link to share with us?
I found out about Roslyn through hearing Erik Meijer speak at a conference. A quick search shows that the content of his talk at the conference I went to is probably covered in his C9 lectures[3], probably in Chapter 8[4]. But I'm pretty sure that will only cover the parser combinators, which is the algorithm, but not the specifics, of how C# is parsed.
When I was doing C# parsing I was working with the CodeDom[5]. If you just need the AST I think ExpressionTrees[6] are now the idiomatic way to generate it, but I'm not sure how that relates to Roslyn.
Disclaimer: My day-to-day development switched over to primarily C/Python/JS about a year and a half ago, so it's been a while since I fired up Visual Studio. My knowledge is probably out of date, and might be flat wrong--nobody's memory is great after a year and a half.
[1] http://msdn.microsoft.com/en-us/hh543916
[2] https://github.com/dotnet/roslyn
[3] https://channel9.msdn.com/Series/C9-Lectures-Erik-Meijer-Fun...
[4] https://channel9.msdn.com/Series/C9-Lectures-Erik-Meijer-Fun...
It's not. The problem is the number of possible types you want to instantiate a generic type or function over is potentially infinite.
If I write say a binary search tree package, I can only use 'go generate' to generate instantiations for a finite number of types. If a user of my package need a binary search tree of another type, touch luck. The best they can do is use interface{} or start 'go generating' in their own projects.
'go generate' is great for generating code using yacc or Ragel, but it's not a solution to the lack of generics.
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.
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!
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.
Most of the typical design patterns do not hinge on generics or even inheritance and can be implemented easily in Go too.
type interface blah { behavior() }
I completely get what you mean about Go being simplistic and easier to reason than your typical J2EE app. But remember you don't have to write your Java apps that way. Unfortunately "design patterns" took off a decade ago and ended up dragging Java and many other languages into the complexity quicksand.
I hope Go learns from these lessons as it matures.
I'm intimately familiar with the jvm and app dynamics and they do have wonderful tooling.
but, without that tooling I would be really paddling upstream.
call me old fashioned but I like simple tools, and golang I can profile faster and find bugs sooner. I have supported critical infrastructure on both platforms ( Java for many years , golang for 2) and it is not a hard choice to make for me, even with app dynamics and similar tools.
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.
But I don't buy the argument that we don't need them, and that we will necessarily write worse code with them.
For some reason, the core Go team has no need to write general algorithms/data structures. They just...write the code when they need to.
It's a strange way to think about programming, but for me, it can work. You focus on the "executable", not the "library" (I know that sounds strange...)
http://mollyrocket.com/casey/stream_0019.html
For all the people complaining about both (the lack of) generics and high performance systems level programming, this and his allies in the video game industry such as Mike Acton
(Data Oriented Design in C++) https://www.youtube.com/watch?v=rX0ItVEVjHc
and Jonathan Blow (Ideas about a new programming language for games) https://www.youtube.com/watch?v=TH9VCN6UkyQ
argue that performance and the focusing on the problem you are trying to solve are intimately related. Needless levels of abstraction (particularly ones that go against the hardware) and generically trying to solve for cases you will never actually use is a waste of real performance and developer time.