Rust is really nice for pattern matching on static types, and reading and writing data in simple imperative syntax, and amazingly, the subset of it you use most of the time is pretty well 'pure' in the functional sense. You can write functions and know they only read the data they are given, or write to the caller's local copy of something, without having to write any higher order functions, or trust complex webs of invariants and code comments.
The problem with Rust, though, is that ever since the 'modern C++' people took over the language, it's been forced into this worst of both worlds dynamic, where you are eternally trapped in the 'safe' subset of C++ that the Rust language lints as allowed, but despite this restriction, you still have to spend every minute of your life thinking about pointer and memory representations. The difference between references, boxes, reference counting, make for exactly the sort of thing that a compiler could optimize, but the rust compiler can't, because smart pointers are all defined in userspace, because it's got to be like C++, or the C++ people will get sad.
Rust has other problems; it copies Haskell's typeclass system, instead of ML's older functor system, and so its typeclasses ('traits') are basically useless for anything you want to do in practice. It's better to just use polymorphic functions, and not touch traits if you don't have to. Plus there is a culture for 'iterator' and higher order function clever craziness, instead of just, writing the code that does what you want.
On the other hand, I program in Erlang for work, and everything is simple, and does its job, and I can just think about program logic, instead of aliasing semantics. This is what high level programming should be like! This pushed me away from my earlier low level language ideas, back towards my even older high level, interpreted ideas, but this time with the goal of stripping away all the crazy module systems, to just make a nice pass-by-value language.
The implementation I have so far is at github.com/spiveeworks/phosphate.
Before I was interested in making a high level language, I was interested in making a really low level language, halfway between C and LLVM.
I have a lot of concepts for language ideas floating around. My interest in languages has declined a lot since I realized that C99 is the best programming languages there is, but the academic aspects of these languages are still kind of interesting.
The main language that I actually implemented was a type checker/symbolic evaluator for a dependently typed programming languag/proof checker that I called lofer. The design was focussed on impredicative/Church encoded data, with postulates, and plans for special type checking rules, allowing one to add more sophisticated functionality. The ideas around this have all moved over to STT now.
One of my attempts at implementing a city simulation let to an interesting interpretted, object oriented language idea with a system of interfaces/abstract classes/traits that would allow for multiple implementations by the same base data type. I never actually implemented type checking in this language, and of course this language lost all of its appeal once I discovered the glory of simple C programs. Multiple implementations of an abstract class is a feature that exists for free in dependently typed languages, so if Object Oriented Programming had any merit at all, then this innovation on the paradigm would be quite valuable I think.
Another language idea that is aesthetically pleasing to me, but with no clear advantage to using or making, is just a referentially transparent language that isn't afraid of imperative style, but is afraid of mutation of aliased data. Essentially an interpretted/memory managed Rust type language, with no borrow checker, just pure functional programming without recursion or higher order functions. If you started to put pool-based memory management back in then you could even make something that compiles natively, or runs as the compile time of a procedural language.