Slashdot Mirror

No, there is an earlier "credible attempt to displace C++": D. D was created by Walter Bright, who previously was "the main developer of the first C++ compiler to translate source code directly to object code without using C as an intermediate language" (quoting Wikipedia), and so is clearly "credible" by your criteria.

The thing about Rust is that the ownership/borrowing system makes it better than C++ in important ways. Programmers have to specify variable usage details, but this (1) makes the code easier to maintain, (2) gives you a much more powerful form of RAII, (3) makes reference counting work so well that you don't need a tracing garbage collecter, and (4) makes the resulting code significantly faster in many cases. That is why Rust should compete successfully with C++, whereas a "C++ without the warts" like D could not.

Typically different languages are engineered towards different purposes
High level languages are good for quick scripts or GUI Applications
Low level languages are good for speed, drivers, getting as close to the bare metal as possible.

That being said It is possible to get both the benifits of a low level language and checking of code by the compiler at the same time.
C / C++ was designed a long time ago, long before the internet and before a lot of tools, methodologies and ideas which are now available.
The problem is making changes to it now isn't a possibility simply because of old cruft / backwards compatibility.
I know quite a few here have suggested Rust, although my favourite is DLang - https://dlang.org/ since it more closely resembles C / C++
They seem to have solved a lot of problems recently associated with the runtime, in that you can now more easily replace it with your own implementation.

Here's a better idea, why not try D / DLang instead?
https://dlang.org/
Any valid C or C++ can be used with D

Rust could potentially replace C, but not C++
It's important to note that Rust does not have Object Orientation, it's more of a pragmatically functional language
It separates data storage and functions into separate grouped objects
but lacks features such as inheritance.

D has inbuilt garbage collection, which can be disabled but is on by default
I think one of the issues in the past has been the disabling of garbage collection with it's standard library, since it assumes garbage collection is enabled for that part.
Although I heard they were working on fixing that, I'm not sure how far they got with it so far

I agree! "C" is a letter, not a name for a computer language. Yuck.

Worse!!! C++ is a name spelled with a math symbol.

Then there is the D language.

While Go and Swift are interesting incremental improvements, they are not taking into account what we learned about programming languages. In many ways, these two languages seem firmly stuck in the 1980s. For example, Go has no generics, and as far as I can tell, Swift still does not have the kind of true generic types I introduced in XL in 2000, i.e. the possibility to call "ordered" all types that have a less than, and then define functions with "ordered" instead of having to use <T> all over the place just like in C++ (and please, could we stop using angle brackets?)

More generally, there was a lot to be learned from more dynamic languages deriving from Lisp. Being able to treat code as data (homoiconicity) completely changes things. It means your language can be extended in itself, just like Lisp integrated object-oriented capabilities effortlessly. It means you can do metaprogramming, introspection, reflection, dynamic code generation, in a natural way rather than with specialised ad-hoc features. All things that Go or Swift spectacularly fail to do.

A real language redesign does not bring you incremental benefits, it should bring orders of magnitude on many tasks. I speak from experience. In XL, I can do complex arithmetic in 11 lines of code. What about Swift or Go? Ask yourself why Go can't offer complex arithmetic as a library package? Similarly, in Tao3D, I can do things HTML5 just can't, in a much less verbose, much higher-level language, and simple animations take 30 times less code than in JavaScript. The 30x factor tells me that I invented something new. Many others can demonstrate similar innovation.

I fail to see benefits of a similar order of magnitude with Swift or Go, and it annoys me. Companies like Apple and Google have the means, if only the financial ones, to make bigger things happen, in particular when smaller teams like ours already did a lot of investigative work.

IMO it's much cleaner to consider code as a series of transforms of varying kinds than a grab bag of tools.

I agree entirely - functional approaches tend to result in much more elegant code, where suitable.

I like Coffeescript's switch [coffeescript.org], but that's partly because I like having every construct being an expression, removing an element of the code/data divide.

That looks very similar to Rust's match construct, which is basically the same thing but with C-style syntax. Another useful feature I've seen (that would be incompatible with Python's preference for duck typing) is D's final switch, which ensures that cases exist for all members of an enum.

Both Objective-C and C++ have object oriented concepts graphed on as an after-thought.

Your best bet for a classic compiled object language is either SmartEiffel or EiffelStudio.

If you are going to demand using a C-like language then your best bet is D.

For example: #ifdef UNTESTED_FEATURE

D supports conditional compilation. And has features to accomplish any other sane use of the preprocessor, but in a cleaner way as first class language constructs.

Because the preprocessor "creates" the C-code, you can do *everything* with it.

Yeah, but should you? That's basically writing code in a feature-poor unstructured string manipulation meta-language.

3. C++ isn't an interpreted language; of course it won't have much reflection.

While reflection is much easier to implement in interpreted languages, there are compiled languages that support it. e.g. D

Jeezus fuck. Its bad enough that we get Dicevertisments, but Diceverticements with Campaign ID's on them?

Anyway this is the direct link to the D Language

And of course this "D" language is not to be confused with the other "D" language, which is Turing complete.

Java handles unicode much better than does C++. It also handles strings better. And synchronization between threads.

N.B.: You *can* do all those things in C++, or even in C, but they're much nicer in Java.

OTOH, I despise the UTF-16 coding used by Java. Enough so that I generally prefer Python or Ruby. though if I don't need specialized libraries my real choice is D (Digital Mars D). See http://dlang.org/index.html .

This, however, doesn't mean that I think Java, Python, Ruby, or D are appropriate languages to write an OS in. For I deem that the best choices are C or Ada. You *could* do it in D, but you'd need to disable many of it's more desireable features for much of the code. (There are times when you really don't want garbage collection or the layers of indirection that make objects flexible. In D that means you don't use classes, but you can use structs.)

You are what is called a "C++ apologist". You are comparing C++ to nothing except itself and abstract complexity (and offhandedly VisualBasic), instead of actually coming to terms with the real problems of C++.

Let me offer you a few pieces of evidence of C++'s failures.
* C++ has a text preprocessor. A solution to engineering constraints of fucking 1970. No one has or will ever do that since 1975. Everything is and should be resolved symbolically.
* C++ is meant to be able to compile C code with no to minimal changes. This really makes
* D. Read http://dlang.org/cpptod.html which is a description of how another systems-level language dealt with perceived drawbacks of C++. I don't think D is perfect by any means, but there are many thoughtful improvements to C++.
* Read http://yosefk.com/c++fqa/defec... for a bunch of valid complaints about C++ (granted, many of those can be argued).

Not to be a fanboy, but: a lot of this stuff makes me think "Ah yes, that's why we have D".

We dream of cleaning up the mess

Yep. D is pleasantly free of the mess.

a direct mapping to hardware plus zero-overhead abstraction

Here, D and C++ differ somewhat. D isn't totally unusable without its trusty garbage-collector, but it's not something that's often done.

Being a fan of range/container algorithms

Andrei Alexandrescu agrees. See also these.

Ranges are a standard thing in D.

I think we should think more about isolating unsafe code in a program than to eliminate it. Putting the necessary unsafe code into a different language limits our control of it, limits what can be communicated to it, and typically imposes overheads.

Precisely why D has a safe subset and the @safe and @trusted attributes.

Of course, D doesn't have compatibility with old C++ code, or even with old D code (that's why there's the ancient-but-stable D 1.0 language).

That is a more restricted definition. You need a stricter definition to safely elide code.

Apparently the D compiler does perform further analysis to see if that stricter definition is met. See here. It seems to check if the function can modify it's arguments (for example, by zeroing them).

GCC is giving memset special treatment, right? If GCC didn't know whether memset would side-effect, it wouldn't elide the call. One could presumably work-around this problem by creating a static library defining memset_secure, which just called memset. When calling memset_secure, GCC wouldn't know whether it side-effects, and so wouldn't elide the call.

(Unless you're allowing link-time optimisation. You'd have to be sure your memset_secure static-library was a real machine-code static library.)

Aside: in the D programming language, it is possible to express 'purity' of a function, and so enable this kind of function elision for arbitrary functions.

Well, I'm totally developer, and I *don't* like Ruby. Partially because it's too slow, but mainly because it doesn't support utf-8 (or actually any unicode) well. That needs a gem. I really like Vala even though I find it unusable. (Poor documentation and incomprehensible error messages.) It seems to be aimed only at people who are already experienced in GObject programming...which is a weird target audience for that kind of language.

I *don't* like Java, though that's what I'm using at the moment. I prefer Python and D http://dlang.org/index.html . But Python doesn't handle multi-processing well, and D is missing too many libraries. (Outside of the library problem, D is the best language I've encountered.)

My main gripe with C and C++ is the horrible way that they handle Unicode. And it's not as if they didn't have alternatives available before they even started to deal with it. (C has the argument of "maintaining simplicity" to justify shoving that off to a non-standard library, and glibc does a reasonable job. C++ doesn't have that argument.)

A secondary grip with C/C++ is poor multi-processing. This isn't quite fair, though, because I'd already decided that they were unusable due to the unicode handling issue. (I also don't like Java's choice of utf-16. I much prefer either utf-8 or utf-32. utf-16 seems to inherit the problems of both of the other choices.) Since I'd already decided that they weren't acceptable choices I didn't seriously look into their methods of multi-processing.

Note that for BOTH unicode handling and multi-processing I would prefer D over any other choice I've seen. But the lack of libraries counts as a heavy enough strike against it that I'm using Java..

FWIW, I suspect that both the Dev and the Op sides of you would like D. (Digital Mars D)

You could give D a look. ( http://dlang.org/index.html ). To me it seems like one of the best languages that compile "to the metal". It's problem is the perennial one of new languages: Not enough libraries. Of course, you can link against any library with a C calling convention (and I think those with a C++ calling convention), but there are problems with data structure translation. Even strings require special handling. And it doesn't recognize C/C++ macros, so all the header files need to be translated...which is a bit of a difficult problem, and currently each case needs to be handled manually. Etc.

It's enough of a problem that I'm not doing my current project in D. But I still wish I could.

That is true, but C++ does it in a way that makes programming dangerous.

That's why the D language was developed. It's something like C++, but done correctly with a clean sheet of paper. You can even understand the syntax! C++ programmers can easily learn it.

The question is whether D will ever catch on. It's not, or at least doesn't have the image, of a cool new language. The only chances I see for its success are 1) it'll be used on a lot of FOSS projects, so eventually enough people will want to darg it into their day jobs, and/or 2) some well known company starts using it internally. I'm not a big Facebook fan, but it would be a likely candidate, as Andrei Alexandrescu (C++ author and #2 guy on D) works there.

P.S. I also like Ada. At one time you had to be careful admitting that, but it's ok now because not many people know what you're talking about. It's dying though, and has been for many years. It's probably already a common topic at the Old Programmer's Home. D has a chance in part because it's newer (and more up-to-date).

D does!. But D also has so many neat features.

D is wonderful, and it can interop with C / C++ or write inline ASM for you micro-optimists out there.

D does!. But D also has so many neat features.

D is wonderful, and it can interop with C / C++ or write inline ASM for you micro-optimists out there.

D does!. But D also has so many neat features.

D is wonderful, and it can interop with C / C++ or write inline ASM for you micro-optimists out there.

D does!. But D also has so many neat features.

D is wonderful, and it can interop with C / C++ or write inline ASM for you micro-optimists out there.

D does!. But D also has so many neat features.

D is wonderful, and it can interop with C / C++ or write inline ASM for you micro-optimists out there.

What would be a safer low-level systems language than C? I'd love to see one, preferably, one with a LOT less undefined behavior, but still within 2-3x the performance of C, and with the ability to call C or C++ libraries when necessary. I'm not looking for a fully managed environment like Java or .NET, or a higher level language like Python or Ruby. Definitely *not* looking for C++ either . . . I know one can write safer code in it but one can also, quite by accident, write very unsafe code in it as well. Maybe something like D?

You definitely know a lot about D.

You're too generous - I've just read a bit about it and played about with it a little; I'm certainly no D master :P

Regarding frameworks/libraries/maturity/practical power, I think you might underestimate what Mono is capable of - I'm no expert, but I don't think you'll have any trouble doing web-dev work with it.

For D, I believe there are libraries out there for doing web-dev work. This one might do, but looks a bit on the low-level side. For serious production code I'd certainly recommend C# over D (ASP.NET is already out there in the 'real world'), but I'm sure it could be done with D.

Hm, should check how D is in the area of multi threading.

I don't know much about this, but I do know that D2 has some thread-safety features built into the language itself: 'global' variables are now by default actually merely 'thread-global'. You have to use a special keyword if you want real process-wide globals. I can see where they're coming from, but I'm not sure I like it.

But bottom line I don't like many of the design decisions in D

There are certainly seem to be some warts - I get the impression the const system is a bit broken.

like having no true MI

I've never been bitten by not having MI, but maybe that's because I learnt Java before I learnt C++. The arguments for not having MI are fairly persuasive imo: simpler for the compiler, generally less error-prone for the user, and MI is rarely the right solution anyway.

I never quite got my head around Scala's solution (it looked a lot like MI to me), but people seem to like it.

(with language versus platform I mean the broad spectrum of libraries that are focused on special purposes in Java, like JPA or the Java Rest and Soap support via annotations etc. the huge amount of third party frameworks like spring or Aspect/J or hibernate)

Ah, the advantages of bytecode and reflection. Sounds almost like Aspect Oriented Programming is what you're really getting at here. There's not much in the way of AOP for D, from what Google tells me.

For your part h), see also SBT, the Simple Build Tool for Scala, with operators
Items I think you're missing:
i) REPL for rapid exploration of language features.
j) If the language is compiled, fast compilation times. This to me is a massive reason to prefer Go and D to C++ when you're building something that has to be near C++ for speed but does not need to hook deeply into existing C++ code.

I also disagree on your need for strong static typing. Let's say you have some kind of object with functions doX and doY and some functions that manipulate those objects. Then you interface with a third party library that happens to have objects that also have doX and doY you should be able to use interchangeably with your functions and objects. In the world of Java and C#, you need to make a common interface and recompile the whole set, including the third party library, to get that to work. With Scala, you can work around it by using implicit conversions but it's still an added layer of complexity. In Python, Ruby, Perl, PHP, or Clojure, it just works. Sure you can screw up and have type errors - but you're three days into writing your unit tests when the Java/C#/C++/Scala guy is still defining his damn interfaces.

People who wrote code which smoothly made the transition from 32-bit to 64-bit w/o requiring a rewrite yet was still able to take advantage of increased width don't think it was a waste. Or whose portable code can work on a desktop machine with 8-bit bytes, or on embedded DSPs with 16-bit bytes....

What exactly do you mean by take advantage?

Do you just mean that, in well-written C, an increase in bus width is only ever a good thing, and at the same time it enables efficient DSP code?

In, say, Java, moving to 64 bit will have no effect on program semantics because of the fixed-sized primitives (i.e. unlike C, it just about guarantees you won't see any new bugs from the transition), but might enable one to take advantage of a larger heap.

There's also the non-trivial matter of

People who wrote code which...

which certainly isn't all C programmers. Reflects C's unusually pro-performance design, I guess. Interestingly it looks like the D programming language has no support for C-style CPU-dependent primitives, only fixed-sized.

You'll probably laugh, and it does need some polish and more effort, but what about D?

That being said, while it lacks a lot of conveniences, C certainly isn't a bad language, just not the easiest to learn and write in.

D isn't all sunshine and rainbows either. I think deadalnix summarizes some of the problems nicely in this http://forum.dlang.org/thread/kaqbkp$1kqj$1@digitalmars.com?page=2 discussion.

So true. It's a dysfunctional love/hate relationship I have with the C++ standard. And just like most abusive relationships, I refuse to leave her. :)

I wish D would gain some momentum.

That's half the story. The other is that most pages are dynamically generated, slowly. There was a comment thread a couple of weeks about the blindingly fast D forums. Note that they are fast because the server is generating the pages very quickly.

The D programming language people have successfully combined a mailing list and tradition web forum into one. What's more, the web forum is lightning fast to boot (fastest ever forum I've ever used - why can't phpBB etc. be that fast?).

The exact specifics are unknown to me, but from what I've heard, they've done a terrific job:
http://forum.dlang.org/

All of the downsides of C++ are fixable with a from-scratch language with the exact same feature set, but no legacy syntax.

Give a look at D programming language. Basically its goals are what you described. (has nicer syntax then c++, makes some stuff a bit easier, but still allows to get ' performance and "to-the-metal" ' if needed)

Couple of links:
Home Page
Wikipedia Entry