drvd

So a stripped down variant of cue? Why not use cue directly?

Not to mention Rad.

> total idiot

This. Basically all public economists agree on Lindner's ideas and behaviour to be nonsensical. So he either is an idiot or a puppet.

Either we work at the same company or this is a recurring theme everywhere.

Unfortunately the gnuplot palettes are broken (but easy to fix).

> Yes, you need the protection.

You lost me there. This is the fundamental problem with Scrum; this type of paternalism where "programmer" is a synonym for "idiotic code monkey", borderline autistic who isn't capable of dealing with demand from the outside. And all programmers are the same, all organisations are the same and all type of development work is the same. Everywhere. If only we would be doing "Agile" right.

> Scrum is meant to protect the team from changing requirements mid-work

Do I need this protection? Why cannot I protect myself? Do I want this type of protection? Especially if it comes with all the negative downsides of Scrum.

Scrum is based on the imho often wrong assumption that a team needs "protection" of some sort. If your team consists of 16 year old youngsters only this might be true and this type of protection might be useful.

All this "protect the team from changing requirements mid-work" is nonsensical anyway, because no _really_ valuable work is done in 2 weeks. If the requirements _really_ changes you have to throw away the code for the old requirement. You can throw away 2 weeks of coding or 2 days. I'm pissed off more by 2 weeks of dead code. If the requirements adopts a bit its better to adopt early. And change in focus and priorities (which is _not_ a changing requirement): I'm happy to do so if I'm convinced it's for the good of the company and I'm happy to say "Sorry, this will have to wait until I'm done with what I'm currently doing. Please come back next Tuesday.".

Nothing. Major versions of Go modules can be kept _either_ in a directory _or_ a branch. (The OP just doesn't seem to be aware of the branch option.)

> I am [...] quite experienced in Java and Js/Ts. > I never jumped the Go bandwagon because of the lack of generics. > Can I now try Go?

Probably no. You still would be very disappointed. Go's take at writing and maintaining software often is pretty repugnant to people with a strong Java or JavaScript mindset. If missing user defined parametric polymorphism ("generics") was a reason to not even _try_ it you will be offended by by other things Go does in its particular way. Be it error handling, pattern matching, concurrency, mutability, etc. Basically if you try to write Java (or JavaScript) programs in Go you will suffer and hate Go. Same for C++/Rust aficionados. Go's newly added "generics" still come without "library support".

Whenever I see that quote being used to spurn Go I'm amazed of the seemingly large number of language researchers of a calibre of Wirth, de Moura or Wadler and the few actual used languages on the other hand.

In Go

    func foo(x int) { return x + 1 }
    var y *int = nil
    foo(y) // compiler will flag thi

Some people think Optional/Either/etc are the absolute cure to a certain sort of problems and -- I speak from experience -- it is impossible to convince them that it's not.

Well, of course, if your end users, the business users, are okay if you present them an "optional result" which might or might not be a result, then Optionals/Either _are_ the cure. Unfortunately most end users are pissed if you tell them that you optionally shipped their purchase or that the refund will either be credited to their CC or not.

Programming in Go since 10 years and I do not have to worry about nil pointers. You seem to assume that the possibility of a pointer being nil is something that is complicated, a burden to the programmer and a source of runtime bugs. It's not. At least not in Go. At least not something you have to worry about in practice.

> How can r not be nil, when it contains a nil value?

In the same way a slice can contain one or more nil values without itself _being_ nil. A gift box containing nothing is not itself nothing.

> And the reason is hopefully apparent from the previous two lines: It depends on the type of "nil".It depends on the type of "nil".

Well, no. "r == nil" tests whether r itself is nil (i.e. the zero value of that interface type) which it is not. It contains b and is thus no longer nil. The type doesn't play a (large) role here. This misconception might be due to the fact that lots of types can be nil: slices, maps, channels, functions and (unfortunately) interfaces.

Nobody is astonished that a slice containing any sort of nils is not nil itself; that a buffered channel containing nils is not nil itself and that the constant function `func()*int { return nil }` is not nil itself either. Only for interfaces this poses a problem. If interfaces wouldn't be "nil" but lets say "zilch" than it would be evident that r != zilch.

Sorry to hurt your feelings, but it is not. The _compiler_ cannot know whether the code in a package might be used (e.g. because the package is just used to register some stuff; a common example being image file formats). Only the _linker_ can strip unused stuff. This has nothing to do with bad language design, most languages work that way.