I was doing the "Implement a language with llvm" tutorial [1] last night. LLVM really is awesome... Why do we even make new languages for the JVM (apart from access to JVM libraries). LLVM seems so much more powerful as a basis.
I don't really know how long LLVM has been mature yet, so maybe it's not used because it's rather new. And of course it's way more low level than the JVM. It's probably easier to go JVM and not implement your own garbage collector.
Still, this could be the "portable platform" of the near future.
Well, libraries are probably the largest reason, as providing access to native libraries is much harder (if possible at all) on LLVM due to the lack of reflection in C or C++.
Aside from libraries, other reasons for it being unpopular include JIT compilation being slow for LLVM (compared to hand rolled implementations) lack of a mature GC infrastructure (for decent performance, iirc you are best off rolling your own with little/no help from LLVM) and general difficulties with the performance of compiled code for dynamic languages (many of its optimizations, e.g. LICM, TBAA, etc are unsuitable for dynamic languages. Other optimizations get tripped up by type guards, and cant do much useful work). Not to mention that LLVM is huge, and it can be a painful dependancy (especially given the above)
Another problem for LLVM as a portable platform is that LLVM bytecode is, well, not portable. I mean, how could it be? It must be able to encode the semantics of C, which is inherently non-portable (especially after e.g. sizeof has been replaced with machine dependant sizes).
That's not to say LLVM is not awsome, because it is--very much so. But LLVM's design goals have never included being a platform, as thats likely at odds with it being a great compiler for languages like C/C++. (Maybe not, but it certainly seems that way to me)
Edit: just realized you said apart from libraries. Rephrased some stuff to highlight other points
"LLVM’s intermediate representation provides garbage collection intrinsics that offer support for a broad class of collector models.
[...] We hope that the primitive support built into the LLVM IR is sufficient to support a broad class of garbage collected languages including Scheme, ML, Java, C#, Perl, Python, Lua, Ruby, other scripting languages, and more.
However, LLVM does not itself provide a garbage collector — this should be part of your language’s runtime library. LLVM provides a framework for compile time code generation plugins. The role of these plugins is to generate code and data structures which conforms to the binary interface specified by the runtime library. This is similar to the relationship between LLVM and DWARF debugging info, for example. The difference primarily lies in the lack of an established standard in the domain of garbage collection — thus the plugins.
[...]
On the plus side, this means that you should be able to integrate LLVM with an existing runtime. On the other hand, it leaves a lot of work for the developer of a novel language. However, it’s easy to get started quickly and scale up to a more sophisticated implementation as your compiler matures."
G++ still doesn't support all of the C++11 standard library so that is not entirely true. (Clang's standard library implementation, libc++, is C++11 feature complete as well)
Perhaps, but I don't see the need for the gcc did it first responses. A simple gcc and clang both have ful c11 support now would seem more appropriate is basically all I'm trying to convey.
This is totally a competition, although the bar is probably pretty low.
If Clang is feature complete, compiler and library, and GCC takes ~N years more to be feature complete, compiler and library, then Clang could win. People might say, "I'm tired of not being able to use feature X, it's been implemented in Clang for two years", drop GCC, and install Clang.
So far they only implemented "binary literals" which is based on a GCC extension that they were supporting already. But good to see that the compiler vendors are going forward. GCC already supports "Return type deduction for normal functions".
To add to that -- Visual Studio still has woeful support for C99. I keep hoping that when (if?) they get full C++11 support, the C11 support will just fall out of that. Pipe dream, I know...
I'm aware of that, which is why I was hoping C11 would just fall out of the C++11 implementation. The people working on the C++11/C11 standards did so specifically to bring the languages closer together.
If you fully implement C++11, then C11 comes along for relatively little cost.
I keep hoping that Microsoft will wake up and realise that just as HTML5 was important, so is language support for the lingua-franca of the computing world.
One issue might be manpower ... My impression has been that MS's compiler team is woefully understaffed / overworked given the relatively influential position of their products.
Not disputing understaffed possibly being true, and not arguing with you guys, but it's a poor excuse for Microsoft being one of the richest, most powerful companies in the world, while willing and continuing to lose billions on things like Bing, Xbox (it's true, they still haven't broken even if you count all they spent plus the red-ring-of-death write-offs), Zune, and now their mobile initiatives.
And what was Microsoft doing in those 12 years between C99 and C11? What are they doing so inefficiently in their design that they can't figure out how to implement C when every other C++ compiler team has? Come on, Clang didn't even exist until 6 years ago.
Stupid positions Microsoft takes like this with regards to C99 and C11 only underscore how pathetic, short sighted, and clueless they have been for over a decade. They have needlessly alienated developers they profess they need so much for so little reason. How ironic that now they are begging developers to do Windows RT and are promoting "going native".
How ironic that now they are ... promoting "going native"
Actually for me this is a sign that they are finally starting to Get It. I agree with your sentiments on the last decade but it seems to be improving now.
C++11 (and C++03) do not include lots of C99 features. For example, C++03/11 do not contain variable length arrays (one of the C99 features people often want).
I hear your pain. I'm trying to roll my pet project with C only (it suits me better, since I'm not a full time programmer). I'm using clang on OSX and gcc on linux and mingw on Windows (all x64, of course). There is something that bothers me though. I feel like I have made a grave mistake. Everything I look up that I need for my project there exists a suitable library for C++, but not for C. This surprised me. Maybe I don't know my way around libraries for C, but it seems like I have to reinvent wheel (badly so) if I want to stay with C. So now I'm thinking if I should just let go of C and do C with classes, which bothers me tremendously.
Heh, I'm familiar with that problem. I write in both C and C++ regularly, and be assured, the one I'm not using always seems better (maybe Google is just trolling me by showing me the results for the wrong language). I can only find C libraries or tools when I search for C++ libraries, and vice versa.
If you're doing low level work (e.g. the layout of your objects is a concern to you), stick with C. C++ often gets in the way there and you won't be able to write idiomatic C++. If it's midlevel you're better off with C++. If it's high level, neither of these are a good fit, and you're better off looking elsewhere.
It would be nice if we had a central repository for C libraries, like old CPAN. I know they can't be universal, but repo could be. Github is sometimes nice to browse aroynd, but not really that great with discovering/searching stuff.
The November CTP is a one-time experimental release. Subsequent formal VC++ updates don't include what it has. So for all practical purposes it might as well not exist.
I find Clang to be outdated in most Linux distributions. Asking developers here, are you compiling your own clang/libc++ to benefit from the continuous stream of improvements ?
You can download stable releases from http://llvm.org/releases/ - it has binaries for some common platforms. A stable release is made once in 6 months on average.
But to be on bleeding edge, yes, you update from SVN. It isn't hard, but you better have a beefy machine to build&link all of it in reasonable time. This page summarizes it nicely: http://clang.llvm.org/get_started.html
I don't really know how long LLVM has been mature yet, so maybe it's not used because it's rather new. And of course it's way more low level than the JVM. It's probably easier to go JVM and not implement your own garbage collector.
Still, this could be the "portable platform" of the near future.
[1] http://llvm.org/docs/tutorial/index.html#kaleidoscope-implem...