> The issue you are talking about is not a language issue, it's an ecosystem issue. K recognizes it by not trying to be all things to all people - it's incredib

> The issue you are talking about is not a language issue, it's an ecosystem issue. K recognizes it by not trying to be all things to all people - it's incredibly easy to FFI directly, and to connect through various interprocess methods (including a native efficient KIPC well supported from just about every other language environment). I'm afraid this only makes my point stronger. If I'm pushing the ugly complexity outside of K with an FFI, I'll be stuck writing the ugly plumbing (a major part of the job) in some other language. For the uninitiated it is very difficult to say whether or how much will be left for K to handle, if anything. That kind of thing would make K look like a one-trick pony, and maybe not worth investing in. > Most project specs today include requirements that are accidental complexity, rather than inherent. I agree, and I'm afraid that in many projects (including my dayjob) the accidental complexity is the bigger job. Even if I could solve the inherent complexity of all we do in one beautiful line of code, we're still stuck with a mountain of crap from 2-3 decades of legacy and bad design that really can't be changed.