
The JVM situation - Rickasaurus
https://groups.google.com/forum/?fromgroups=#!topic/scala-functional/kvbaE6cAzqM
======
guard-of-terra
The JVM is extremelly useful after you consider that all other foundations for
higher gen languages are either:

\- 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 :(

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

~~~
guard-of-terra
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.

~~~
copx
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...](http://www.scala-
lang.org/api/current/index.html#scala.collection.Iterable)

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

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

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

~~~
Pxtl
They tried. Does nobody else remember Perl 6/ parrot?

------
octo_t
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/](https://github.com/ReadyTalk/avian/)

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

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

------
adamnemecek
"Scala is not a well-designed language" regardless of anyone's opinion, that's
a pretty ballsy thing to say on the scala DL :-).

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

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

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

------
peter_l_downs
Prolly the biggest advantage of the JVM in my opinion was pointed out by
"iv...@ivan.net.nz":

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

Solves so many headaches!

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

~~~
michaelsbradley
There's always Frege:

[https://github.com/Frege/frege](https://github.com/Frege/frege)

But it's definitely a work in progress.

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

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

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

------
srean
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/tutorial.fdoc)

[http://felix-
lang.org/share/src/web/nutut/intro/intro_index....](http://felix-
lang.org/share/src/web/nutut/intro/intro_index.fdoc)

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

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

~~~
srean
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

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

~~~
srean
> (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.

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

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

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

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

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

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

~~~
swah
I agree with you, but isn't the whole Hadoop suite based in Java? Also,
Twitter infrastructure (Finagle etc)...

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

------
Pxtl
Come to the dark side. C# has been awsome since about 3.5

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

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

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

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

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

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

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

------
brucefancher
Clojure.

~~~
clubhi
Too succinct.

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

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

~~~
kleiba
Yeah, I got that and appreciated it, but at the same time it's not "poetry
news", you know ;-)

~~~
rbanffy
All hackers are poets. We write executable poetry.

~~~
kleiba
Then I have certainly seen some Dadaist code in my day.

