I agree with you that the code must be developped using the KISS principle.
Look at the D code of my github account. All you will see is "baby-code". The more complex stuff I use in D are genericy and polymorphism. And, from my personal experience, the lack of genericity and polymorphism in Go often forces me code in a less straightforward manner than in D. I have to find an indirect way (interface, etc) of doing something that would be simple and straightforward in D. Maybe I'm force to develop more powerful or sophisticated code in Go's way, I don't know, but I will never say that my Go code is much easier to program or to maintain than the same implementation in D. My github account is now full of tools progressively converted to D from an initial implementation in Go or Node.js, so I begin to have some experience in switching a tool from a language to another... 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.
