Why Go Is Not Good • Hacker News Board

Re: Why Go Is Not Good

#21

Post by Rochus » Sat, Jun 26, 2021, 9:31 AM UTC

pjmlp wrote: post #20

Rochus wrote: post #18

Earlier quoted context omitted.

Never used Active Oberon in a project, but I'm currently implementing an extended Oberon version I call Oberon+ (see https://github.com/rochus-keller/Oberon/blob/master/document... ) which I enjoy using (currently migrating the Are-we-fast-yet benchmark suite, see https://github.com/rochus-keller/Oberon/tree/master/testcase... ). It has generic modules and it is still simpler than Go.

Looks quite interesting, thanks for sharing. Love the simplifications you did, and the generic modules is basically what I have advocated Go should have done, had they actually bothered to look into CLU and Modula-3.

Thanks. Generic modules turned out to be a good fit for Oberon; I can even validate the generic modules before instantiation and even without type constraints; assumptions about types can be hidden using procedure types which is also a good fit for Oberon (I can still add type constraints later if really necessary). The concept is actually mostly inspired by Ada, including the explicit instantiation. It was the first approach I tried, then I switched to the Roe/Szyperski proposal for some time, but which turned out to cause to many complicated rules and consequences not in harmony with the Oberon philosophy, why I finally switched back to generic modules. The approach indeed has similarities with Modula-3, but the instantiation is simpler, and the generic parameters are types, not module interfaces.

Re: Why Go Is Not Good

#22

Post by eru » Sun, Jun 27, 2021, 5:36 AM UTC

DJHenk wrote: post #11

Well, it must be good at _something_, or it wouldn't be as popular as it is. Perhaps it's not a perfect language and perhaps that is not important at all. I use Go on a daily basis and even after doing that for years am still very happy with it. I read lists like these, try to understand what the complaint is and then... I realize that I just don't care. There have been two or three occasions in my career that I thou…

> Well, it must be good at _something_, or it wouldn't be as popular as it is.

Yes, though lots of pretty awful things are popular. Eg PHP.

Re: Why Go Is Not Good

#23

Post by eru » Sun, Jun 27, 2021, 5:41 AM UTC

aliasEli wrote: post #4

User defined operators frequently lead to programs that are difficult to understand, e.g. what is this '+'. When reading you will probably at first assume that it is adding two numbers, but then you also have to consider all other versions of this operator function. A function call with a good descriptive name is much clearer.

Operator overloading in the style of C++ is pretty silly, and your concerns apply.

Have a look at how eg Haskell deals with operators:

- You can define your own, so you don't need to re-use bit-shifting for IO. And in fact, you wouldn't be able to do so.

- There's also specific kind of overloading, so that '+' can work with different types. But eg you couldn't turn bit-shifting 'The rules for shadowing of operators are the same as the rules for shadowing any other function or variable name.

In fact, operators are just a weird syntax to write binary functions in Haskell. Otherwise they behave exactly the same.

Whether to use operators or functions with 'normal' names is then only a stylistic question, and a library can offer both styles to its users. (And you can retrofit the style of an existing library without having to have access to the library.)