jtasdlfj234

Virtual Threads, under the hood, cooperatively yield at IO boundaries (on supported APIs)

Please prove me wrong on these points. My current belief and understanding is that:

1. `foo(T)` indicates polymorphic over both `T::T(const T&)` and `T::T(T&&)`. This gives you benefits of both pass-by-move (using `std::move` as needed), or copy.

2. Usage of `foo(T&&)` signals code-smell or an anti-pattern as `foo(T)` should be used instead unless it is perfecting forwarding / universal reference `template <typename T> foo(T&&)`.

Okay, circling back here. So your position is that nil safety would reduce the value of Go's "getting things done"? As someone who uses Go in production, I don't agree at all.

Dart evolved into a nice language with null-safety and exhaustive patterns.

Hopefully in Go 3, we could see these features added as well.

> It's so derpy.

That's why I love it.

Excellently described.

I'd love to see a resource that highlights these all on a table across programming languages as well as the associated strengths and weaknesses of such threading & concurrency models.

Perhaps a ByteByteGo graphic, if you will.

I would have more respect if they at least admitted to the flawed type system but instead say it is not a problem. It is disappointing to see past mistakes repeated in a new programming language. Even the Java language creator was humble enough to admit fault for the null pointer problem. The Go devs do not have such humility.

https://github.com/uber-go/nilaway