jtasdlfj234
Re:Async file IO in Java is not truly async [Resource, Tech blog]
on Monday January 08, 2024 @05:04PM (#38918871)
Virtual Threads, under the hood, cooperatively yield at IO boundaries (on supported APIs)
Re:Don't pass structs bigger than 16 bytes on AMD64
on Friday January 05, 2024 @12:11PM (#38881530)
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&&)`.
Re:Go: What We Got Right, What We Got Wrong
on Friday January 05, 2024 @09:01AM (#38879113)
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.
Re:Go: What We Got Right, What We Got Wrong
on Friday January 05, 2024 @12:42AM (#38876095)
Dart evolved into a nice language with null-safety and exhaustive patterns.
Hopefully in Go 3, we could see these features added as well.
Re:Go: What We Got Right, What We Got Wrong
on Thursday January 04, 2024 @06:02PM (#38873519)
> It's so derpy.
That's why I love it.
Re:Go: What We Got Right, What We Got Wrong
on Thursday January 04, 2024 @05:40PM (#38873293)
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.
Re:Go: What We Got Right, What We Got Wrong
on Thursday January 04, 2024 @04:50PM (#38872765)
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.