4 ms·

It isn't just C++ that could do with replacing. I want the speed of C. I want the soft realtime characteristics, practical functional, highly granular GC, lig

It isn't just C++ that could do with replacing. I want the speed of C. I want the soft realtime characteristics, practical functional, highly granular GC, lightweight message passing concurrency, hot code reloading and easy parallelism traits of Erlang. I want the fault tolerance and network distribution tools of OTP. I want to have access to hard realtime performance with some additional work. I want type inference, and a static type system which stays out of your way but can approach the if-it-compiles-it's-probably-bugless ideal, yet without weighing you down where you don't need it. (When it comes to dynamic vs static typing, I'd like a slider that I can move at will.) I want immutability to be the default. I want pattern matching and code-is-data macros. I want recognition that the best part of object orientation is interfaces rather than inheritance, but with a way to provide default implementations. I want a syntax that's very readable (with a gofmt-style standard) and easy to refactor without resorting to a heavyweight IDE. Parenthetically, I am not opposed to parentheses. Its LoC counts should compete with the most expressive languages without sacrificing much readability -- if that means some readability for newbies is sacrificed, so be it, but it should read easily once you've progressed beyond the neophyte stage. Whenever we get those promised 1000 cores on a single chip, I want this language to scale beautifully onto that kind of CPU. If I can't write a hard realtime aircraft flight control system, a competitive 3D graphics engine, a complex web app, a word processor, a highly parallel distributed numeric solver, a fault tolerant telecom switch, a variety of throwaway sysadmin and text processing scripts and a selection of games across multiple platforms without feeling like this language was the most appropriate choice for all of these tasks, then it doesn't do everything I want. I haven't done much with Ada or Eiffel, or enough with Lisp or Haskell, so this list is probably too short on that basis alone. And once I have all of those things, I'll have another list.

tinco 14y ago
That's a fine list, and when said like that it might even be fun to implement and relatively easy to accomplish, but there's a bigger battle before you can write any of the software systems you mention. You need all those things _and_ interoperability with existing libraries that are written in C and C++, preferably both ways. That is a lot less fun to implement. Another thing is that implicit in the 'realtime' part of your requirement is that you don't want a runtime system, and that bugs a whole bunch of your earlier wishes. It also makes the language less interesting as many of the cool features of modern languages depend on runtimes (it's why we can't use Rust or Go!) Whoever designs the new language needs to have a lot of restraint, knowing all the fancy things modern languages have, and picking only those that can be implemented whilst satisfying the needs that those core applications have.
- Scramblejams 14y ago
  Oh, I forgot interoperability! I've grown so accustomed to connecting my Erlang programs to C++ libraries through the simplicity of ports that I erred. Thanks for adding to my list -- the more the merrier. :-) It would be interesting to make the runtime optional, to see how close together the two runtimey and runtimeless subsets could get. Or, perhaps it would be possible to mark a section of code as runtime-free. IIRC some work's been done on that but I don't think it's ever been practical.
  - ihnorton 14y ago
    Does Erlang do something special to make C++ interfacing easy? Any info/links would be appreciated - I have only found info about calling C-exported code with ports.
    - Scramblejams 14y ago
      No, not particularly. I've just settled on writing some shim C/C++ and using msgpack or protobuf over the port to do the interfacing. I prefer it because it feels the simplest to me. Obviously it could get complicated with some applications, though that would be the case with just about any other method of interfacing. Oh, and did I mention my dream language has a great REPL, compiles nearly instantly and can run interpreted, too?
  - cpeterso 14y ago
    A runtime-less subset of Rust is being considered and is being developed incrementally. Most of the Rust compiler and runtime is written in Rust itself, so the runtime may be able to be loaded dynamically. https://github.com/mozilla/rust/issues/3608 https://github.com/mozilla/rust/issues/3608
- Scramblejams 14y ago
  tinco, as with most programming language dilettantes I have a wishlist for my ultimate language, but I've never actually implemented one. Where would you suggest I start? And where should I go after that?
smosher 14y ago
I think you want what I want, which is some way to marry Scheme and Rust.

tinco 14y ago

That's a fine list, and when said like that it might even be fun to implement and relatively easy to accomplish, but there's a bigger battle before you can write any of the software systems you mention. You need all those things _and_ interoperability with existing libraries that are written in C and C++, preferably both ways. That is a lot less fun to implement. Another thing is that implicit in the 'realtime' part of your requirement is that you don't want a runtime system, and that bugs a whole bunch of your earlier wishes. It also makes the language less interesting as many of the cool features of modern languages depend on runtimes (it's why we can't use Rust or Go!) Whoever designs the new language needs to have a lot of restraint, knowing all the fancy things modern languages have, and picking only those that can be implemented whilst satisfying the needs that those core applications have.

Scramblejams 14y ago
Oh, I forgot interoperability! I've grown so accustomed to connecting my Erlang programs to C++ libraries through the simplicity of ports that I erred. Thanks for adding to my list -- the more the merrier. :-) It would be interesting to make the runtime optional, to see how close together the two runtimey and runtimeless subsets could get. Or, perhaps it would be possible to mark a section of code as runtime-free. IIRC some work's been done on that but I don't think it's ever been practical.
- ihnorton 14y ago
  Does Erlang do something special to make C++ interfacing easy? Any info/links would be appreciated - I have only found info about calling C-exported code with ports.
  - Scramblejams 14y ago
    No, not particularly. I've just settled on writing some shim C/C++ and using msgpack or protobuf over the port to do the interfacing. I prefer it because it feels the simplest to me. Obviously it could get complicated with some applications, though that would be the case with just about any other method of interfacing. Oh, and did I mention my dream language has a great REPL, compiles nearly instantly and can run interpreted, too?
- cpeterso 14y ago
  A runtime-less subset of Rust is being considered and is being developed incrementally. Most of the Rust compiler and runtime is written in Rust itself, so the runtime may be able to be loaded dynamically. https://github.com/mozilla/rust/issues/3608 https://github.com/mozilla/rust/issues/3608
Scramblejams 14y ago
tinco, as with most programming language dilettantes I have a wishlist for my ultimate language, but I've never actually implemented one. Where would you suggest I start? And where should I go after that?

smosher 14y ago

I think you want what I want, which is some way to marry Scheme and Rust.