hi jan,
i mostly share your perspective, but i may be a bit more optimistic.
the language as-is can be used to write horrible code already (i know
because i did and still sometimes do). i am also sure that many will
"abstract prematurely" before they see the light and come to reason (i
will probably do the same, because it is part of the learning process).
but i also have trust in the go developers and community and they earned
it. i am optimistically certain that the go standard library will not
morph into an java-esque object-hell (as some others seem to fear), not
only because many of use would nag and complain as we do, but because
the developers set out with - or flocked to - this same ideal of less is
more.
on the other hand are valid use-cases currently covered by code
duplication, code generation, and empty interfaces. that would often
gain from a clear type signature in addition to the existing docs or
well vetted and battle tested data structure packages. how many project
have their own tree implementations with subtle bugs, that nobody had
time to properly review? how many ways are there to generate code? how
many copy and pasted blocks of code have missed a change in the last
line? i know i have read papers that quantify these types of errors (i
think it was from someone involved in the findbugs project in java
land). although i don't remember details, i know it was not pretty and
mirrored my own experience reading and writing code.
my argument is, that if you do not use generics in your own code, but
libraries used by you do, then you would still need to read the docs and
learn the api - not a big difference from that perspective.
in the best case we add some type-safety, avoid obscure code generation
scripts, error prone duplication and simplify some apis, all while
making some code more comfortable - and other code even possible to write.
in the worst case we have some inappropriately popular libraries and
frameworks that use generics, that we can decide to ignore as a company,
group or individual. i would argue that we already have them here and
there and they don't particularly rely on generics to exist.
i think that go is what it is, not because of the language spec, but
because of the people that use it as to write code. nobody is perfect,
but we have many brilliant people on this list with a whole lot of
experience. i learned to trust the decisions of the go developer team
and they earned my respect and gratitude. the reason anyone would freely
choose go to write code is tied to the ideas, works and decisions of
these some people. why would i stop having trust in them now?
On 13.03.21 14:09, Jan Mercl wrote:
On Sat, Mar 13, 2021 at 1:44 PM Martin Schnabel <m...@mb0.org> wrote:
as far as i know there is no reason that anybody has to write code with
generics when they are available. therefor i really don't understand the
negative mails to this list.
That nonchalantly ignores that code is way more often read than written.
"Clever" use of preprocessing macros can make C code unreadable to
anyone other than its author unless learning the mindset behind the
macros. Symbols in the binary can have very little connection with the
symbols in the source code. Nice tar pit for transpiling/debugging
etc. I believe that's why Go does not have C macros or anything like
that.
The problem with generics is not the same, but it shares some of the
problems depicted above. The no more existing 1:1 symbol mapping is
the one I regret most by a wide margin. Goodbye easy and simple
grepping.
Good use of generics _will_ be good for Go, don't get me wrong about
this. But, when looking at random code in the wild, let me ask: What's
the ratio of poor vs good code one encounters at random?
And don't get me wrong the second time. I'm writing a lot of poor
code. Once I start using generics, my future self will be probably the
first one to curse me for that.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/5880b473-4198-8c4a-fcb0-faa4a3c07f3d%40mb0.org.
