Typescript looks nice to work with but the tool chain is horrible (this isn’t really Typescripts fault though, more a synonym of it having to compile to JS).
Go looks horrible to work with (too simplified syntax) but is actually really nice because the tooling is (mostly) spot on and it’s simplified syntax weirdly helps with maintainability for large projects that have evolved over multiple years.
I guess this just goes to show how much personal preference can be a driving force behind our platforms of choice.
The same goes fo Go. I have a mapping for if err != nil { ... } and the cursor is places inside the block.
I dont understand why people dont use this kind of thing for the most common programming constructs.
Coding software that works when conditions are met is easy. Coding software that works when things break is hard. So I want error handling to stand out because it forces errors to be handled visibly and properly.
All too often I see Python programs drop to a stack trace under normal execution or JavaScript return cryptic errors that don’t mean much to anyone bar the core maintainer. But I seldom see 3rd party Go software bomb out in quite the same way. And I think that’s in large part because Go doesn’t try to hide errors away as an inconvenience that we shouldn’t be looking at.
So I’ll agree Gos approach is ugly. But sometimes good software does just look ugly. And the way I see it, it’s the quality of the compiled software that matters more than the beauty of the combination of characters that built it.
The sad part is that people have been talking about this for years but Go team stubbornly refuses to make error handling more ergonomic.
It is, but it's also subtle, and if you want branches (especially sad-path branches) to be explicit, that's not a good thing.
Sure there are some Go specific stuff in there. But the whole thing reads more like someone preaching an irrational hatred for something rather than a fair breakdown of genuine footguns.
I’d be interested to know which libraries you’re working with where this has been a problem because I’ve only ever experienced one occasion where a 3rd party library panicked unnecessarily.
It's not even inherent to TS that the toolchain must be a morass of moving parts and multiple config files, as shown by Deno in contrast to Node.
I guess this just goes to show how much personal preference can be a driving force behind our platforms of choice.
Technically, it provides an improved type system that offers the tooling to write safer code.
In practice, plenty of folks just rename the file extension and keep coding as they always did.
Really? Me and my team been using it for years with no problems whatsoever.
I do admit Go has an easily found foot gun: nil pointers. It's a small one though, in comparison to the original problems with nil pointers. More stubbing your toe than shooting your foot.