The JVM situation(groups.google.com)
groups.google.com
The JVM situation
https://groups.google.com/forum/?fromgroups=#!topic/scala-functional/kvbaE6cAzqM
102 comments
Rust is the anti-JVM.
- 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.
- 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.
I personally am really excited by Rust, but it's also still a fairly fast-moving target. Lots of work is still being done on the semantics of the language.
It's an industrial research project, basically. When the semantics stabilise I reckon it'll be a technical winner in its chosen domain.
It's an industrial research project, basically. When the semantics stabilise I reckon it'll be a technical winner in its chosen domain.
Yes, certainly -- it's annoying to be working on some code, then update to a day-newer compiler and suddenly have a screen full of errors (as is currently the case).
But in the long run, it'll be worth it, and I have no doubt that Rust will become an amazing language worth using.
But in the long run, it'll be worth it, and I have no doubt that Rust will become an amazing language worth using.
And now you can browse Wikipedia in Servo (which is written in Rust): https://twitter.com/metajack/status/346822553089761281/photo...
Servo is a good idea because it helps show the pain points of Rust on a real world project. But it doesn't show that Rust is ready for general use yet because that's really what it is -- another facet of the Rust project.
True. It is nice; however, to see a big project being developed side-by-side with the language.
Absolutely. The obvious historical parallel is the co-evolution of Unix and C.
I wouldn't say all other foundations for higher-order languages -- F# runs fantastically on the CLR (or Mono) and doesn't have any of those problems you listed.
I would rather say that the mentioned problems are typical of languages that use their own VM instead of basing on an established platform like JVM or CLR.
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?
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?
Well, one of the things that hurts Scala on the JVM is the lack of tail call elimination, which the CLR supports. Reified generics and value types are probably also significant improvements.
F# and the CLR aren't proprietary?
Microsoft has open sourced F# http://fsharp.org/ and the fsharp.org community is very proactive. As for the CLR, it is an ECMA and ISO standard http://en.wikipedia.org/wiki/Common_Language_Infrastructure
F# is licensed under Apache 2.0: https://github.com/fsharp/fsharp/blob/master/LICENSE
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.
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.
Mono isn't proprietary.
In my experience Mono is a bit like the OpenJDK was a few years ago:
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.
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.
I feel like Xamarin is in the uncanny valley of language / tooling features. Close enough to working to make the brokenness feel so much worse. If it was more raw, less IDE friendly (ala Go) that would be fine... or was more polished and had a better Xamarin IDE and plugin system, that would be fine as well.
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.
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.
Yes, but it can be a patent trap:
https://www.fsf.org/news/2009-07-mscp-mono,
https://en.wikipedia.org/wiki/Mono_%28software%29#Mono_and_M...
This patent trap commentary is 4 years old. I don't think this is on anyone's radar anymore. Otherwise Xamarin would not even exist.
People should be investing time in Scala (compiler and tooling, e.g. IDE support) instead of designing their own language that probably won't get a lot of traction.
I'm not sold on Scala and my colleagues aren't either.
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.
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.
Actually C++ looks simple compared to Scala. E.g. C++ iterators seem complex and tricky compared to say Lua's.
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.
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.
To be fair, this is a list of everything inherited, not just one level up, but the full transitive closure. All of the Gen* classes arrived with 2.9 when parallel collections were added.
Also, the implicits shown are any implicits which can be invoked on Iterable, which includes all implicits which can be invoked on Any.
Also, the implicits shown are any implicits which can be invoked on Iterable, which includes all implicits which can be invoked on Any.
Am I supposed to be intimidated by a list of 100 things you can do with an Iterable? Each one seems pretty reasonable. The C++ stdlib has 100 things you can do with iterators, too.
Scala is one of the best languages out there if your job is to write code. If you spend a non-trivial amount of time reading it, it depends on which of the sublanguages the original writers used.
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.
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.
What happens is that every single bit of functionality is split up and abstracted away, so that code duplication is kept at a minimum.
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.
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.
To be honest, neither am I. I've done small projects in Scala (+libraries) and the amount of clever small features makes for short (maybe sometimes even elegant) code, but readability is a nightmare.
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.
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.
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.
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.
Been there and done that. However, designing languages to push the state of affairs forward is more my cup of tea (working on Scala helped with a lot of ideas though).
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.
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.
There are really several layers of issues to deal with in regards to the JVM.
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.
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.
They tried. Does nobody else remember Perl 6/ parrot?
Simon Ochsenreither has been investing a fair amount of resources into Avian[1], an alternative JVM with support for tailcalls and various other useful toys.
I think this is possibly where languages like Scala may lead, potentially forking a JVM and refitting it to their own needs.
[1] - https://github.com/ReadyTalk/avian/
I think this is possibly where languages like Scala may lead, potentially forking a JVM and refitting it to their own needs.
[1] - https://github.com/ReadyTalk/avian/
Avian is a very impressive piece of work. I'm not sure i'll ever switch to it, but hopefully, its very existence will drive the OpenJDK to improve itself to compete (eg adding tail call optimisation). A bit like how Scala forced Java's hand in adding lambdas.
Interesting, it'd be good to have community-drive alternative to the JVM, like some kind of a Postgres of VMs. Also tail calls are what people complain about with Clojure on the JVM, so this would address that problem.
When I'm done with my current project, my plan is to make the heap 64-bit on 64-bit machines (which was currently an issue last I checked).
By "to the JVM", you mean "to the Oracle JDK".
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.
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.
"Scala is not a well-designed language"
regardless of anyone's opinion, that's a pretty ballsy thing to say on the scala DL :-).
Let's just say that Tony Morris doesn't mince words on the Scala MLs.....
I think its recognised, even by people like Odersky, that the language has been significantly compromised by the decision to run on the JVM.
It is an incredibly well-designed language, but lots of that effort has gone into covering up some really nasty warts.
It is an incredibly well-designed language, but lots of that effort has gone into covering up some really nasty warts.
I'd be interested to hear some examples of how the decision to run on the JVM has skewed the design of Scala. (Plus whether/how the same is true of Clojure.)
Here i am thinking it's the best language I've ever written in :-) I guess that's not really incompatible with still being "not a well designed language." When we're comparing ourselves to platonic ideals I guess the real thing can only pale in comparison. I just don't perceive the compromises.
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
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
Scala is a great language to write in. It's also good because you can learn a lot about the JVM (that you wouldn't learn as easily in Clojure, because the JVM interop of Clojure is less mature and far less intuitive) but also about strong, static typing in a system almost as badass as Haskell's.
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.
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.
And not only is it 5 lines to 1 line, the remaining 1 line is basically just underscores!
I absolutely agree (although for smaller projects I enjoy Haskell more).
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.
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.
They would never get it out of the door if it wasn't based on the JVM. The reason is Haskell. JVM mandates certain imperative tools in the Scala language; if you subtract these, you end up with Haskell, and Haskell is big enough that you'll have hard time reinventing it.
Members of the Scala community are generally quite mature, and this reflects in their attitude and response when it comes to legitimate criticism of Scala.
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.
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's pretty simple really, and far from unique to programming (let alone to the Ruby and JS communities in particular): all communities tend to take criticism from insiders in good faith, and tend to take criticism from outsiders more personally. It is obvious from reading the thread that Tony Morris is "inside" the Scala community, both due to his demonstrated depth of knowledge and to the deference and consideration given to his question. You have to earn the ability to say "Scala is not well-designed" on a Scala list. If somebody showed up and started a thread saying, "I just discovered Scala and it is immediately clear to me that it is poorly designed", it would turn out very differently.
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.
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.
why does one need to be "inside" the community and have gained reputation before making valid criticism?
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.
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.
I actually didn't say that one needs to be "inside" a community to criticize it, merely that all human communities tend to respond differently to criticism from within than from without. (For instance, Seinfeld's dentist Tim Wotley converting to Judaism "for the jokes".)
> They react with hostility and denial when they encounter legitimate criticism.
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.
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.
> 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.
To be fair, there's a huge difference between complaining about an implementation and complaining about the design of a language.
To be fair, there's a huge difference between complaining about an implementation and complaining about the design of a language.
> Citation needed, Rubyists in particular have been whining (and rightfully so) about MRI's poor concurrency support for the past year or two.
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.
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.
> This does differ from how members of the the Ruby and JavaScript communities take criticism of those languages, for example.
Don't forget Go. :)
Don't forget Go. :)
Prolly the biggest advantage of the JVM in my opinion was pointed out by "[email protected]":
> 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.
Yes, and for how good Haskell is as a LANGUAGE, it sucks at this very important feature (assuming you want to use a 3rd party library).
There's always Frege:
https://github.com/Frege/frege
But it's definitely a work in progress.
https://github.com/Frege/frege
But it's definitely a work in progress.
Yes, I agree that uberjars are a great thing when it comes to the JVM ecosystem. However, with the advent of projects like docker, I can't help but think that this reasoning is now obsolete. You can write your app in Go, Rust or Haskell and deploy it inside a container that you provide. You control the environment that it runs in.
Sun used to use the catchy slogan "write once, run anywhere" to refer to this property...
While it's not the same thing, 'go' can compile for multiple platforms, and then you can deploy appropriate binaries on another OS as long as 'go' is installed.
> and then you can deploy appropriate binaries on another OS as long as 'go' is installed.
Nope. Go does not need to be installed for a binary produced by the `gc` compiler to run.
Nope. Go does not need to be installed for a binary produced by the `gc` compiler to run.
It's fun to hate on Java (cause who here hasn't hit stupidity with Java?), but the fact is that Java does a lot right.
There are two types of languages, the languages people hate and the languages no one uses.
There are two types of languages, the languages people hate and the languages no one uses.
There is a third type of language: languages that people hate so much that no one uses them anymore.
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.
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.
With any luck, all the languages we know today will get there too one day, as they are rendered obsolete by further decades of experience with programming languages.
Well, except LISP, obviously.
Well, except LISP, obviously.
People here might like to take Felix for a spin.
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++.
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++.
What's wrong with it, then? Such a language would need:
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.
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.
It scores extremely, extremely well on 2.
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
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
Coroutines are nice, but don't provide concurrency (by which I mean simultaneous computation on >1 cpu - sorry if I got my terminology crossed up).
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.
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.
> (by which I mean simultaneous computation on >1 cpu - sorry > if I got my terminology crossed up).
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.
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.
I think you have to start with your target platform. If you want to run in the browser it has compile to JavaScript. That has consequences. If you're targeting mobile phones it has to generate Android or iOS code, preferably both. On the server there are many more choices; targeting LLVM might be a good bet.
Language design is important, but being a good fit for the platform is more important.
Language design is important, but being a good fit for the platform is more important.
So what are my real options for avoiding the JVM on new projects? Go? I'm not into functional save a bit if Scala. But not willing to invest time in something like Haskell.
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.
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.
Without even a hint of what you want to do with your "new projects", that's not possible to answer. Python is a sensible answer for many cases, for instance. Go is pretty plausible for some projects but would immensely weak for others (for its age, it has great library support, but it is still a young language), etc. C++? D? Ocaml? C#, perhaps on Mono? How exotic are you looking to be? In the rich, diverse world of programming languages, the JVM is merely one participant. It's large, but I do not think everything else merely lives in its shadow or anything, it is not that dominant. Not even close, really. (C++ may once have stood atop the world, but nothing else has quite pulled that off since.)
C and C++ are still the dominant languages, by far. They're still actively "standing atop the world".
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.
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.
You underestimate the impact mobile software development has had on language utilization: http://lang-index.sourceforge.net/
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.
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.
JRuby has for a long time been a usable, production grade Ruby, and, while CRuby has made big strides in recent version, is still ahead in many ways (including threading, due directly to the JVM.)
(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++.
(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++.
In my opinion, the Java ecosystem has grown to the point where C++ is no longer "the undisputed master". It is, at least, in dispute. TIOBE isn't perfect, but if C++ were still the undisputed master, Java would not handily out-score it, for instance. (If your response is to start expanding on the imperfections of TIOBE, stop and reread that sentence a few more times, carefully. Exactly what my if-then says, and what it doesn't say, are important to my point.)
I think if what you're suggesting were true, then we'd see Java being used for far more "foundation" software, as well as for higher-level software. It would be difficult, if not impossible, to avoid using at least some Java-based software at nearly all times. This isn't what we see, though.
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.
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 agree with you, but isn't the whole Hadoop suite based in Java? Also, Twitter infrastructure (Finagle etc)...
I think it's easy to feel overwhelmed but you probably can scale up with Python with little effort with PyPy (time ago you could do that with Psyco) or change your processing to something based on Twisted.
Have you checked out Rust?
While there's plenty to disagree with, it pains me to see such rich fodder for an interesting discussion on the design, implementation, and adoption of programming languages languish on the second page of HN while the first page still has a dozen NSA stories.
Come to the dark side. C# has been awsome since about 3.5
If they're going to switch from the JVM to the CLR, they might as well switch to F#; in fact, I'll even argue it'd be easier for them to switch to F#, since they'll be able to continue using many of the functional programming concepts and abstractions they've already learned in Scala.
For a multiparadigm langauge, C# 3.5 and up offer some solid functional programming stuff. Obviously if you want to go hardcore into FP you can find it in F#, but if you just want to do lots of awesome things with lambdas using otherwise-conventional OOP, C# is surprisingly well-equipped.
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.
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.
While C# runs on platforms other than Windows, those platforms have such incredibly rich programming ecosystems one has to wonder why would anyone program in C# for them when there are hundreds of languages more appropriate to the specific problem.
Hundreds of languages? I don't know, Xamarin's tools seem to indicate that there's a real demand for using C# on a variety of platforms. While not my personal preference, C# is really a wonderfully well-designed language.
I don't think C# is even remotely able to compete in this battle. :-)
Seriously, I stopped reading on "1) Scala is the best available programming language for the JVM."
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.
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.
"Best" doesn't necessarily mean "perfect" or "optimal".
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".
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".
I think the OP was referring to the fact that "best" is subjective. Obviously many, many others don't think that Scala is the "best" programming language on the JVM.
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.
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.
This isn't about my opinion or preferences. This is about looking at the reality of the situation.
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.
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.
Not only that, but claiming Scala is the best programming language for the JVM is like claiming Vala is the best programming language for Gnome. It's childish.
I'm sorry, but I think calling Scala "not well designed" is a bit off the mark and smells of flame-bait. Relative to the extremely hard problem of putting a Hindley-Milner type system on top of the JVM, I think it's extremely well-designed.
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.
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.
Clojure.
Too succinct.
The comment or the language?
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.
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 worth talking about Clojure as an alternative to Scala.
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."
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."
I think Clojure has a clear advantage here: newcomers always complain about the parens and after an initial time frame we all get it and it becomes a non-issue and as you progress, there is no baroque design, it just composes over itself.
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 :-)
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 :-)
> The comment or the language?
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.
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.
clojure and scala aren't really in competition, in the same way python and java aren't.
- 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 :(