Hacker News new | comments | show | ask | jobs | submit login
Multi-Device C++ is used everywhere on planet Earth and beyond (embarcadero.com)
30 points by T-zex 1786 days ago | hide | past | web | favorite | 34 comments



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 get that there are userland applications in C++, but coreutils and all the GNU apps traditionally used in Linux distros are in C. And if you're counting userland apps, then you might as well say that Python and even JavaScript are the language of Linux, particularly since their use is growing more and more in most distros. Clearly, no one would make such a claim, so why for C++.


I think it's a bit disingenuous to write that Linux uses C++.

I like the civility in this sentence, yet I'm inclined to say that it's more than just "a bit disingenuous." Is there anybody who has not read this post by Linus Thorvalds on C++:

http://harmful.cat-v.org/software/c++/linus


gcc just switched to C++, clang always has been.

While this isn't "linux" per se, it's also kinda hard to do anything useful on a GNU/Linux system at this point without a working C++ compiler.


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.


Why should all programmers try to get rid of C++? IMHO as the programming community should try to enhance the craft. To write better code irregardless of language(including C++).


No I don't think that is how it works. Programmers enhance the craft by applying technologies (like C++) and finding their weak spots and correcting those with new tools.

Enhancing your own craft has a ceiling (that of the technology), advancing technology has none.


I'm being pragmatic. One of the goals of the Go language is to be an alternative for C++. It has ended up an alternative to scripting languages and failing to attract the programmers who use C++ the most. http://commandcenter.blogspot.se/2012/06/less-is-exponential...

So my question is the same: Why programmers should try to eradicate C++?


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.


MS put in an effort to improve the system level with their Singularity project (http://en.wikipedia.org/wiki/Singularity_%28operating_system...).

I personally love C/C++, write my guile scripts in vim, and see no reason to replace it.


Would you mind explaining why do you think we should get rid of C++? Do you have the same opinion regarding C (since you talked about the system level)?


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.


> rid the world of C++

Why? If you don't like it don't use it. There are enough people who are happy with C++ because it perfectly fits their domain.


Invent a good alternative then. There are reasons why you don't run Haskell in a fighter jet.

And you can certainly write crappy Haskell too. It is hip to shit on C++, I get it. But for some types of software there is not a good alternative.


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.


It is by no means perfect. But I think some parts of C++ is quite clever too. Templates might allow horrible code, but every time you write a container type in C or Go, you wish you had them.


> 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.


Sorry... Fat finger trade - I accidentally downvoted you instead of up (not sure how to revert it)

Pity the down vote isn't on the far right of the heading.


You can't revert it, I have remedied the situation by giving the grandparent an upvote. It was a deserving comment anyway.


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.


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.

https://github.com/mozilla/rust/issues/3608


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.


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.

When you think you got the idea of your language down, now you write it down formally. This is where it gets a little complex so I'm not going to fully explain it (you can mail me when you're at that point @tinco.nl) but the basic idea is that you learn EBNF, and pick a lexer/parser generator (there's multiple in every language, even javascript).

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.

Then a rather difficult step, the code generator. It takes your AST and turns it into executable code. For CoffeeScript this means turning it into Javascript. For C# it means turning it into CLR bytecode, for C it means turning it into x86 machine code.

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.


Thanks for the guidance. If you ever do a release of your own handiwork, please let me know. Email's in my profile.


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


AAA high quality video game engines are always writern in C/C++

Video games are one of the domains where C++ will always tend to be THE standard choice, indispensible when creating engines.


This is just an advert for C++ Builder XE3. There is nothing in this article that a C++ programmer does not already know.


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.


"YOU are full of bullshit." (quote from Linus)

I'm pretty sure the Linux kernel uses C.

http://thread.gmane.org/gmane.comp.version-control.git/57643...

--------


Read this: http://miek.nl/downloads/2010/c++-talk.pdf?we-require-more-d...

Then read the article again. C++ terrifies me.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: