I never thought people will actually come up and defend code duplication. It's definitely more than ugliness. The need to fix all the copies when they need to be updated is a bigger problem.
It's fine that you don't agree with our tastes, but it would be nice if you could stop coming into every Go thread and being condescending about it.
Like PostgreSQL and OpenBSD, I've been permanently turned off Rust because I never want to be left at the mercy of a community that invests so much time in harassing and insulting others.
Please tell me where you've been harrassed and insulted by the Postgres community? Sometimes people come into the IRC channel and say something that doesn't make sense and are told it doesn't make sense, and sometimes those people get very upset, but I wouldn't classify that as harrassment. And that's basically the strongest reaction you'll ever get from anyone in the community.
Any active comments thread related to MySQL attracts a derailing holier-than-thou invasion telling us how dumb we are for not using PostgreSQL. PostgreSQL's advocates haven't quite reached the arrogance level of Oracle DBAs, granted, but they're a lot more active.
I basically stopped using (public) IRC somewhere around 2000. I have little idea what goes on in PostgreSQL's IRC channel(s). I expect it's toxic, but I'd expect that for any project's IRC presence. Public IRC is an inherently toxic medium.
That doesn't sound like anyone I know of who actually works on PostgreSQL, and certainly not anyone I'd consider part of the PostgreSQL "community." The mailing lists, IRC channel and other forms of community communication are much more hostile to Oracle than any other RDBMS, and anyone who tries to start a flamewar there (particularly one about MySQL) is instantly shut down. I'm really sorry that you've been turned off from great technology by the actions of some overzealous Postgres users.
Except, I also talk good about Go in what concerns using it to replace C, specially in possible uses for real systems programming in a GC enabled language.
After all, when compared with the first Oberon version, Go only needs a few more primitives in runtime and unsafe, Kernel and SYSTEM in Oberon respectively.
This is what attracted me to the language in first place.
Agreed! But what this means is that when you decide not to apply DRY, you need to have a reasonable justification. Code duplication in general is a bad thing.
Now you are shifting to a editing dilemma. Code duplication is not machine code duplication which is what really matters at execution time. Reading is also easier (even for non-Go programmers at least familiar with C) without templating-like syntax.
Machine code duplication is spending a few extra megabytes on perfectly valid, if duplicate, machine code.
Source code duplication is a risk of spending an hour, or maybe a day, of developer's time to detect the duplication, change it in concert in several places, with an occasional need of detecting and fixing a subtle discrepancy between the copies.
RAM is $0.015 per megabyte. Developer time is $50 per hour.
You could also spend that developer time trying to untangle code reuse between various components, or the more subtle breakages caused by changes that don't account for the expectations of all callers. Code reuse is still a tradeoff.
It should be noted that generic code is harder to break. It is, by definition, less entangled with its callers. There are also fewer operations you can do with generic parameters, so there are fewer ways to screw up.
Code duplication is definitely a programmer problem, not a machine problem. It's also a major problem. Code duplication increases the probability of programming errors, and makes maintenance harder. Any modern language with poor tools for keeping duplication at bay is suspect.
