The Next Big Programming Language You’ve Never Heard Of

http://www.wired.com/2014/07/d-programming-language/?mbid=social_fb

by rohunati • 12 years ago

63 73 12 years ago

wired.com

Artemis2• 12 years ago

Sorry Wired, but you don't build up hype for a language like that.

donpdonp• 12 years ago

spoiler: the language is D. http://dlang.org/

signa11• 12 years ago

not sure if D is a stranger in these parts.

gerbal• 12 years ago

But can it compile to Javascript?

dkarapetyan2• 12 years ago

It's got an LLVM backend so yes. Probably not production ready.

astrodust• 12 years ago

What can't?

jarrett2• 12 years ago

True--in principle any language can be executed in the JS runtime. A lot of them can even be executed reasonably quickly. Though I suppose the parent comment was asking whether a mature compiler from D to JS currently exists.

Zelphyr• 12 years ago

More importantly, does it contain an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp? If not then I really don't see it having a future.

_random_• 12 years ago

Yes, any good language can be obfuscated by converting to JS.

andralex2• 12 years ago

Wierdest thing it's it can: http://goo.gl/88eFzs

tdees402• 12 years ago

D? It's been around for a fairly long time, and it doesn't really have much momentum. I'm not sure why it's "the next big programming language".

srean4• 12 years ago

Right! momentum is the most technically relevant quality of merit. Lets have a wholesome and fulfilling discussion of that aspect in particular. If that fails, lets discuss semicolons, and braces and make this HN story very meaningful and informative. After all that is the kind of discussion I come here for. If an article is crappy lets make the discussion around it crappier still. Shudder at the thought that a discussion could be stimulating even if based on an article less than stellar. Low and middle brow, here we come.

Ha! you are fun, searching through my comment history and downvoting old comments still downvotable. Whatever floats your boat.

JacksonGariety• 12 years ago

But the title doesn't say "of merit" it just says "big."

danmaz74• 12 years ago

Unfortunately, technical merit doesn't make anything "the next big thing". High momentum for a prolonged period of time does.

nitid_name• 12 years ago

I imagine a language needs a certain rate of adoption to maintain the amount of programmers actively coding in that language. I feel like the term "momentum" accurately encompasses this idea.

Lets talk about Justin Bieber!

I don't understand why you invoked the name of a Canadian popstar. There is no chance of such a comment adding to the discussion.

cwyers• 12 years ago

Momentum means that things like tooling, libraries, documentation and frameworks are being built. Even if D is 'technically' better (whatever that means) than Go or Rust or whatever other language you want to compare it to, a language doesn't exist on its own, but inside a larger ecosystem. And the number of people using/contributing to/being employed to work on Go/Rust/Java/C#/Python/Ruby/etc. means that the D language's benefits over those other languages may not be enough to overcome the ecosystem advantages that come from "momentum."

But yes, instead of acknowledging that there's a valid point there, let's just accuse everyone who lives in the real world where you actually have to USE a language, not just admire its technical merits, of being low and middle brow.

tdees402• 12 years ago

I'll bite: a relevant technical question would be: is D really that much better than C++11 that you should abandon C++ (with all of the consequences that would have on tooling/libraries/etc.)?

I think D made more sense pre-C++11.

jordan0day• 12 years ago

Perhaps that's why wired presumes you've never heard of it?

soundoflight• 12 years ago

I think Wired presumes you have not heard of it because they assume the reader is not a programmer.

jarrett2• 12 years ago

Apparently it's being used at Facebook. If they actively injected life into the D ecosystem to the same extent Google does with Go, the momentum might pick up substantially. Look at how late Go arrived--it was announced in 2009--and how popular it already is. Now, that doesn't mean Go or D can necessarily become the next big thing, i.e. the C++/Java killer. But even if they got as far as Python or Ruby, that would be a significant change to the programming landscape.

TazeTSchnitzel• 12 years ago

If Facebook did for D what HHVM is for PHP, maybe people would use it.

They haven't.

joe_the_user• 12 years ago

Well,

AS C++ competitor, it seems logical that D would require more time to mature than a scripting language and even now-successful languages like Python have taken a long period before they gained traction and then popularity.

And Facebook is using it, that seems to imply some reasonable momentum.

noir_lord2• 12 years ago

Has anyone at wired these days actually seen a computer?

If they have they should really show it to their journalists.

drcode• 12 years ago

Certainly! Here is video proof: https://www.youtube.com/watch?v=-2ZkJd4u0Us&feature=kp

noir_lord2• 12 years ago

That is perfect!

jbrooksuk• 12 years ago

Is this because Facebook uses it? D has been round for longer than they seem to be making out.

dkarapetyan2• 12 years ago

Andrei is looking pretty fit these days. Being a research scientist at Facebook is good for your health it looks like.

x43b• 12 years ago

Previous discussion with 14 comments from 6 hours ago https://news.ycombinator.com/item?id=7998144

rossjudson• 12 years ago

The phrase "C++ is an extremely fast language -- meaning software built with it runs at high speed" needs to be changed to "It's possible to build high speed software with C++".

I take any performance claims made by a particular language with a pretty big grain of salt (particularly those made vs Java/JVM) unless they're accompanied by some reasonably sophisticated benchmarks and source that actually show a performance difference -- not just one that low-level language enthusiasts presume exists.

philosophus• 12 years ago

Well, I think you could be a bit more specific than that and reasonably say something like "If speed is a high priority for you, then C++ is often a good choice." That's why PC games are generally written in C++.

YZF7• 12 years ago

Here's one: https://days2011.scala-lang.org/sites/days2011/files/ws3-1-H...

And yes, languages are not slow or fast. The JVM could be as fast or even faster than native (AOT) because JIT can in theory optimize better than AOT. There are fixes planned for performance issues. Things have improved since the benchmark. It's only one particular benchmark. One specific implementation of VM/compilers/etc. Let me show you some badly written code in language X that runs slower than language Y on machine Z.

In my opinion JIT is always going to be slower than native (AOT). Maybe the gap will close but fundamentally you can do anything a JIT does AOT at zero run-time cost but not the other way around. That's not a language thing, C++ targetted at a JIT environment (and I think you can target .NET for example) will also run slower and languages that are JITted today could possibly be AOT.

The other thing is that if a specific language doesn't allow fine control over memory layouts and data types at the native level and/or if there are inherent costs in the language's design (e.g. duck typing) that is also something that will ultimately prevent it from running as fast as languages that do. That's because you can always build higher abstractions from primitive ones but you can rarely build a primitive one from a higher one. Very smart compilers may be able to identify a "primitive use case" and optimize for that but in general that's a much harder problem.

brimstedt• 12 years ago

Is there any language/environment that tries to combine the two? I.e JIT for a few iterations and then "settling" on the best optimization and caching it?

pron4• 12 years ago

Maybe the gap will close but fundamentally you can do anything a JIT does AOT at zero run-time cost but not the other way around.

You can't inline virtual functions, which is the number 1 optimization done by the JVM (as it enables most other advanced optimizations). You can try achieving it with a profile-guided optimizing compiler, but a JIT can adapt its optimizations based on changes in the inputs (which trigger different code paths at different times in the program's lifetime). Also, the JVM inlines virtual calls even for code loaded at runtime.

The other thing is that if a specific language doesn't allow fine control over memory layouts and data types at the native level...

True. Java 8 already takes steps in that direction with the @Contended annotation (that adds padding to prevent false-sharing), and Java 9 will let you have much more precise control over layout with value types.

On modern multi-processors, performance is also determined by your ability to use scalable (usually lock-free) concurrent data structures, and those are a lot easier to implement and use when you have a good GC.

tormeh2• 12 years ago

Well, a JIT-compiled program can be substantially faster than an AOT-compiled one, given that running time is large enough. Which it is for services on 24/7 (that's more throughput, but you get my drift)

twic2• 12 years ago

fundamentally you can do anything a JIT does AOT

False. Amongst the things that JITs can do that AOTs cannot are optimisation based on profiling of the program executing with its actual inputs, interprocedural optimisation of dynamically linked code, interprocedural optimisation of code generated at runtime, and runtime specialisation [1].

I'm not sure there's a bright line between runtime profile-guided optimisation and runtime specialisation; however, i think most of the optimisation that production JITs do today is more reasonably classed as the former, rather than the latter. However, the other three are all happening right now in JVMs around the world.

[1] http://en.wikipedia.org/wiki/Run-time_algorithm_specialisati...

gcv2• 12 years ago

I hear that argument a lot, and yet I have never seen real-life software that runs comparably in Java and C++. For example, a few weeks ago, I was looking at some (fairly simple) data processing code backed by SQLite. The Java version was too slow for the amount of data that needed to get analyzed and reanalyzed repeatedly. A rewrite in C++, with no special trickery, ran 3x faster.

After isolating everything in Java (including ditching the JDBC driver for lower-level SQLite bindings), nothing changed. It was likely JNI overhead, but frankly, that doesn't matter: Java was too slow. No sophisticated benchmarks here — just real-life production code that runs like molasses in the JVM and runs acceptably in C++.

Also, C++11 is not a low-level language anymore. (And I say this as a long-time Lisp and Clojure programmer.)

technomancy• 12 years ago

I think the point is that claiming speed is a property of languages is simply a category error, like saying programming languages are green or noisy. These can be properties of programs (well, properties of a given execution of a program) but have nothing to do with languages.

addflip• 12 years ago

Whenever I see the story is from Wired I always check the comments to see if it's worth my time more often than not it isn't.

nawitus• 12 years ago

I think most programmers I know have heard of D. When I took at look at it years ago, I concluded that the main problem was that it tried to please everyone. There's simply 'too many' features without a core theme to drive programming.

srean4• 12 years ago

In a fun and meta sort of way you are saying D has not tried to please you. There are structural problems with this kind of criticism btw I have upvoted your comment, I do share the vision of a small elegant language yet sufficiently powerful language. At the same time I if some parts of D were to be thrown out I would find a way to complain about it. In fact one of my gripes is that it does not have compile time sum types and pattern matching, that and lightweight and efficient fibres (I believe these abstractions still use OS's threading mechanism underneath, I would be very pleased to be proven wrong).

The thing is D initially wanted to be C++ done right and then C++ done better. So with that in mind it has to have a lot of features. I do appreciate a lot that D feels a lot more homogeneous and designed rather than built up with unrelenting accretion the like C++. An aspect that I quite like is that if it is not immediately clear what should be the right way to resolve a design problem (for example name clash between function overloading and specialization) the D tendency is to make it into an error till the right solution/semantics emerges. In C++ sometimes the choice is somewhat arbitrary: here we have k choices lets pick one and go with it even if it has nothing obviously convincing going for it.

I would like to draw your eye towards templates and template metaprogramming. It really feels bolted on C++, and its really tortuous to use. In D however, although it was added much later it gels very nicely with the rest of the languages. Template metaprogramming is nothing special in D. Its just a function like any other except that it and its arguments are evaluated at compile time. (for D developers reading this, please can we have reference counting for CTFE).

So yes you are correct, it has a lot of features, given D's design scope that is hard to avoid, but these features do fit well enough with each other for a practical language to be used in anger, and fit a lot better than its immediate rival C++ / Java.

WalterBright4• 12 years ago

You're right in that people often comment that D has too many features, and btw please add X, Y and Z features!

bithush• 12 years ago

They got it wrong, the next big language is obviously Limbo![0]

[0] https://en.wikipedia.org/wiki/Limbo_programming_language

acomjean• 12 years ago

The problem with low level languages is they don't live in isolation.

As someone who worked on a large project in Ada, you'll need to at some point use the OS and its libraries which for Unix is in C. Want to network or get a OS semaphore? C. Many languages support this call to the C library functionality, but it always seems to force a lot of things back into the C way of doing things.

Maybe with a runtime (Java!, or ada tasks) this is abstracted away, but its still there..

jobu• 12 years ago

Alexandrescu talked about D at Boostcon a few years back, and as I recall he was planning to make it compatible with C system libraries.

WalterBright4• 12 years ago

D has been compatible with C libraries since the beginning.

CountHackulus2• 12 years ago

Many of the libraries you'd want to use are already ported or binary compatible (just need a header file) with D. Given that a fibre-based web framework has been written with it, and that it can use pointers natively, there's not a whole lot you can't do with it. Even writing bare metal code should in theory be doable with some work.

russelluresti• 12 years ago

I read the title of this article and thought "HN is now a parody of HN."

pnathan• 12 years ago

Last time I looked at D (maybe 6-8 years ago), I saw a C++ reskinned, and two standard libraries, incompatible.

Looking at it today, it looks much more modern, but I'm simply not interested. I've drunk the Rust koolaid. :-)

(But it would be interesting to do a compare and contrast with a decently sized project for both D and Rust).

drudru11• 12 years ago

cade metz alert

exacube• 12 years ago

Man, Facebook has a lot of hookups with Wired. You always see articles on Wired about Facebook projects and tech.

relevant: Co-creator of D works at Facebook.

wkdown2• 12 years ago

Let me put on my tinfoil hat for a second.

Two companies that love user data are making "languages" for us to write our applications with (Facebook with Hack and React, Google with Dart and Go)

The NSA worked backdoors into RSA encryption. Could the Facebook/Google compilers provide a similar backdoor for them to syphon data?

/tinfoilhat

WalterBright4• 12 years ago

D is all up on https://github.com/D-Programming-Language so I think it'd be kind of hard to sneak things into it.

wkdown2• 12 years ago

I was speaking of the four I mentioned, not D

kilon• 12 years ago

Programming languages are so previous century. The future is environments that move away from the machine and deep inside the user's mind. Automation taken into extremes.

The Next Big Programming Language You’ve Never Heard Of

Related Stories