Live data from Hacker News

Scala Native

github.com

11–20 of 265 posts

Re: Scala Native

#11
post #4

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

This is exciting but I've been burned in the past. Your commit graph seems to show you're serious so I hope you stick with it.

Will probably have more questions after I browse through the code but some basics: Q: How much of the collections library is covered with full support? Partial support? NYI w/ ETA? Q: Cross-platform support? If I wanted to run this on iOS and Android today, what do I have to do? What about on Windows or OSX? Q: How does GC work? Is there a way to take more control over GC for Scala objects? Q: Is it possible to ‘link’ in external dependencies, i.e. Joda Time. How do I do this right now? Q: Does the compiler use a translation layer? If so, is it consistent with Java 7 or 8?

On another note, the c extern stuff is excellent — exactly what I’d like to see for portability and performance (without the headache of something like the JNI).

Re: Scala Native

#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 slightly to better suit the native environment. I'm seeing some hints to that on the page with the "@struct" and "@extern" decorators.

Re: Scala Native

#14

Just saw this on twitter. Scala, you have my attention. There were a lot of talks about "the tools of yesterday" and "the tools of the future" lately. Scala getting closer to the metal, without the JVM is a significant step toward "the tools of the future".

I would argue scala' main selling point is making the jvm palatable to people who hate Java. However, it's entirely unclear without the jvm why I would choose it over, say, rust, Haskell, go, c++, etc.

Re: Scala Native

#15

Otherwise known as "Haskell"?

Much to the Scalaz crowd's dismay, Scala always was an ML first and foremost. Any similarity to Haskell is incidental to Haskell/ML's shared background in strongly typed functional programming.

Re: Scala Native

#16
post #14

Just saw this on twitter. Scala, you have my attention. There were a lot of talks about "the tools of yesterday" and "the tools of the future" lately. Scala getting closer to the metal, without the JVM is a significant step toward "the tools of the future".

I would argue scala' main selling point is making the jvm palatable to people who hate Java. However, it's entirely unclear without the jvm why I would choose it over, say, rust, Haskell, go, c++, etc.

That is a very narrow view of Scala. It's a great and powerful language.

Re: Scala Native

#18

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…

Clearly they added a bunch of new stuff that the JVM can't understand.

So it is either "Scala like LISP"

or

It is a superset of the Scala language. Meaning all existing stuff will work with it, but if you use new secret keywords it will work "better".

Which seems not quite ideal, because that means most Scala libraries will not be "tuned", and you will need all new libraries.. just like ScalaJS made you need entirely new Scala libraries that did not use reflection.

Worried the Scala ecosystem is turning into a nightmare ;)

Re: Scala Native

#20

Otherwise known as "Haskell"?

Much to the Scalaz crowd's dismay, Scala always was an ML first and foremost. Any similarity to Haskell is incidental to Haskell/ML's shared background in strongly typed functional programming.

Incidental? It's pretty well known that Scala was heavily influenced by Haskell. In particular, do notation (for comprehensions), pattern matching, lots of standard lib classes (ex Maybe (Option)), many of the methods in the collections library (map, fold, take, etc)

Anyway, I wasn't trying to disparage either of them (or this project). Just poking fun at the seemingly common "I want to use Haskell but I'm forced to deploy on the JVM" use case for Scala.

Post reply on HN