1:04am I have coded for thirty hours straight.
I'll finish JIT soon.
6:05am JITs almost done, a strange door has appeared
near my desk. I can hear faint meowing.
27:67am THE DOG IN YELLOW
HAS SANG ITS MEOWING.
OBLIVION IS THE KEY.
The article makes it sound like "errors occurring in the library code" is a major problem, but forgets to mention how much that also contributes to its strength and simplicity. in Lobster I took great care to make these type errors look very readable, like a compile-time stack trace.
Also monomorphization does not always produce code bloat. All these copied (typically small) functions tend to get inlined, and inlining has a habit of cascading, allowing parent code to be simplified and reduced in size etc. Contrast that with boxed generics that use virtual calls, which act as a barrier to optimization since we have no idea what it will do, and which of the many methods it will call. That can result in a lot of code that is present in the compiled code that is not actually needed (which would be a bigger problem for AOT languages like Go than JIT languages like Java, since "dead" JVM bytecodes don't produce code cache misses).
In a sense, monomorphization is a good match for AOT and expressive type systems, and boxing works better for more dynamic implementations and simple or no type system. Languages like Go straddle these the two extremes uncomfortably.