2 ms·
At 2/3 of every screen, error handling is absurdly noisy. A DSL for wrapping and bubbling up errors (the 99% case) is desperately needed. The builtin container
by erik_seaberg 4y ago
At 2/3 of every screen, error handling is absurdly noisy. A DSL for wrapping and bubbling up errors (the 99% case) is desperately needed.
The builtin containers just suck. They’re always mutable. Map write conflicts might panic, yet there’s no support for preventing them. They aren’t comparable, which can cause panics elsewhere. You have to pretend slices have move semantics, because copies may or may not share state after an append. They don’t implement any interfaces, so you can’t even replace them or reuse their sugar.
Functions can return tuples, but tuples aren’t first-class, there are no maps or channels of tuples.
No overloading, each type sig needs its own func name and IDE refactoring won’t choose the right one.
Reflection is very limited. No access to types or functions by name. No type or func or arg annotations, just a single string on a struct field.
The GC design is pretty old and people go out of their way to avoid relying on its throughput.
Liked: The memory footprint is pretty small. Parts of the community are starting to rely on code generation to work around the base language (e.g., piles of ignored boilerplate because Mockito can’t be implemented at runtime).