A sad day for Go, the pHDs have won, simplicity has died.
Go: Support for Generic Methods
51–60 of 288 posts
Re: Go: Support for Generic Methods
#52Earlier quoted context omitted.
Maybe, but personally I've become quite tired of programming languages "organically grown" as opposed to properly designed the first time. After a good decade of C then C++, I found ANSI CL (despite being a massive compromise and unfinished) much more coherent and complete than both.
Scheme is (or at least was) coherent. You don't need to look any further than set/setf/setq to see that Common Lisp is "organically grown" from the fertilizer of a committee. CL does its best to make every other lisp more attractive.
Scheme has a coherent and minimalist design, but its ecosystem and abstraction facilities feel too sparse for large applications.
When I started building a Lisp-based machine learning framework, Guile seemed like the right choice because it provides GOOPS and generic functions, yet I still ended up with a lot of boilerplate to compensate for the lack of a strong type system.
Scheme feels to me like C is to C++: not ergonomic for large-scale application development. Go is one of those languages that has both minimalism and productivity.
Re: Go: Support for Generic Methods
#53slowly implementing all the things they said we didn't need
Where did "they" say "we" didn't need generics? That sounds like a bad faith / misinterpretation / straw man; as someone else pointed out, they postponed generics until they figured out the use cases and whatnot.
Remember that the generics implementations in other languages (like Java) take up half the spec + implementation - that's not something that Go wanted.
Re: Go: Support for Generic Methods
#54A sad day for Go, the pHDs have won, simplicity has died.
It only died if you actually applied it in your own codebase - as with any feature, using it is optional.
Re: Go: Support for Generic Methods
#55Earlier quoted context omitted.
It's not a bad thing to realize that one can be wrong and then strive for change.
Maybe, but personally I've become quite tired of programming languages "organically grown" as opposed to properly designed the first time. After a good decade of C then C++, I found ANSI CL (despite being a massive compromise and unfinished) much more coherent and complete than both.
"properly designed" - ah yes, programming languages are famous for universally agreed upon design philosophies.
Re: Go: Support for Generic Methods
#56Earlier quoted context omitted.
Maybe, but personally I've become quite tired of programming languages "organically grown" as opposed to properly designed the first time. After a good decade of C then C++, I found ANSI CL (despite being a massive compromise and unfinished) much more coherent and complete than both.
I know Go is justly criticized for many of its design decisions, but it still feels well-designed and "small" to me in day to day usage when many other languages don't.
Eh, the thing with generics coming late is pretty much what I meant by "organically grown".
My best litmus test these days is support for multidimensional arrays because it's always needed at some point in general purpose languages. CL and Ada had it right from the start while C++ needed C++23/26 to get std::mdspan and we still need to wrap it to pass the underlying/owned memory pool around (https://rosettacode.org/wiki/Multi-dimensional_array for more).
Re: Go: Support for Generic Methods
#57This is great. Will be useful for data access methods! As for the detractors, from the first generics proposal this was called out as a "not now", not never. There were questions of implementation. They aren't a super large team, and they try to do things incrementally and do them well.
> As for the detractors, from the first generics proposal this was called out as a "not now", not never.
What? The post quotes the Go FAQ as saying, "we do not anticipate that Go will ever add generic methods". There is also some similar discussion of the original generics proposal, with language like "then it's much less clear why we need methods at all". (I'm omitting some context, but I don't feel that it changes the meaning.) Those feel much closer to "never" than "not now".)
The post is also subtitled "A change of view".
Re: Go: Support for Generic Methods
#58slowly implementing all the things they said we didn't need
complaining about things given to you for free
Re: Go: Support for Generic Methods
#59Earlier quoted context omitted.
It's a highly successful language because (1) it was backed by Google, and (2) created by Robert Griesemer, Rob Pike, and Ken Thompson. If it came out of anywhere else, it might have struggled even to hit the homepage here.
This logic is easily shown to not hold. Why isn't Carbon, Dart, etc. not really popular then?
I can't speak about Dart, but Carbon had just barely started development when it was first announced 4 years ago, and is currently presented as an experimental language that is not yet ready for use [0].
0: https://github.com/carbon-language/carbon-lang#project-statu...
Re: Go: Support for Generic Methods
#60Earlier quoted context omitted.
Maybe, but personally I've become quite tired of programming languages "organically grown" as opposed to properly designed the first time. After a good decade of C then C++, I found ANSI CL (despite being a massive compromise and unfinished) much more coherent and complete than both.
So which language had it right from the start? is there a language that has a very low rewrite status?
I think Elixir is a good candidate here. It's small, coherent, and composes well, and (at least to my understanding) the authors consider the language finished, with no new major features planned.