Call it educated speculation based on years of experience with similar decisions.
How big is the team? How many years of maintenance have you had on those projects? I remember C++ looked pretty awesome for a while. It was certainly great for one-man projects or small team. Then the problems started piling up. Thing is, C++ didn't have any good alternatives (maybe now we'll have Rust); Scala does.
Scala is not C++. Scala has much better features to keep complex pieces of code separated from the simple pieces. Also C++ design philosophy was totally different from that of Scala's - C++ values performance over everything else, while Scala's top priorities are correctness and type-safety.
Nope. C++ is almost a superset of C (there are a few minor differences, but most C programs are correct C++ programs).
Even the most basic Scala program is not a valid Java program. They are just two different languages targetting the same platform.
If making analogies, a much closer analogy would be to say Scala is to Java what D or Rust is to C++.
As of lots of baggage - can you elaborate? Only null comes to my mind and it is never an issue - it was left because Scala is practical. Sure, there are some limitations imposed by the target platform like lack of TCO, lack of efficient suport for tuples/value-types, or RTTI for generics being not powerful enough, but Java-the-language has nothing to do with it. The same limitations apply to Kotlin and Ceylon.
That's not fair, first wait for Kotlin to exist (stable release in @18 months last I checked) before making such a comparison.
Scala 2.12 and Kotlin 1.0 release points should roughly coincide. Scala's got a wee bit of a head start, but if Kotlin delivers on the promise to compile as fast as Java, then for sure they'll gain traction.
Speaking of build times, just got back from the ScalaExchange conference in London (suprisingly large turnout, a little over 400 attendees). Talking with one of the Typesafe team members, it appears that Jason Zaugg (works on the compiler) recently found a way to reduce build times by 20-30%...and that's just for 2.11, good times ahead ;-)
Should point out that incremental builds + sub projects pretty much completely mitigate the "scala is slow" argument, but for deployment Jason's recent enhancements will be a boon to all Scala teams, large and small.
This is little inconsistent. Kotlin is well under development since 2010 and was published in 2011 or earlier, so it is already a 2 or 3-year-old project.
This doesn't matter much, v1.0 is a very important milestone because very little will be written about the language before then. Also, nobody will consider using a pre v1.0 language in production, no matter how many years it was in development.
The most annoying thing about IntelliJ is the way it's keyboard shortcuts clash with virtually every keyboard shortcut of your average Linux distro. Other than that it's an awesome tool.
You can edit them to your heart's content though. I have never had an issue, but I use the "Default for XWin" setting. There are about a dozen other keymap templates available by default, though.
Reified generics is one of the reasons why Scala on the .NET is effectively dead. The VM's type system isn't powerful enough to support some features of Scala, such as higher-kinded types.
But the JVM not having reified generics is a mostly a blessing for Scala. With reified generics, your language's type system can essentially be only as powerful as the VM's type system, and I think it's clear that Scala today wouldn't be the same if Sun had gone the reified generics route.
(Still, it would be nice to have specialized generic containers for some primitive types in the JVM)
Tail calls are actually rather un-optimized in .NET. F# avoids them as much as possible. F# used to emit tail calls any time it could, but it hurt performance. IIRC, tail calls were also ignored in many areas prior to v4 (and they still have some limitations IIRC). The JVM could implement tailcalls via analysis; the tail prefix isn't truly needed.
But Xamarin's porting of Java to C# to run Android on Mono without the JVM did show a rather large perf increase. I'd assume that's mostly generics eliminating boxing.
What do you mean by "The JVM could implement tailcalls via analysis"? Offhand, I can't see a way for this to be practically viable, but I may just be lacking imagination.
Maybe I'm dense, but why not the same way a compiler implements it? In a recursive function, at the point of recursion, flag the call to have codegen not setup a new stackframe and just reuse the current frame.
But you may be right that this might not be viable to run fast enough for JIT on a large codebase. Obviously you could tail-call enable every call that's eligible, but that probably doesn't generate optimal code. OTOH, they have tracing in the JIT for hotspot stuff, right? So if the tracing part counted how many call loops it had hit, it could decide to implement tailcalls in that path. Or perhaps it invokes analysis when the stack gets to be 75% full.
Right, my thought was that doing real tail calls everywhere that's eligible would almost certainly be a performance disaster. I'm not sure that hotspot could help, at least if applied naively, since correctness depends on never missing a tail call that could lead to unbounded stack usage.
For example, consider an F#-like language on the JVM. Given the definition `let apply f x = f x`, you could imagine `apply` getting called in all sorts of contexts that don't result in unbounded recursion, so a hotspot-like system would not generate a tail call when compiling the method given the first N invocations. But then if another function is defined as `let rec loop n = if n < 1 then n else apply loop (n-1)` and invoked as `loop 10000000`, then the lack of a tail call in `apply` is fatal.
So if something kicked in at 75% stack usage (via a guard page?) and forced analysis, wouldn't that work? It'd be like the plethora of JVM options now: another configurable switch.
How much of the stack are you willing to look at when you hit a guard page? The non-tail call might not be right near the top, depending on the structure of the code. I'm not saying it's impossible, but I think the approach of having the higher-level language add the annotations is probably more practical.
If the tail-call-needing function isn't found rather quickly (say, in the first 100? frames), then isn't it unlikely that the tail call will help? That seems like a much rarer case. Is the cost of going 1000 functions deep that expensive? Most threads aren't gonna hit a high % of stack without having some sort of problem anyways.
Of course it'd be better for the JVM to support this in bytecode, just like generics, stack allocation, and pointers. But it seems to me that if there was a real solid need for TCO then a JVM could implement it with tunable heuristics (most Java code doesn't need TCO, so if your code really depends on it in complex scenarios, you can always pass a -XXTcoInspectionDepth argument.)
Note that Scala doesn't implement general tail call optimization; it only applies to direct self-recursive calls (as far as I'm aware). By contrast, on .NET F# implements true tail call optimization, including cases where the call is statically unknown at compile time (as in `let apply f x = f x`).
.NET is Windows-only, which is a significant limitation compared to the JVM. I don't think better performance on Windows -- even assuming going to CLR instead of JVM would provide that -- is a good reason for Scala to move to the CLR as the primary target.
I understand your point. Consider this: using Xamarin you can get native performance on iOS and better-than-Dalvik performance on Android. Is there a good tool chain for that in JVM/LLVM world that supports Scala?
"Better than Dalvik" isn't necessarily a compelling selling point looking forward, since Android is almost certainly going to moving from Dalvik to ART as the default runtime fairly soon.
I don't think it's unreasonable to respond to a very poor quality blog post bashing Scala since it received very widespread publicity. The interesting story behind the story is the extreme enthusiasm with which Scala bashing posts are upvoted on various forums. It's highly unlikely that the majority of those voting have actually used Scala.
Despite that post for tolerance of other JVM languages, I still found the linked (original) thread a type of toxic community I haven't exactly seen before. Peppered with great posts, but overall, disturbing.
Self-important to an extreme (We are a threat to them .. mentioned dozen+ times), often describing people who don't like Scala as either lazy or defensive. The concept that someone could be very adept at Scala, and still think it isn't a good language (and set of important libraries) is simply a non-starter for them.
That type of fundamental arrogance in a community so young is bad news -- and it appears to come right from the top.
On the upside, there was at least begrudging acknowledgement that issues actually exist.
Please don't exaggerate. There are only 2 posts from the same user there where an author mentioned laziness and self-defence as possible reasons to dislike Scala.
Most posts are really about the existing problems and what can be done to improve things in Scala. In general I find this conversation very constructive and mature. I use Scala at work and see how things are gradually improving, and this conversation makes me more assured that language/community continue to move in that direction.
Removing structural typing wouldn't be an improvement to my mind. It's the sort of thing you use maybe once a year, but when you do it's extremely useful to have around. It's a bit like saying that removing the ternary conditional operator in Java would make a big difference to developers' lives.
I think the kind of features you use maybe once a year are a bad thing to have in programming languages - ease of reading is more important than ease of writing.
I should also point out that it's a feature which I don't believe detracts from readability. It's pretty clear from looking at code which uses ST what it does. There are examples in this thread.
It's a feature that you will use directly maybe once a year when adding it to a library, but I then use that library (and indirectly that feature) virtually every day. YMMV but we've found it very useful.
The quality of the original "1-star" blog post was extremely low. Odersky sums it up well with:
This week-end's edition is called "Scala - 1 Star - would not program again", and it's by someone who from reading his post seems to have written Scala all of two weeks after coming form Javascript. I think the interesting bit is not so much that these posts are written, but that they are upvoted so much.
I was also very surprised to see such a low-quality blog post being voted up with such enthusiasm on HN and elsewhere.
When somebody reads that X is better than what they're using or that X is the "next big thing", they're liable to feel this as a personal attack. It's like their choices were wrong--they should have gone with X instead. This isn't usually how the articles about X are actually meant to be read, but it's how some people see them nonetheless.
Now, these people are feeling slighted (however unfairly). They're not going to drop everything and pick up X. Fair enough: jumping to every shiny new technology would be madness. But chances are they won't even bother learning about X properly. Instead, they want some plausible sounding reason about why X is not all it's cracked up to be, about why they're actually smarter for not using it than vice versa, about why it's all just more hype. They want to stick it to those smug X-using bastards.
So they vote up critical articles that just happen to be written coherently, regardless of how accurate they may actually be. And so we get dross on the front page. Happily, the HN comments tend to paint a much better picture: they simultaneously debunk the original argument while exploring the actual upsides and downsides to X. With these sort of articles, the contents are worth far more than the actual blog posts.
X here is anything from Scala to NoSQL to functional programming. The recent article about what is wrong with FP and OOP is a perfect example of this, which annoyed me in particular. And yet, I think this sort of thing is virtually inevitable if functional programming is to grow and become more popular, so it's more than a worthy sacrifice.
Is this not an ad hominem attack? The original post writer joked about Scala syntax giving him a headache. I too felt the same way the three times I've briefly looked at Scala. I think some of the points made in that post were valid.
I'm very sure it isn't meant that way. Two weeks of exposure to Scala really is not nearly enough time to learn the language if you haven't any previous experience with strongly-typed functional languages. If you have deep exposure to both Java and Haskell then perhaps you could be productive in Scala in two weeks but even then if you wrote a rant like this your criticisms would still likely be on shakey grounds.
" very surprised " - seriously, considering the number of JS fans here? Post something like "[any old/boring stuff] - but in JS/WebGL/HTML/CSS now!" and you will get at least a hundred votes.
People love controversy, and Scala is relatively new/unknown.
But the fact that the article got disseminated so widely speaks volumes about the need for curation. Delegating it to users simply ensures it meets a certain minimal threshold.
Also be aware that people like myself that don't know much about Scala, but are trying to keep it on their radar, may upvote such a post just to try and see where the comment thread goes and see if there are good insights from the defending community.
Often an upvote doesn't mean I agree with the post or even its tone. Just that I want to see some further discussion.
(I don't know if this is in the spirit of HN, I appreciate it must be maddening for some people to see 'low quality' posts get upvotes).
I thought the discussion the prior article created was really useful. Learned many things, including some things to look out for while evaluating, and other languages that people seem to like.
Remember there are a lot of groups who stand to lose if Scala results in a renaissance in the JVM platform. In particular those newer platforms e.g. Go, Clojure, NodeJS etc.
Plus HN has always been a moth attracted to any flame(bait).
I don't think Clojure has to loose if there is a renaissance of the JVM, however it will have less space to exist if Scala becomes what people think when they think "FP on the JVM" (and it's starting to become the case).
I don't think Clojure's popularity will be heavily affected by Scala's, but rather by the contingent of people who want to do dynamically typed and/or lisp-y programming on the JVM. I see Clojure competing more with Ruby, Python, jRuby, Lisp, etc than Scala. There may be some subset of those who can and will cross-over to statically typed Scala, but I think that for most part dynamic fans tend to stick to dynamic languages.
If there's a language-based JVM renaissance and we don't end up in a place where what targets do rather than what they're written in (beyond "language X makes this problem easier", anyway), then I'm not sure it's really a renaissance.
None of those will lose if there's a renaissance in the JVM platform. Go is a competitor to C more than the JVM, and is a FOSS Google product that's becoming their 4th official language and is not going away. Clojure is part and parcel of that JVM renaissance. And Node is coming to dominate client-side development by underpinning an emerging build tool standard - Gruntjs, and arguably the CommonJS-based Browserify, which will dwarf the parts of Node that compete with the JVM. None of these are heavily threatened by a server-side JVM renaissance.
Go isn't a competitor to C. Having a mandatory garbage collector makes that pretty clear. Go is instead a competitor to the legion of other high level, predominantly application-focused languages: Ruby, Python, Java.
Rust is an alternative to C and C++, but Go doesn't have a claim to that.
Discussion of tools is pretty important, and the "1 Star" blog post summarized a programmer's feelings about a tool. Both of his main complaints, compilation time and impenetrable operator overuse (remember, this is the language that brings us arbitrarily overloadable beauties like _._ and :+= and <%<), have been acknowledged in Martin Odersky's post.
When we, as programmers, choose tools, we make both a bet and an investment. We invest our time — both up-front in learning the tool, and during the course of a project — and bet that it'll pay off relative to using other tools. A blog post which gives a hint as to the expected value of this bet is appreciated. Hence the upvotes.
FWIW, I think Scala is a razor in the hands of a monkey, and it turns me into the monkey. I read Odersky's book 4 years ago, and it left me with a horrible taste in my mouth. I consider myself a competent programmer in Common Lisp, Clojure, Java, both C and C++ (including C++11), JavaScript, and Ruby; yet I do not trust myself with Scala.
PS: And this is just language semantics. Let's assume that Scala will eventually compile faster and solve its binary backwards compatiblity problems.
* You might be better off using a pre-release snapshot of Java 8 as a better Java. You'll get closures, functional collections, and better type inference. I bet Eclipse and Intellij support it better too.*
You lose out on most of the features of Scala, and IntelliJ supports Scala very well.
