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

Scala Native

github.com

Post reply on HN
Print view View original

131–140 of 265 posts

Re: Scala Native

#131

Post by densh »

openasocket wrote: post #13

Is this a "true" Scala? As in, if I write a Scala program that only uses the scala stdlib, will it run on both the JVM and Scala native with no modifications to the source? Or, is it more like "a Scala" in the same way you would say "a Lisp"? I think a lot of the design decisions for Scala were made so that Scala would work on the JVM and easily inter-op with Java. It might make more sense to modify the language slig…

The goal is to be as "true" as possible by default with extra flags to trade some exact semantic aspects for performance. E.g. overflow semantics, bounds checks, null safety etc.

Apart from the base language we'll also introduce some language/library extensions to make lower-level programming that is going to be limited Scala Native "dialect" of Scala. E.g. pointers, structs, stack allocation, extern objects etc.

Re: Scala Native

#132

Post by densh »

badlogic wrote: post #10
densh wrote: post #4

Hi all, I'm the author of the project and would gladly answer any questions.

How's the managed runtime implemented (GC, memory model, etc.)? How did you get rid of JVM and JRE class library dependencies of Scala? What's the debugging story? I'd be great if this kind of info found its way onto th website. Is this in any way related to vmkit? Excited about this, keep up the great work!

> How's the managed runtime implemented (GC, memory model, etc.)?

In a first release we're going to use Boehm GC. That's just a stepping stone, not a long-term strategy. Stay tuned for news on this front.

> How did you get rid of JVM and JRE class library dependencies of Scala?

We're reimplementing / porting from Apache Harmony all the things we need.

> What's the debugging story?

We're going to integrate with lldb.

> Is this in any way related to vmkit?

Not related in any way, apart from being based on LLVM.

Re: Scala Native

#133

Post by switchbak »

incepted wrote: post #108
up_and_up wrote: post #73

Earlier quoted context omitted.

Go is great if you dont mind writing 1000's of lines of boiler plate code one would expect to exist.

Be fair now, you don't need to write them, you just copy/paste them.

Not sure if you meant that in jest, but it made me shudder a little.

Re: Scala Native

#134

Post by incepted »

danellis wrote: post #121
incepted wrote: post #102

Earlier quoted context omitted.

Agreed. I see the statement "It's being developed at EPFL by one engineer" as a very high risk that once this student graduates or moves on to a different university, the project will be abandoned and die.

It's worth noting that there was an LLVM-backed Scala project that was abandoned and died, so I definitely hope this avoids the same fate.

There was also a Scala.net project that was abandoned and died.

That's very common for academic projects.

Re: Scala Native

#135

Post by airless_bar »

kbenson wrote: post #70
edko wrote: post #64

Earlier quoted context omitted.

You can also do s"$varOne$varTwo" and that concatenates two variables.

Yes, as an alternate syntax, interpolation works well to disambiguate your intent, which supports my point. It's really just a highly specialized form of a different operator, which says I work on strings, so anything I see that isn't a string coerce to a string . For example, in Perl $varOne . $varTwo Is entirely equivalent to "$varOne$varTwo" The question is why Scala chose to use + when it had other, non-ambiguous…

To be more familiar to Java developers.

There are some thoughts about migrating people away from + toward string interpolation. But automated conversion tools are required before this can happen.

Re: Scala Native

#136

Post by airless_bar »

densh wrote: post #131
openasocket wrote: post #13

Is this a "true" Scala? As in, if I write a Scala program that only uses the scala stdlib, will it run on both the JVM and Scala native with no modifications to the source? Or, is it more like "a Scala" in the same way you would say "a Lisp"? I think a lot of the design decisions for Scala were made so that Scala would work on the JVM and easily inter-op with Java. It might make more sense to modify the language slig…

The goal is to be as "true" as possible by default with extra flags to trade some exact semantic aspects for performance. E.g. overflow semantics, bounds checks, null safety etc. Apart from the base language we'll also introduce some language/library extensions to make lower-level programming that is going to be limited Scala Native "dialect" of Scala. E.g. pointers, structs, stack allocation, extern objects etc.

Is there a difference between @extern and @native?

I could have imagined that it would have been more compatible if Scala-JVM and Scala-Native used the same annotations (using JNI behind the scenes on the JVM).

Re: Scala Native

#137

Post by [deleted] »

densh wrote: post #131
openasocket wrote: post #13

Is this a "true" Scala? As in, if I write a Scala program that only uses the scala stdlib, will it run on both the JVM and Scala native with no modifications to the source? Or, is it more like "a Scala" in the same way you would say "a Lisp"? I think a lot of the design decisions for Scala were made so that Scala would work on the JVM and easily inter-op with Java. It might make more sense to modify the language slig…

The goal is to be as "true" as possible by default with extra flags to trade some exact semantic aspects for performance. E.g. overflow semantics, bounds checks, null safety etc. Apart from the base language we'll also introduce some language/library extensions to make lower-level programming that is going to be limited Scala Native "dialect" of Scala. E.g. pointers, structs, stack allocation, extern objects etc.

[deleted]

Re: Scala Native

#138

Post by densh »

shrugger wrote: post #26
densh wrote: post #4

Hi all, I'm the author of the project and would gladly answer any questions.

Is this actually affiliated with the facility that is behind Scala for JVM? I saw the banner of the university on the Scala Native site, is that for real? I have been so extraordinarily impressed with Scala, and with the contributions its made in the PLT field, I'm very excited for Scala Native to start picking up steam. Can we expect the same level of excellence from Scala Native as we've received from Scala for JVM…

I'm currently employed as research assistant at EPFL at Martin Odersky's lab and closely collaborate with Martin and Sébastien Doeraene (the author of Scala.js) on technical design and implementation of Scala Native.

Re: Scala Native

#139

Post by bad_user »

brianwawok wrote: post #75
airless_bar wrote: post #37

Earlier quoted context omitted.

> just like ScalaJS made you need entirely new Scala libraries that did not use reflection. Most Scala libraries never used reflection, so most of the ecosystem "just worked" on Scala.js. I think quite a few things in scala-native are there to show the possibilities of this platform, but in the mid- to long-term those improvements will be supported everywhere: - @struct and AnyVals: As soon as AnyVals can support mor…

> Most Scala libraries never used reflection, so most of the ecosystem "just worked" on Scala.js. Do you have personal experience with this? I do not have hard numbers, but for me - basically none of my stack worked. I had to find a new JSON parser. I had to find new validation for my form stuff. Etc. etc. It wasn't impossible, but it was a lot of work.

It's not because of reflection. Most Scala libraries are reflection free. Exceptions are Scala libraries wrapping Java ones, or Scala libraries that are doing Java serialization / deserialization, which many times depends on reflection. For example JSON parsing in Scala many times piggybacks on Jackson, THE Java library for JSON parsing. However there are JSON parsing libraries that are pure Scala and that do not require reflection like Jackson does.

But reflection isn't usually an issue for Scala as Scala code does most of the same tricks at compile-time. Scala libraries that have problems are those libraries dealing with multi-threading. Do you block threads anywhere, waiting for a Future, or on a CountDownLatch? Any await/notify anywhere? Sorry, that won't work on top of Scala.js. That doesn't mean that you can't work around it though and it does take effort on the part of library authors. My own library (sorry for the shameless plug :)) is completely cross-platform: https://monix.io

BTW, Scala.js is very new, but the whole ecosystem wants to support it, every major library is being ported if not ported already and everybody is talking about it ;-)

Re: Scala Native

#140

Post by airless_bar »

densh wrote: post #132
badlogic wrote: post #10

Earlier quoted context omitted.

How's the managed runtime implemented (GC, memory model, etc.)? How did you get rid of JVM and JRE class library dependencies of Scala? What's the debugging story? I'd be great if this kind of info found its way onto th website. Is this in any way related to vmkit? Excited about this, keep up the great work!

> How's the managed runtime implemented (GC, memory model, etc.)? In a first release we're going to use Boehm GC. That's just a stepping stone, not a long-term strategy. Stay tuned for news on this front. > How did you get rid of JVM and JRE class library dependencies of Scala? We're reimplementing / porting from Apache Harmony all the things we need. > What's the debugging story? We're going to integrate with lldb.…

> We're reimplementing / porting from Apache Harmony all the things we need.

Doesn't that create licensing issues? You already seem to have code from Harmony in the project, but the project's license is neither Apache nor does it mention it.

Additionally, won't that cause trouble with Oracle, considering the lawsuit against Google?

Post reply on HN