If Zig can foster a culture of handling errors this way, it'll be the way the community writ large handle errors.

https://github.com/ziglang/zig/issues/2647

You have to workaround by things like passing into a pointer to error object.

For the kind of work I do — writing servers, networking, and glue code — fast compilation is absolutely paramount. At the same time, I want some type safety, but not the overly obnoxious kind that won’t let me sloppily prototype. Also, the GC helps. So I’ll gladly pay the price. Not having to deal with sigil soup is another plus point.

I guess Google’s years of experience led to the conclusion that, for software development to scale, a simple type system, GC, and wicked fast compilation speed are more important than raw runtime throughput and semantic correctness. Given the amount of networking and large - scale infrastructure software written in Go, I think they absolutely nailed it.

But of course there are places where GC can’t be tolerated or correctness matters more than development speed. But I don’t work in that arena and am quite happy with the tradeoffs that Go made.

I think a good understanding of design is also something people don't get about front end. Limited designs from designers means I fill in the gaps in some places.

Dealing with every possible edge case. Breaking out the advanced web APIs when they can easily solve certain problems, e.g. Intersection Observers or Mutation Observers.

Breaking out the advanced CSS APIs like @property rules for super easy and smooth animations.

Improving tooling and JS builds. Making sites fast and reliable.

On and on. Front end can get looked down upon if you're making the same old stuff over and over again. A modal here, a toast there.

But when you get assigned the crazy shit designers come up with, it becomes a very intricate challenge to create the the simplest solutions you can.

What do you mean? Much of the discussion around errors from above link is clearly based on the ideas of Haskell/monads. Did you foolishly search for "monad" and call it a day without actually reading it in full to reach this conclusion?

In fact, I would even suggest that the general consensus found there is that a monadic-like solution is the way forward, but it remains unclear how to make that make sense in Go without changing just about everything else about the language to go along with it. Thus the standstill we're at now.