And btw, this doesn't mean that just because there are genericity and polymorphism in D, that I must use them.
Most of the time, I don't even need to use them, like in Go, so I simply don't use them. What I'm saying is that, sometimes, you have to apply a similar function to different types for instance, and in this particular case, using genericiy OR polymorphism can get the job done quickly and in a cleaner way (DRY principle). That doesn't happen all day long, but I'm occasionally in such situation, I really regret there is no native genericity and polymorphism in Go. Using interfaces and stuff can indeed solve the problem in a way or another, but that's far from the simple, easy and obvious way to solve it. At least that's what I feel each time I have to implement such code. Because for web-related development, Because despite I prefer D as a general purpose language, I'm still using Go to develop server side applications which interact with browsers and databases. Its extensive standard library obviously makes it still the best tool for the job, no doubt about it. On Wednesday, August 2, 2017 at 8:36:18 AM UTC+1, ohir wrote: > > On Tue, 1 Aug 2017 05:04:24 -0700 (PDT) > ecstati...@gmail.com <javascript:> wrote: > > > But D also gives you reference classes, genericity, function > polymorphism, > > conditional compilation, design by contract assertions, compile-time > meta > > programming, > > All things above to be avoided in _maintainable_ software. > > Mantra: every working line of code is written once by one person > then it is read hundreds/thousands of times by dozens of people. > > Go spares your pair, then supervisor, from manually enforcing on > you hard local rules: "We use C++ but you are forbidden to use: > exceptions, overloading, auto, weak ... ". Go language by itself gives > you all that -do-not-use-this-and-that- checks for free ;) > > > and many other features that are severely lacking in Go. > Luckily. These and many other features _luckily_ lacking in Go. > Something that can't be used also can't be abused. > > From the software maintainer pov Go is both readable and debuggable. > In Go one may grasp execution path and functionality from the very > fragment of source s/he is reading now. With very few exceptions. > > Throw in any level of meta programming, even simple function overload, > and suddenly reader of a fragment of code is forced to read entirety of > entangled sources then map it mentally - all that just to grasp importance > of that fragment s/he has read a while ago. Rinse and repeat on each level > deep. > > Any business gain (man-hour wise) form higher level 'features' is null, > void > and negative at first bug hunt on production code. More so if said code > authors are long gone from the team. Many businesses learnt this > hard way and now they know better; now they go for Go. > > > But for your command line or desktop developments, I think D could be > much > > more appropriate than Go... > > Unless your CLI/desktop is supposed to be easily maintained for years to > come. > > PS. If one want some joy and entertainment off writing, one may go for > Racket [https://racket-lang.org/]. Every program in it sooner than later > evolves into separate language of its own. Language only author can > understand. Even if just for a while ;). > > -- > Wojciech S. Czarnecki > << ^oo^ >> OHIR-RIPE > -- 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. For more options, visit https://groups.google.com/d/optout.
