D is another gem (while established in its own circle, it's not mainstream, therefore a "gem") I'd suggest people to give a try. Also Nim for crazy powerful compile-time features.
There's more to a language than just features and functionality though. Why does Clojure have adoption despite being the least powerful Lisp, created decades after Common Lisp? Its stdlib, default data structures, and even syntax make it compelling (yes, sometimes having a deliminiter other than parentheses is helpful, and no being able to define new syntax via macros is not the same thing because defaults are important). Its not bad to rehash language features that have existed for 50 years if the resulting language has other compelling qualities.
Depends on what you think the cause of the lack of adoption is. If you think it can be fixed by doubling down on existing languages, then sure. But I don't know if that's addressing the cause (because I don't know the cause).
I use Lisps all the time and love them. But I recognize that most people don't like them. At some point we have to meet people where they are, if we want to have broad impact. Ideas on their own aren't good enough, they need to be packaged up in the right way, approachable to the right people, marketed appropriately, etc. The tech itself is just a small part of what it takes for an idea to create impact.
Yes. But you could see the new crop of native languages as: as close to LISP as possible without codegen in the runtime. There is this 2x gap between JIT and AOT.
(EDIT: Other than that I'm not sure if any of the new kids can introspect on the content - lines of codes - of a function, like LISP would).
Lisps support AOT compilation since several decades, image tree shaking, and actually having a compiler in the runtime allows for tooling that most languages lack.
The problem is that all of these languages are at least partially derived from C or C++, where memory layout is inverted relative to something like Fortran (which seemed to get this right from the 1960s) when you consider most cache lines on most processors. Therefore you must either go through hoops yourself tinkering with layout in languages not built for it or add much more complexity to a optimizing compiler (like gcc or llvm). I feel Fortran got this right, and Pascal and C was where languages flipped the norm. I kind of get why they did this, because in the 80s and 90s there were so many varying architectures, the memory wall was a very real thing. Actually Simula60 (a monte carlo language), probably had the right abstraction level (everything is just a block), but this was before things like stacks, heaps, trees, and other data structures were permanently etched into people's brains.
I like how Julia implemented this (but they use Fortran-like defaults, with clear inspiration from matlab, numpy, etc), with a relatively compact set of functions to do any sort of "index ordering": https://julialang.org/blog/2016/02/iteration/
Rust is very much a child of Ocaml (with a lot of idioms form haskell) with much more control of memory than pretty much any other language (which probably makes it better for implementing complex or safety critical things like optimizing compilers or an operating system). Actually, learning any ML language is probably easier than Rust, but you'll get more fluent at a ML-like (expression based) language like Rust. For me, I felt like I understood Rust way more after looking at how rustc works and started unlearned everything I knew about C/C++.
> C or C++, where memory layout is inverted relative to something like Fortran (which seemed to get this right from the 1960s) when you consider most cache lines on most processors.
How do you mean? As I understand it, the only difference in these languages in this regard is in 2D arrays, where in C, the current row is in the current cache line and in FORTRAN the current column is in the current cache line. It seems to me you are if anything slightly more likely to want to do several operations on the current row, so the C way is better. What am I missing?
I assume you mean a widely-used one. There's a handful in development. Have you looked at Redox? :)
Ed: I really don't mean this to be snarky, even though looking back it kind of sounds like it. Sometimes you just have to stop fretting about phrasing, slap a smiley on and ship the thing...
