The JVM situation
groups.google.com
groups.google.com
- Can't get threads really right.
- Have some lousy pausing single-thread mark-and-sweep GC.
- Is proprietary and bound to one dying platform.
- (Bonus points) has 3rd party libraries that are not thread-safe or segfault from time to time.
WRT "making language not unlike Scala but with better interop", Kotlin and some other projects seem to do that but they can't get themself out of the door :(
- Proper task isolation with pointer ownership.
- No global GC. Task-local GC when needed, and explicit ownership otherwise.
- Mozilla.
- No NullPointerExceptions. Unsafe code is convenient when you need it.
It's an industrial research project, basically. When the semantics stabilise I reckon it'll be a technical winner in its chosen domain.
But in the long run, it'll be worth it, and I have no doubt that Rust will become an amazing language worth using.
JVM and CLR are not very different. What would be the reasons to want to avoid JVM, but still consider CLR as an acceptable choice?
The Windows-based implementation of the CLR is proprietary, but as other posters have mentioned, it's built around an open, standardized specification (ECMA-335). Xamarin has been making big strides in improving Mono over the past year, and it'll only continue to get better.
Most things work, but there are a few things that are broken in unavoidable ways. Similarly, the performance isn't terrible, but the optimization is not quite at the same place as the original platform.
Xamarin's rapid work suggests that there will be a 'production-ready' CLR for most platforms (they've got it down for iOS, Android, and recently OSX) soon enough.
Right now, they are stuck in the odd middle, but it is still an amazing value if you are building common code cross platform apps.
For an outsider it looks like a C++ for JVM: A language of endless short-sighted features that's going to bury yourself under it.
It's not even Haskell because Haskell strives to be elegant.
But let's just look at one element of Scala's truly byzantine iteration logic collection: Iterable
Inherited: Iterable IterableLike Equals GenIterable GenIterableLike Traversable GenTraversable GenericTraversableTemplate TraversableLike GenTraversableLike Parallelizable TraversableOnce GenTraversableOnce FilterMonadic HasNewBuilder AnyRef Any
Implicitly: by traversable2opsby MonadOpsby any2stringaddby any2stringfmtby any2ArrowAssocby any2Ensuringby alternateImplicit
Source: http://www.scala-lang.org/api/current/index.html#scala.colle...
..and now explain what all these aspects actually do! And that's just one small element!
And look at the method set of that thing.. Whoa! Again C++ suddenly seems minimalist.
Also, the implicits shown are any implicits which can be invoked on Iterable, which includes all implicits which can be invoked on Any.
If Scala is used as "ML with OO features when really needed but not otherwise" it's quite nice, but I would not advise using Scala without a style guide for a multi-developer project.
Considering that Scala ships with BOTH tons of collection types AND tons of useful operations, this seems to be a sane thing to do.
Scala manages ...
- to make both adding a new operation AND adding a new type not suck too much
- to retain the “best” collection type through operations, without duplicating code left and right
Most other languages fail already at point number one. No other language has managed to achieve point number two, let alone both.
Front and foremost, though, I found tooling to be lacking. Reading a stack trace is horrible, the compiler is slow and the two most mature IDEs (IntelliJ IDEA and Eclipse) both have problems highlighting/checking and completing code.
For now, I'll probably stick with plain old Java.
You should consider Clojure. The community is evolving in a way that compensates for some of the tool chain problems, and Leinengen is definitely more intuitive than SBT.
My traditional bias favors static typing, but I think Clojure might beat Scala because for most web applications, runtime typing (you can implement similar guarantees as in compiled languages; however, checking isn't at compile-time and therefore your testing will be less performant) is good enough.
Writing tooling is incredibly difficult, especially when Eclipse isn't really designed to support new JVM languages. It is easier to write an IDE for your language than to plug into Eclipes.
First, the JVM really IS NOT a great choice to build other languages on. It wasn't designed for it; In fact before invokedynamic, it was nearly impossible. For all intents, building other languages on the JVM is a bad hack, regardless of how elegant ( or not ) the language syntax is. The amount of fuckery required is nearly unbelievable.
Second, the JVM is owned by Oracle. It is technically 'open source' but Oracle has proven time and again to not only be against open source, but one could even support the position that they're actively hostile towards it.
Ideally, the solution would be to invest engineering mind-share into creating a REAL VM that was designed to host many programming languages. Regardless of what you think of Microsoft, they got .Net correct in that their tooling infrastructure was built from the beginning with multiple programming languages sitting on top of the CLR ( and later the DLR ). The LLVM folks have been making some progress in this regard by way of VMKit, but personally I cannot understand why this issue doesn't get more mind-share. Python, Scala, Ruby, Clojure, Lua, etc would all benefit in the end.
I think this is possibly where languages like Scala may lead, potentially forking a JVM and refitting it to their own needs.
The implication that the Oracle JDK is the JVM equivalent of Oracle/DB2 is rather unfair. The Oracle JDK is really OpenJDK, which is, as the name suggests, open source.
It is true that there is one behemoth corporation behind OpenJDK, but that still makes it the equivalent of Chrome or Eclipse, not Oracle or DB2.
To most of these people, Scala is merely a tool, often just one among many others. They fully realize that it has flaws, and are very willing to acknowledge the existence of these flaws. They don't take it personally when somebody points out such problems. This is quite evident after reading through the discussion in this case.
This does differ from how members of the the Ruby and JavaScript communities take criticism of those languages, for example. Such people do tend to be much more emotionally attached to those programming languages, for whatever reason. They react with hostility and denial when they encounter legitimate criticism.
Technological improvement happens best when criticism can flow freely. The people involved are focused on acknowledging and accepting that flaws exist, and then proceed to try to fix them. On the other hand, when legitimate criticism is shunned or blindly denied, like in the JavaScript community, technological progress proceeds at a much slower pace. More effort is placed on defending and maintaining the status quo, even when this is the most ineffectual and non-beneficial thing to be doing, than is expended on improving the situation.
It seems to me that there is a pretty typical mix of criticism coming from inside the Ruby and JS communities being responded to thoughtfully, and criticism from outside being responded to defensively.
If somebody who has never posted came out of the blue, and listed some criticisms (which are well researched and valid), it should be taken just as seriously as Tony Morris's piece.
Citation needed, Rubyists in particular have been whining (and rightfully so) about MRI's poor concurrency support for the past year or two. That's just one counterexample.
Everyone that I know that's good at Ruby has their own favorite wart where it does something they hate.
To be fair, there's a huge difference between complaining about an implementation and complaining about the design of a language.
A lot longer than that, but, to be fair, that's a criticism of the main implementation, not the language -- and one of the selling points of JRuby. OTOH, there's been lots of criticism, and dissection, in the community of infelicities in the language design that make it difficult to implement efficiently.
Don't forget Go. :)
It is an incredibly well-designed language, but lots of that effort has gone into covering up some really nasty warts.
For me, attaining a factor of 5 lines to 1 line code shrinkage translating from a legacy (though still imperative) codebase is amazing, and must point to an excellent language design. Of course I realize I could probably achieve the same thing with a number of other functional languages of which i have limited experience
Tony Morris (the person who started the conversation) is a pretty devoted Scala-er. But it is definitely recognised by Scala experts (especially people who are arms deep in the compiler) that the JVM is a very limiting factor in the design of the language.
On the other hand, reading Scala code written by mediocre developers is painful. That's probably true of any language, but in Scala bad code comes with (a) minimal support from the IDEs that make shitty code navigable, (b) a less mature reflection API, and (c) serious compile-speed pains at scale. If anything kills Scala, it will be the the Java-in-Scala crowd-- the ones who failed to learn what Scala was really about and what it had to offer, but used it because their bosses demanded it.
Scala is well-designed-- extremely so, and almost no one here could have done better in that time-- in the context of its constraints (JVM) and purpose (a Haskell-like language on a VM with a top-down type system-- radically different from the bottom-up tying approach of traditional Hindley-Milner languages). Scala-bashing gets on my nerves for two reasons. First, if you understand the compromises that had to be made, it's hard to imagine it being done better. Second, you know what happens if Clojure and Scala developers beat each other up? Managers step in and make us write Java.
> The one thing I like about the jvm is that I can compile
> and package code on one platform and deploy to another
> without worrying about anything but the fact that the jvm
> is installed.
https://github.com/Frege/frege
But it's definitely a work in progress.
Nope. Go does not need to be installed for a binary produced by the `gc` compiler to run.
There are two types of languages, the languages people hate and the languages no one uses.
For values of "no one uses" that set up the "like"/"not used" dichotomy, I'd say Perl is in both categories. With any luck Java will get there too one day, even if the JVM doesn't follow it.
Well, except LISP, obviously.
http://felix-lang.org/share/src/web/tutorial.fdoc
http://felix-lang.org/share/src/web/nutut/intro/intro_index....
All analogies are inaccurate, so with such inaccuracies assumed, one can look at Felix as: Felix is to C++ what Scala is to Java, but that is is not a very illuminating comment.
To give an idea, Felix is a whole program optimized, strongly typed, polymorphic, ML like language that can interact effortlessly with C and C++ code and has coroutines baked in. It uses a mix of lazy and eager evaluation for performance and compiles down to C++.
1. tool support (valgrind, gdb or better)
2. good performance - 64-bit on the major desktop OSes (mobile a plus, obviously)
3. real concurrency
4. libraries
5. build time for large projects ("compiles down to C++" makes me think this could be an issue)
Most new languages fail at several of these, for years. You'll notice that I haven't mentioned language design at all.
Regarding 3 it has had coroutines built into the language since the last 10~15 years, much before the language Go made it more mainstream. preemptive threads is more recent. It does have a stop the world garbage collector, which is not good for concurrent applications, but the semantics allows one to avoid creating garbage to a large extent. Libraries is chicken and egg, one needs higher level of adoption to drive this. 5 could be a legitimate concern, but I dont think its going to be any worse than Scala or C++ in this respect.
As far as language design goes, Skaller the author is a well regarded PL theorist active on LTU.
I am not saying this the best, end all language, but one that has enough interesting features that would be interest to the early-adopter rich crowd that we have here. It certainly has grabbed my eye balls
Thanks for the recommendation. I respect LTU-respected language designers. I didn't know it was 15+ years old.
Stop-the-world might be ok for batch compute work where I care about amortized cost (as long as the GC itself could use all my cores efficiently).
I'd be interested in the debugger experience - since it compiles to C++, I'm a little scared.
I think you meant parallelism there. Felix does have preemptive threads for that, but its a relatively new addition, so I expected it to be rough on the edges.
You will probably be able to catch Skaller on LTU, ATS mailing list and of course on Felix's own mailing list. He can answer questions better than I can.
I think you will have to debug the generated C++ because I dont think it preserves the corresponding Felix source lines by default.
The good thing is that it supports functional style (though not restricted to it), so you can debug individual functions easily enough. Besides it has robust and flexible type system (way better than C++'s) that you can enlist to catch errors early. It does type deduction so you dont have to litter the code with types.
Language design is important, but being a good fit for the platform is more important.
I also don't feel like Python is an option. Seeking more performance from a single node is what he me move to Java from Python for many of the the things I work on.
Almost everything truly important today is written in one of them, or both of them. The usable, production-grade implementations of PHP, Python, Ruby, JavaScript, Lua and Perl depend on one or both, as well. Most JVM implementations depends heavily on them, too.
When they're providing the foundations necessary for even their competitors or alternatives, it inherently makes them even more valuable and effective.
The Objective C number isn't coming from server development so one can infer a lot of Java's popularity is coming from Android.
In a perfect world, Google would have picked a great up-and-coming language for Android AND brought the tooling up to parity with Java as they developed Android. But they made the optimal choice at the time to be able to provide a very mature and powerful (n.b. did not say "friendly") toolchain at launch with the relatively small team they allocated to Android.
Android isn't built around a JVM. The Android Dalvik VM has properties that make a small OS that runs many VM instances possible. The JIT compiler strategy is tuned to increase performance without a big hit to battery life. Dalvik is the best VM for mobile devices. So if you think the VM has a strong influence on the popularity of a language, Java in Android will be a leading language until some significantly better JVM language gets good enough tooling in the context of the Android SDK to challenge it.
Java has mainly been relegated to enterprise apps and Android development. Now, that's not to say those are small markets. It isn't a "dead" language in any sense. But its scope is quite limited when compared to C and C++. We no longer hear the hype about entire operating systems written in Java, like we used to. There are no major relational database systems written in Java (Derby and H2, for example, are still quite limited). Even for web development and business app development, many people are moving away from it to alternatives.
Yet we still see C and C++ being used at all levels of software development, for software that sees extremely widespread use, in many different domains. They're used for developing the most critical and widely-used device drivers, OS kernels, libraries, application software, server software, compilers, interpreters and so on.
Whether you're using a server, desktop, laptop, netbook, smartphone, tablet, or even many embedded devices, you're almost constantly using a huge amount of software written in C and/or C++. Given this context, Java is a minor player, at best.
(I think MagLev is production ready -- and used in production -- and its based on Smalltalk.)
So at least in Ruby's case, its not the case that the usable, production-grade implementations depend on one or both of C and C++.
A lot of C# developers are stuck treating it as Microsoft Java, which it hasn't been for several years.
To me, the biggest problem with C# is cultural. C#'s user-community is entirely enterprisy... it's open-source adoption has been minimal, and that means that most C# code is still heavily stuck in a "cathedral" mentality where coders either use exclusively Microsoft libs (which are often terrible - no single company can ever be expected to get it right every time) plus some heavy wheel-reinventing, or maybe they pick up some gigantic vendor-backed 3rd-party lib like Telerik. There isn't the massive community of open-source developers like you see on other platforms.
There is no such thing as "best programming language". A programming language either fits your problem, making if comfortable to express your program with it, or it doesn't.
You can easily be given several choices that are all imperfect or suboptimal. But of those choices, there could very well be one that isn't as imperfect or suboptimal as the others are. This one can be considered the "best".
That's pretty much the situation here. Given that the major players in this arena are Java, Clojure and Scala, we often find Scala coming out ahead in most measures. In this context, it can be said to be "the best".
Given that the major players in this arena are Java, Clojure and Scala, we often find Scala coming out ahead in most measures.
The "we" in the above sentence refers to you and some other people that might have that sentiment, but not lots of other people.
Java (the language) is quite heavily used, but this is more a factor of it merely being around for years, and the huge amount of hype it received during its first decade of existence. However, it is now widely accepted that it is significantly deficient in many ways, which is part of the reason that people are seriously looking to alternatives.
Clojure may be a major player within the context of modern Lisp-like languages, but beyond that it's extremely obscure, and it is not widely used at all. At least part of this obscurity is due to its syntax and semantics. Time and time again we've seen this approach rejected by the software development community as a whole, regardless of whether we're talking about Lisp, Scheme, Common Lisp, and now Clojure. It's just not what people want.
So Scala ends up being the one with the fewest drawbacks, and the most positive aspects. It has a far more familiar syntax and semantics, it is seeing actual real-world use, and it does have features and functionality that attract people toward using it. From an objective viewpoint, it is the best of the given options.
I probably prefer Clojure slightly, but Scala-bashers are missing the fact that, for what Scala is trying to do, it does it extraordinarily well. Now, I don't like object-oriented programming at all so I question the utility of that aspect of JVM support-- Clojure's doing a much better job of making that stuff the weird-looking clunky part-- but Scala does a damn good job with what history handed it.
All kidding aside, one- or two-word comments are quite uninformative. Just because the original article with its "Scala is not a well-designed language" statement doesn't bother backing up bold claims with arguments, we should not fall into the same trap here on HN.
It's worth talking about Clojure as an alternative to Scala. They're both targetting the JVM, and they're both still on their way out of a niche. But just throwing out the name of an alternative programming language doesn't make a useful comment yet, nor does the "too succinct" reply.
It's probably more accurate to think of each as alternatives to Java. Why the distinction? Frankly, the two seem almost diametrically opposed to each other in their approach to things. The properties of one that might attract a user seem almost totally absent in the other. At the highest level Clojure's approach seems to prioritize simplicity above all else (except perhaps pragmatism). Even a cursory glance at Scala's type system gives one the feeling that simplicity was not high on Martin's list of priorities. Scala's facilities for abstraction complect objects, types, and traits. Clojure prefers piecemeal abstraction (e.g. "polymorphism a la carte.") Even Clojure's reader macros, which are arguably one of the (relatively) more complex features of the language, are relatively simple compared to Scala's implicits. As Neal Ford said, Scala will probably end up winning the Java.next race because it "fetishizes complexity in exactly the way Java developers are used to." I don't think many users of either language view the other as a suitable "alternative."
For someone new to Clojure like me, the problem with Clojure is that it's so easy to overlook an existing function and spend a while implementing something which already exists, even in the core libraries.
I had a quick read to a Scala tutorial this weekend and what I remember the most is how ugly the syntax felt, even compared to other languages :-)
Think about it for a second. Take a step back. Look again. It's poetry.
A very concise comment, on a very concise language is followed by a "too concise" comment. It's beauty.