oelang

One small correction, they're funded by the Swiss taxpayers and the European union.

The evidence is that all high performance garbage collected languages use some form of generational collectors. These implementations aren't made by idiots.

for a deeper discussion see: https://www.infoq.com/presentations/java-vs-c-performance

All talk & no benchmarks. If reference counting with cycle detection was faster, the jvm & clr would use it.

This project has been discontinued. But fear not, a new scala-native is on the way, Denys Shabalin a phd student at EPFL is working on completely new implementation of scala-native. His previous work, scala offheap, a way to use off-heap memory on the JVM with type- and memory-safety is very impressive.

I would add 'Scala in depth' to the book recommendations, it's similar to 'Effective java', the book you need after you have used the language for more than one year.

> As a programmer who is not a physicist

Let me stop you right there...

Intel recently contributed improved auto-vectorisation for artithmetic to the hotspot compiler. Auto-vectorisation of move instructions has been in hotspot for a few years.

The 20% comes from personal experience, maybe I should have said 'close' but that can also mean anything. Basically this is an area where the hotspot heavy duty compiler (C2) does the same optimizations as gcc or llvm. I would say that I would expect gcc & llvm to be within 20% of each other. The 20% is basically different tradeoffs made in the optimization pipeline (different peephole opts, different auto-vectorisation, register allocation algorithm, ...).

Java starts to seriously lags behind C++ when you need good control over the memory layout of your data. In java you can't have an array of objects, you get an array with references to objects. There are no elegant ways to solve that problem, the language just lacks the proper tools to do it elegantly. Memory layout is of course vital for cache efficiency, so that can give C & C++ a big advantage over java. Since this benchmarks uses arrays of doubles, this isn't an issue.

Floating point calculations are only guaranteed to be platform independent when you use the 'strictfp' modifier.

"Java's issues with floating point arithmetic in high-performance scientific computation"

Can someone explain this?

Meh, they dismiss java & pypy very quickly but they don't understand that these languages require warm-up. If you benchmark runs in less than 2 seconds half of the time measured is starting the runtime, profiling & compiling code. I think that interesting computational problems in economics have a much longer running time.

For this kind of algorithm, basically working with arrays of doubles, java should be within 20% of c++ and normally it is just as fast.

I don't think it's meant to be used directly. It's a minimal api (just 4 interfaces) that can be used by various reactive frameworks to interoperate with eachother.

And in scala it's just listOfTxnAmounts.sum or listOfTxnAmounts.max, long live typeclasses (but that's too complicated for 'normal' programmers right?)

We've had dynamic OO+FP languages for a very long time but only in the last 10 years have we seen them with static type systems. I really like clojure (though I haven't used it in anger) but I think you're wrong when it comes to complexity.

Complexity with dynamic languages grows with the size of the project. I know that because of the focus on purity & immutable data structures clojure mananges to mitigate this problem but I'm afraid it's still there.

The last few years several features have been added to clojure that increased the complexity(/surface area) of the language and the documentation is often a mess. I'm not a clojure hater, just pointing out that the complexity with clojure lies elsewhere.

edit: kinda forgot about Ocaml (~18 yrs old apparently)

Dispatch was one of the first libraries for scala, it's not really fair to use it as an example.

The latest version of dispatch doesn't have that many operators anymore. http://dispatch.databinder.net/Combined+Pages.html

If you compare Scala other recently released languages (swift, kotlin, ceylon) they're all kindof similar, some claim to be less complex but imho aren't. Functional + OO is becoming the norm: the C# team is considering to add pattern matching and it looks like java 10 may have some twisted form of type classes.

'Scala the language', is imho very nicely designed, the problems arise in the compiler implementation and the core libraries. Scala carries around too much dead weight in it's core libraries. Some poor choices were made while scala wasn't widely used yet and it's very hard to fix that now. If you look at the roadmap for scala it's obvious that they are trying to address these issues.

The author seems to think that java 8 lambdas are faster than scala lambdas. This isn't strictly true. Java 8 spins the inner classes for lambdas at first use, this gives them a performance boost at startup (loading tons of tiny classes from a jar is painfull for the jvm) but at runtime they perform the same (it's just invokevirtual). Another optimization that java 8 has is that lambdas that don't capture are cached & reused, scala does the same if you use the -optimize flag.

The first thing that I actually thought about when I read this was junit hamcrest matchers, sure it's concise but I don't consider it readable at all. The limited expressivity of java really gets in your way.

With scala you can write test that are concise and readable with ScalaTest or ScalaCheck. The readability largely depends on the quality of the library that you use but also the user.

The problem is that they add a new language feature for every new use case instead of trying to make features fit together in a nice compact core & building on top of that core (in other words 'modern language design'). Systemverilog now has ~250 keywords, do you think you know all of them? There are so many that they allow you to selectively disable keywords using compiler pragmas. In python there are only 33 keywords! VHDL avoided this issue because they mostly copied the ADA language which was developed by competent language designers.

I don't doubt the usefulness of a subset of systemverilog, but as a language it's very badly designed.

PSHDL is incredibly low-level & basic, afaik it doesn't even have functions & you can't define your own datatypes. I think it's a mistake to make a HDL language that aims to be 99% synthesize-able. I didn't write this but I do agree with it: http://www.jandecaluwe.com/blog/its-a-simulation-language.ht...

I haven't looked a chisel yet (scala is my favorite software programming language though).

Because reasoning about hardware is hard it's important to be able to rely on simulation. I'm not saying that all issues can be caught/detected in simulation but many can. In most designs 90% of the code (typically the synchronous logic) can be fully debugged in simulation. Ok there is still a portion that can't be debugged, and you'll likely spend a large amount of time on that final 10% but the alternative is certainly worse.

A good designer can avoid constructs that can't be or are very hard to simulate correctly. A good example is signals that have to cross clock domains, metastability is easily missed in simulation and the problems it causes in actual hardware are huge. Good hardware design tries to avoid or encapsulate these kind of constructs.

Beyond this you still have to deal with the analogue world and that is often hard to simulate. Clock generators that misbehave, working with memory controllers (and buggy IP cores): it's not all under your control and that why hardware design often feels so hard. A lot of time is spend on these issues, but that's only because the rest is made easy by using VHDL.

My point was that the first optimizing compiler isn't comparable with what is expected of a modern compiler, so please don't compare their code & memory footprint. With the first fortran compiler it was garbage in, garbage out. A modern compiler can (often) turn garbage into fast code.

Nowadays inside a compiler it's 90% graph processing & reprocessing. Since you're dealing with (cyclic) graphs, garbage collection is very useful and if you don't use some automated gc, you'll probably roll you own in one way or anther.

And a X86 interpreter isn't comparable with a compiler either. I doubt that there was any GC going on in your example, everything probably runs in a single array that represents the memory. Maybe some temporary objects but JS engines have good generational GC these days, I don't think D uses a generational GC algorithm.

I think verilog (and mostly systemverilog) is beyond saving. Systemverilog has a spec bigger than c++ and it's full of broken, unused features or features that aren't compatible. Over the years they have added any feature that some HW engineer asked for resulting in a true kitchensink language. I don't think that there is a single simulator that implements the complete spec. (and on top of the regular language they use lexical macros very heavily)

VHDL is a little better but the syntax is horribly verbose and it lacks power to do advanced verification (either it needs a better library or it needs a few more features). In my mind VHDL can be saved, some VHDL-coffeescript could be wonderful.

MyHdl is interesting, it's build with clear goals & it's made by an experienced HW engineer that also understands good software design (most don't). He would disagree with you about simulation (http://www.jandecaluwe.com/blog/its-a-simulation-language.ht...). The RTL code that MyHdl generates always looked very clean to me and the simulation possibilities with python are of course infinitely better than anything that systemverilog or vhdl can offer.

"it generated quite good machine code, almost as fast as the hand coded one"

I'm sorry but this is complete bullshit. What is expected of a compiler these days (SSA, advanced instruction scheduling, smart inlining descisions) is not comparable with what the first optimizing compilers did.

I tried it, it's not flexible enough for my needs.

Many people here don't seem to understand what is meant by backwards compatibility in the context of the JVM. Scala has very good source compatibility, this means that scala code from 2012 compiles just fine with the latest scala compiler.

Compared to Java, Scala has poor binary compatibility between mayor releases: a library compiled with scala 2.10 will not work with scala 2.11 In java you can use jars created with java 1.3 in your java 8 project.

Go doesn't guarantee binary compatibility either, they (just like scala) guarantee source compatibility.

It's too easy in scala to create a giant mudball codebase where every file depends on half the project. Managing the compile graph is almost impossible when you have 20 hackers on the same codebase.

Sometimes I wish that scala had some compiler-flag that signals these problems, maybe a restricted mode or something with annotations.

Is this the first mayor scala release that doesn't introduce a huge language or library change? Transitioning to 2.11 should be smooth, aside from some library deprecations not much has changed.