1. 4
  1.  

  2. 2

    Is there any real content? all i see is “coming soon” and an empty github org.

    1. 2

      This is mostly a useless advert, I dont get the point of putting so little info on the webpage.

      1. 1

        I’m skeptical about how valuable this will be. The JVM has a really good garbage collector and Scala leans on GC very heavily.

        1. 3

          My guess is that it will continue to be garbage collected, but instead of compiling to java byte code, it will compile to llvm IR.

          1. 2

            Sort of by definition, right?

            I think @kellogh’s post is that it’s unclear what the benefit of Scala compiling natively would be. Java has gone through this already with gcj and that hasn’t been a big success. .Net is trying it now too, though. IMO, I think compiling natively is only a real benefit if the language happens to have some semantics where native compilation is an advantage, I’m not sure that is true for any JVM-based language, the semantics are just really not flattering for a native architecture, IMO.

            1. 1

              I think the difference is that Scala devs are a bit more pragmatic and are willing to make some small concessions toward making things run better, see for example Scala.js: Multi-threading isn’t really supported in the browser, but the world hasn’t ended yet.

              As far as I know, all that crazy every-instance-has-an-associated-monitor won’t be supported for instance on Scala Native.

              If Scala.js can be used as guidance, another important difference is that these projects take their host platform seriously, it’s not like some half-assed “let’s pretend to be Java like in gcj’s case”.

              JavaScript is a first-class citizen in Scala.js, just as Java is a first-class citizen when using Scala. I think Scala Native will be the same with first-class interop with native libraries.