Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scala Native v0.1

scala-lang.org

Post reply on HN
Print view View original

121–130 of 254 posts

Re: Scala Native v0.1

#121

Post by pjmlp »

sreque wrote: post #27
wst_ wrote: post #8

Somewhat relevant: https://blog.plan99.net/kotlin-native-310ffac94af2#.ijzik0jx... Title says Kotlin, but it is about JVM languages going native, in general. Or should they?

They should. The article basically throws in some FUD to convince people that they don't want what they think they want. Except, we do want it! The JVM ecosystem's general aversion to native code and native system integration is what gave C# the opportunity to take over as the closest thing we have to a WORA language. If I want to write code in a higher-level language than C++ that can run on any mobile device or des…

The JVM eco-system is full of options to compile Java into native code.

The only thing is that most ignore there is a JVM world outside OpenJDK.

And even those that know that world aren't willing to pay for commercial JVMs.

Thus propagating the myth that Java doesn't support AOT.

Which in a way is also understandable, given Sun's political decision that AOT compilation was tabu.

Luckily Oracle isn't Sun and has heard the industry. So if all goes as planned, by Java 10, those that don't want to pay for AOT compilers, will have one in OpenJDK.

Re: Scala Native v0.1

#123

Post by sjrd »

edko wrote: post #119
sjrd wrote: post #103

Earlier quoted context omitted.

Absolutely! I'm just pointing out that this need is so strong that people have reached for the slow throughput of Scala.js just to get its fast startup time. If we can have both, that's even better!

No intention of arguing with Scala.js' creator :-) But, I do not think it has a "slow throughput" at all. In my experience, it's had pretty good performance.

Oh it does have pretty good performance, on par with hand-written JavaScript. But that's still 3x slower than Scala/JVM on our benchmarks, and those benchmarks are ported from the Octane benchmark suite used by V8 (so supposedly that's where V8 shines).

Everything is relative. Scala.js remains significantly slower than Scala/JVM in terms of throughput.

Re: Scala Native v0.1

#124

Post by lmm »

cwyers wrote: post #29

It seems to me like Scala's biggest benefit and biggest downside are two sides of the same coin: easy interop with the JVM and Java code. Scala Native just seems like you're paying all the price of that for none of the benefit.

Even if you're not using Java code, it's still the best language going IMO.

What are the alternatives? I couldn't live without HKT these days (once you're used to thinking in them it's painful to work without them), which rules out most languages even in the ML space, and Scala has better IDE support than anything that's left (indeed an excellent tool ecosystem in general in terms of e.g. profilers, instrumentation) except possibly Ceylon (which doesn't have anything like the library/developer ecosystem of Scala). Even assuming Ocaml lands their modular implicits functionality doesn't change this as far as I can see.

Haskell is an option, but eager evaluation makes reasoning about performance much easier. (And I do think there are legitimate use cases for traditional OO inheritance, though this is debatable). If and when Idris reaches a similar level of library/tool support to Scala then it might become a better alternative to Scala Native, but not that many people are willing to use Idris in production yet.

Re: Scala Native v0.1

#125

Post by Recurecur »

wtetzner wrote: post #95
Recurecur wrote: post #75

Earlier quoted context omitted.

In general (not for server apps), two major benefits of Scala Native are: - Predictable latency if desired (optional GC) - Very low call overhead for C ABI As to your point about memory use, Java trades memory for convenience, not performance. GC requires substantially more memory for similar performance. I read an IBM blog (which I can't find at the moment) within the last week which showed a Swift web service runni…

> Predictable latency if desired (optional GC) Does Scala Native support not using a GC? It seems like it would be difficult to get Scala working without a GC.

It supports direct allocation via both the heap and the stack.

  type Vec = CStruct3[Double, Double, Double]

  val vec = stackalloc[Vec] // allocate c struct on stack
  !vec._1 = 10.0            // initialize fields
  !vec._2 = 20.0
  !vec._3 = 30.0
  length(vec)               // pass by reference
...and...

  @extern object stdlib {
    def malloc(size: CSize): Ptr[Byte] = extern
  }

  val ptr = stdlib.malloc(32)
http://www.scala-native.org/en/latest/

Otherwise it currently uses the Boehm GC.

One big area that needs more work:

  "Scala Native doesn’t yet provide libraries for parallel
   multi-threaded programming and assumes single-threaded    
   execution by default."

Re: Scala Native v0.1

#126

Post by mickronome »

algesten wrote: post #63
therealmarv wrote: post #5

Earlier quoted context omitted.

Never touch a running system ;) Scala on JVM is much more tested than the new shiny thing. Also don't expect improved performance... many people think that the JVM is bloated and makes programs slower (this is mostly not true). The downsides of the JVM are more memory consumption/footprint (when you have e.g. small servers or micro instances) and the cold startup time of the JVM itself (which is not relevant on a ser…

> the cold startup time of the JVM itself (which is not relevant on a server in comparison to desktop Java apps). I disagree somewhat with this. We found that when we started writing microservices in languages that are not java, the short startup time changed how we did some error handling. For errors where we say lose connection to the database, or rabbitmq, we much rather have the nodejs-process die and restart, th…

The most effective way to handle these kind of errors in Java unfortunately requires understanding class loading, thread contexts, wrapping connection primitives in the right kind of references, and then making sure that all resource deallocation/closing always use the same codepath. Even though you really only need to implemnt it once, it is both somewhat tricky and technically challenging.

It's a pity that so few Java projects have tried to use these mechanisms without building them as part of massive frameworks, sometimes apparently even without understanding what they have built.

Re: Scala Native v0.1

#127

Post by lmm »

huula wrote: post #40

Question: what kind of frameworks can be practically migrated to Scala Native?

In Scala it's very normal to write libraries or frameworks in "pure" Scala (i.e. not using reflection, annotations, proxies or anything like that), and all of those should be fine to cross-build for Scala Native (assuming their upstream dependencies do first). The state of libraries for Scala.js should be a good indication - anything that's cross-compatible with that is likely to work just as well for Scala Native.

Re: Scala Native v0.1

#129

Post by Recurecur »

usrusr wrote: post #64
dualogy wrote: post #36

Earlier quoted context omitted.

> but it's not of much value if an "echo" or "grep" implementation takes up 15 to 30MB on the drive In this day & age? It might be of value if an echo or grep takes ~20MB and a full-blown HTTP REST server with DB access takes ~25-30MB. Why do I care again exactly whether there is a fixed portion of bootstrap/runtime core code in the binary, as long as I'm not writing echo or grep? (Any helloworld app not written in a…

When you are writing that full-blown HTTP REST server with DB access you would probably be served better on the JVM. Scala native is just as garbage collected as Scala JVM and garbage collection is where the JVM shines brightly. In my eyes, the main value proposition of Scala native will be "you don't have to learn a new language if you need to write an echo or a grep", with "you don't need to learn a new language if…

A major value proposition is also "I want to run my code with predictable latency". This opens Scala to embedded and realtime development.

The LLVM AOT optimizations are also likely to be a lot stronger than JVM JIT optimizations - granted it's good to compile on the exact target architecture. Also granted that sometimes dynamic optimization helps a lot.

Nice handle BTW. lol

Re: Scala Native v0.1

#130

Post by bnjmn »

densh wrote: post #28
mafribe wrote: post #24

Nice work, I hope this will eventually be a serious alternative to the JVM route. Quick question: does this compile down to DOT before going to LLVM? Or has DOT not yet arrived in Scala Native?

DOT [1] is a theoretical calculus that is used as a foundation for our latest front-end compiler called dotty [2]. Scala Native is mostly a middle-end technology that bridges front-end compiler and LLVM. We plan to support dotty as a front-end in the future. 0.1 release is based on older Scala 2.11 front-end. [1] http://www.scala-lang.org/blog/2016/02/03/essence-of-scala.h... [2] https://github.com/lampepfl/dotty

Just what I hoped to hear, thanks!
Post reply on HN