I’ve genuinely never had a problem with it. If something is wrong, it was always going to be wrong.

Have you worked on a production code base with more than a few thousands of lines of code? A bug is always going to be a bug, but 99% of the time it's far harder to answer "how is this bug triggered" than it is to actually fix the bug. How the bug is triggered is extremely important.

Why is it preferable to have to write a bunch of bolierplate than just deal with the stacktrace when you do encounter a type error?

If you don't validate types you can easily run into a situation where you write a value to a variable with the wrong type, and then some later event retrieves that value and tries to act on it and throws an exception. Now you have a stack trace for the event handler, but the actual bug is in the code that set the variable and thus is not in your stack trace. Maybe the stack trace is enough that you can figure out which variable caused the problem, and maybe it's obvious where that variable was set, but that can become very difficult very fast in a moderately complex application. Obviously you should write tests, but tests will never catch every weird thing a program might do especially when a human is involved. When you're working on a moderately large and complex project that needs to have any degree of reliability, catching errors as early as possible is always better.

What I mean is, from the perspective of performance they are very different. In a language like C where (p)threads are kernel threads, creating a new thread is only marginally less expensive than creating a new process (in Linux, not sure about Windows). In comparison creating a new 'user thread' in Go is exceedingly cheap. Creating 10s of thousands of goroutines is feasible. Creating 10s of thousands of threads is a problem.

Also, it still uses kernel threads, just not for every single goroutine.

This touches on the other major difference. There is zero connection between the number of goroutines a program spawns and the number of kernel threads it spawns. A program using kernel threads is relying on the kernel's scheduler which adds a lot of complexity and non-determinism. But a Go program uses the same number of kernel threads (assuming the same hardware and you don't mess with GOMAXPROCS) regardless of the number of goroutines it uses, and the goroutines are cooperatively scheduled by the runtime instead of preemptively scheduled by the kernel.

Key point: they're not threads, at least not in the traditional sense. That makes a huge difference under the hood.

Definitely not a guarantee, bad devs will still write bad code (and junior devs might want to let their seniors handle concurrency).

You can also just tell GitHub to not do that.

I’d rather use a language that doesn’t treat me like an incompetent child, removing unsigned ints because “they’re a source of bugs”.

Why? In my experience using a real debugger is always the superior choice. The only time I don’t is when I can’t.

I finally was able to push back against all the meetings and shit I was having to deal with by making it extremely clear that the schedule was going to slip badly otherwise

My entire point is that you aren’t forced into using that cloud crap for normal development. And you aren’t forced into any specific IDE. You can choose whatever IDE you want unless your employer mandates something specific.

That first paragraph is basically my job now, except for the investors and clients part. We have an actual CTO so he gets to deal with all that crap and I can focus on the tech stuff.

As far as I'm concerned the advantage is I can have three windows (or three editor views) tiled horizontally and each one is the perfect width. A half width (half of 1080p/16:9) is too narrow and a full width window wastes space, but a 2/3 (of 1080p) width window is about perfect. If I tried to do that with two regular monitors, the middle window would be split across the bezel.

*When I say 1080p, I really mean the aspect ratio. My monitor is effectively a double width 1440p monitor, but with the display scaling I use the space is effectively 1080p.

I wonder how relevant this is to Go (which is what I work in these days), at least for simple data retrieval services. I can see how transforming code to a functional style could improve clarity, but Go pretty much completely eliminates the need to worry about threads. I can write IO bound code and be confident that Go will shuffle my routines between existing threads and create new OS threads as the existing ones are blocked by syscalls. Though I suppose to achieve high performance I may need to start thinking about that more carefully.

On the other hand, the other major component of the system I'm working on is responsible for executing business logic. It's probably too late to adopt a reactive programming approach, but it does seem like a more interesting problem than reactive programming for a data retrieval service.