drvd

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.

This seems roughly 2 month early: Would make a funny read on April 1st.

There is a difference between a software (executable) and a library. Semver is overrated but at least common and well understood with clear semantics. And no, Go 2 probably will be Go v1.23.

A module developer _can_ change the URL if the want to introduce a breaking change. Absolutely no problem here. But they do not _have_ to: Adding the version as v2, v3, ... to the module name works also. Nobody is "forced to adopt urls ending in /v2". Go modules work pretty well, are very flexible but seem to differ too much from what people are used to and nobody really seems to read all the available documentation and descriptions of why that way and not how language X does it.

That is the difference between a clock reading and a timestamp.

Go is fast. No interpreter, no JIT, plain machine code combined with the ability to lay out your data like you can in C.

Running "go mod vendor" just populates the vendor folder which allows local development with all tooling. It does not force you to check in the vendor folder (you can even .gitignore vendor). Doing "go mod vendor" is not the typical "vendor", it does not make you the owner and you do not need to support and audit these packages (unless you actually vendor them in the sense of check them in).

> 0.5 is a real number

Yes, and it is one of the few we have no problem with (7 is an other example of this class): The rationals (or the algebraic). Unfortunately the vast majority of the reals are not that catchy. E.g. we still do not know how many reals there are. The reals are a beast if watched from a fundamental perspective.

If a dam burst it kill a lot of people in short time. And 36 hours later rebuilding the infrastructure and towns begins.

If a reactor bursts it might not kill lots of people but it will devastate a large area for a very long time. We still do not know internal details about the Fukushima reactors because not even robots can go there.

A dam burst is a nightmare but it is a nightmare which is easy to clean up afterwards. A reactor catastrophe is a nightmare nobody knows how to clean up at all.

Germans are not so obsessed about not paying taxes like e.g. Americans or Swiss. Nobody likes to pay taxes and everybody complains about the high taxes. But I think (actually hope!) that Germans understand (if only unconsciously) that happiness is much more depending on getting old without fear of poverty, knowing to be treated if ill, being able to go safely outside anytime anywhere, not dropping out of society if bad luck happens and getting proper education than on the single only monetary principle "I don't pay taxes!".

No. Docs are very complete, readable and helpful.