The naked truth about writing a programming language (2014)
That's a good set of questions for 2014. Questions that have become important more recently include:<p>- Imperative? Functional? Some mixture of both? Mixtures of the two tend to have syntax problems.<p>- Concurrency primitives. The cool kids want "async" now. Mostly to handle a huge number of slow web clients from one server process. Alternatively, there are "green threads", which Go calls "goroutines". All this stuff implies some level of CPU dispatching in compiled code.<p>- Concurrency locking. Really hard problem. There's the Javascript run to completion approach, which reappears in other languages as "async". Ownership based locking, as in Rust, is promising, but may lock too much. And what about atomic operations and lockless operations?  Source of hard to find bugs. Get this right.<p>- Ownership. Rust got serious about this, with the borrow checker. C++ now tries to do "move semantics", with modest success, but has trouble checking at compile time for ownership errors. Any new language that isn't garbage collected has to address this. Historically, language design ignored this problem, but that's in the past.<p>- Metaprogramming. Templates. Generics. Capable of creating an awful mess of unreadable code and confusing error messages. From LISP macros forward, a source of problems.  Needs really good design, and there aren't many good examples to follow.<p>- Integration with other languages. Protocol buffers? SQL? HTML? Should the language know about those?<p>- GPUs. Biggest compute engines we have. How do we program them?