Reflections on using Go instead of D

[Ola Fosheim Grøstad]

On Tuesday, 12 July 2022 at 15:56:39 UTC, SealabJaster wrote:
> * I hate that mocking libraries are either external code 
> generation tools or just look and feel like hacks.

How is this better in D? A mocked unit should be a drop in 
replacement...

> * Similarly, writing tests in Go, while it's streamlined 
> similar to how D has `unittest`, the tests themselves can be 
> quite strainful to write.

In what way? D’s `unittest` does not do much?

I usually don’t use testing libraries as writing my own does not 
take much time. Unless you want automated integration tests for 
user interfaces...

> * While generics have made the issue a lot less painful, it's 
> still not nice having to make things an `interface{}/any` just 
> to have some form of reusability in algorithms.

Are you talking about generic libraries? Reusable algorithms tend 
not to be a big issue for applications? What kind of software do 
you build?

What I dislike is the auto generated documentation. D also has 
this issue.

Well written docs are so much better. Write the docs when 
speccing out the API!

Using doc generation for a standard library is just a terrible 
idea.

Three reasons to dislike Go: no real exceptions, lacking 
inheritance, annoying API docs (or APIs).

Builtin concurrency is good, but I seldom would use go routines 
in practice, so not sure if it is the best concept for «system» 
programs.