The Next Big Programming Language You’ve Never Heard Of • Hacker News Board

Re: The Next Big Programming Language You’ve Never Heard Of

#41

Post by pron » Mon, Jul 07, 2014, 6:21 PM UTC

YZF wrote: post #26

rossjudson wrote: post #16

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 performan…

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 so…

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

Re: The Next Big Programming Language You’ve Never Heard Of

#42

Post by soundoflight » Mon, Jul 07, 2014, 6:22 PM UTC

jordan0day wrote: post #17

tdees40 wrote: post #7

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

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

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

Re: The Next Big Programming Language You’ve Never Heard Of

#43

Post by pron » Mon, Jul 07, 2014, 6:23 PM UTC

brimstedt wrote: post #36

YZF wrote: post #26

Earlier quoted context omitted.

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 so…

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?

I think Java is exploring that for version 9, but this can only improve startup times. When you consider the entire lifetime of the program, JIT compilation is negligible, so there's no point in caching the results (other than to improve startup time). Also, the JVM never (AFAIK) "settles" on a specific machine instructions. It will always be on the lookout for optimizations that are better adapted to the current execution profile.

Re: The Next Big Programming Language You’ve Never Heard Of

#44

Post by pnathan » Mon, Jul 07, 2014, 6:25 PM UTC

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

Re: The Next Big Programming Language You’ve Never Heard Of

#45

Post by CountHackulus » Mon, Jul 07, 2014, 6:25 PM UTC

tdees40 wrote: post #31

srean wrote: post #10

Earlier quoted context omitted.

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 discu…

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.

Having used both, I'd say yes. C++11 does some wonderful things, many many improvements that were a long time coming, but D put those improvements into the core language and their standard library. This makes D much more readable and hackable than C++11. Not to mention the metaprogramming support is significantly easier to use (though not more powerful, as they're both technically turing complete).

Re: The Next Big Programming Language You’ve Never Heard Of

#46

Post by CountHackulus » Mon, Jul 07, 2014, 6:29 PM UTC

acomjean wrote: post #33

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!, o…

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.

Re: The Next Big Programming Language You’ve Never Heard Of

#47

Post by YZF » Mon, Jul 07, 2014, 6:32 PM UTC

brimstedt wrote: post #36

YZF wrote: post #26

Earlier quoted context omitted.

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 so…

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?

There's a technique called Profile Guided Optimization which is a little like that.

Re: The Next Big Programming Language You’ve Never Heard Of

#48

Post by twic » Mon, Jul 07, 2014, 6:33 PM UTC

brimstedt wrote: post #36

YZF wrote: post #26

Earlier quoted context omitted.

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 so…

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?

I think you might be talking about tiered compilation, in which case, yes:

http://www.azulsystems.com/blog/cliff/2010-07-16-tiered-comp...

The Azul JVM has been doing this for some time. The Sun/Oracle/OpenJDK JVM started doing it in JDK 7. I think IBM's J9 JVM has been doing it for some time too. I'm sure Microsoft's CLR VM does it, they're a smart bunch.

Re: The Next Big Programming Language You’ve Never Heard Of

#49

Post by gcv » Mon, Jul 07, 2014, 6:34 PM UTC

rossjudson wrote: post #16

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 performan…

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

Re: The Next Big Programming Language You’ve Never Heard Of

#50

Post by YZF » Mon, Jul 07, 2014, 6:39 PM UTC

pron wrote: post #41

YZF wrote: post #26

Earlier quoted context omitted.

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 so…

> 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 trigge…

You mentioned that on the other discussion. Can you tell us a little bit more about inlining of virtual functions? It doesn't sound like something hugely valuable because if you're performance driven you're already not using virtual functions for places where that overhead is unacceptable (and generic programming is what lets you do that).

I've done lots of multi-threaded programming in C++ some of it with lock-free structures. C++11 brings things like async, futures, promises etc. to the table in the standard library and there are also other concurrency libraries and tools (e.g. OpenMP). Can you expand on how GC would make my life easier in general? Surely it depends on the nature of the task you're trying to solve, locks aren't always the bottleneck and there's not always concurrent solutions.