I see this article as a battle plan. If we want to rid the world of C++ (and we as the programmers community certainly should in my opinion) it has to be done by building a language/platform that addresses the needs of the software mentioned.
Looking at the graph it amazes me Microsoft has not tried to tackle this more directly. C# and Haskell only attack the application level, why was there never an effort from them to improve the system level?
Right now the language I see as most positioned for serious work is the Mozilla Rust language. There have been a few stabs at a type-safe deterministic language- BitC and SystemC come to mind.
Loosely, you're looking for a language where you can ensure that garbage collection won't happen and that assembly can be written. Those languages aren't popular these days. Then what's needed is some level of type safety and guarantees about efficient code generation. You should be able to reason quite well about the generated code. "No Magic" is the watchword of that land.
Rust is targeting the next level up from kernels, i.e., system utilities and performant applications. It's not really intended to write kernels, but I think it can get there with some careful work. It should, IMO, do reasonably well on more powerful embedded systems based around typical OS models, e.g., the RasPI.
The question is highly controversial and (separately) not worth discussing. It's not your fault, it was more or less supplied that way by context. It works well as a rhetorical question, but some jackass is going to click "reply." Oh, wait. ;)
Instead, let's consider this: Should we try to make C++ unnecessary? I think the answer is 'yes' and I don't think it's specific to C++. For all languages × all domains, I think the time should come that there is a fitting alternative language.
Yes, C is 70's technology. That C++ is based off C is one of the reasons it is so bad. Problems range from compilation times to weird syntax choices to the complete lack of higher level constructs which C++ only barely makes up for.
I fully agree it is quite easy and maybe even too easy to write crappy Haskell but that is completely beside the point. I don't shit on C++ because that is a hip thing to do, whatever that means. C++ is still used in some fields, and obviously C# and Haskell (and by extension all modern languages) suck for those fields.
I think C++ was a bad idea from the start, because it attempts to be a strict superset of C, which is like trying to win a race while being tied to the current front runner. It might have allowed C++ to use the rope to get in front, but now its in front it just drags the language down.
I am trying to invent a good alternative, but obviously that is easier said than done. I like to talk about it openly and provocatively so others who are more qualified to do it might jump in and try too.
> But for some types of software there is not a good alternative.
This is exactly it. As much as many people dislike C++, not having it at all would be very bad for some areas. Users of the next major systems language should regard C++ in much the same way as (willing) users of C++ regard C.
The takeaway here should be about how much better the future can be, not how bad the present looks. The former is hopefully much less controversial than the latter.
I think it's a bit disingenuous to write that Linux uses C++. Clearly, the kernel is in C, and nothing else. There is no C++ runtime support in the kernel.
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.
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.
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.
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.
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?
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?
The first part is always making the list of features you want to have, these are the ones you value most and don't want to compromise on. You should write them down maybe hang them on your wall to remind yourself. Go through the list and try to find out if no features conflict with each other. That a language exists that has both features is usually a good sign.
After that comes designing a grammar. How do you want to express the features? This is a fun part. I start by selecting a small program I think should be easy to implement in my language, for example a coffee machine, a small web application, a mathematical algorithm (like fibonacci). Find some you think should be written in your language, and then just do it. Be very careful in that everything you want to express is actually expressed in an unambiguous way.
Depending on what features your language has this can be very hard, Ruby for example can only be parsed and lexed at the same time so it requires much hand tweaking.
Depending on the particulars of the language it doesn't really matter in which language the compiler is written, pick one as highlevel as you can. Compilation speed is only important once you have a reference implementation.
I recommend that as a target language you pick a language that is as close to your desired feature set as possible without conflicting with any of your features. A conflict here means either a lot of work to implement, or incurring a too big performance loss. Pick a low level one like LLVM or CLR bytecode if you need good performance.
And then you're done. Now you have a reference implementation you can focus on making it run fast (by selecting a lower level target language / implementing optimizations) and on making a standard library.
Yeah amazing they finally managed to ship it. XE3 came out last September, and had essentially nothing new over XE2. They had to pull C++ support because it was so buggy. Anyone who has been a C++ Builder customer will no doubt be excited, finally a 64 bit RAD Studio C++ compiler they can migrate to. Last big update C++ Builder customers got was (woo) unicode support quite a few years ago.