Live data from Hacker News

Scala Native

github.com

141–150 of 265 posts

Re: Scala Native

#141
post #4

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

How do you plan to deal with the large amount of metadata required for some stuff? Like the timezone database for calendars, the CLDR for formatting stuff, or various Unicode tables for handling case folding/comparions/etc.?

Will you be using native libraries/the data blobs installed on the host system? Or will you ship these things with each binary?

Re: Scala Native

#142
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…

> Q: How much of the collections library is covered with full support? Partial support? NYI w/ ETA?

Non-parallel collections should work in first developer preview (to be announced.) Parallel collections may took a few release to get working.

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

If you can compile and run C code with Clang on some platform, it's reasonable to expect Scala Native to be run there eventually as we're based on the the same underlying compiler toolchain. Currently we mostly aim at POSIX environments.

> Q: How does GC work? Is there a way to take more control over GC for Scala objects?

Boehm GC for now, but that's not our long-term strategy.

> Q: Is it possible to ‘link’ in external dependencies, i.e. Joda Time. How do I do this right now?

We can link with libraries via C ABI. Java libraries need to be ported over to Scala.

> Q: Does the compiler use a translation layer? If so, is it consistent with Java 7 or 8?

We strive to keep the same semantics as Scala/JVM.

Re: Scala Native

#143

Earlier quoted context omitted.

These are not minor releases.

By definition those are minor releases.

Scala's versioning scheme is publicized and well-understood. Are you trying to blame Scala for not adopting SemVer before SemVer even existed?

Very silly.

Re: Scala Native

#144
post #4

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

What are your mobile plans? :) I realize this is probably a ways off, but I've dreamed of being able to write core logic in a language like Scala & then using that code from ios & android. Will scala native generate some c-linkable files?

iOS/Android support is the most requested feature. Stay tuned for updates on that front.

Scala Native generates LLVM IR that can be compiled to C-linkable code but for now we focus on "one statically linked application at a time" use case.

Re: Scala Native

#145

Earlier quoted context omitted.

Sorry I've never used Scala macros, beginner's question: are Scala macros not completely compile time? Why would they use reflection? Is it just syntactic sugar for dynamic type inference? If they just use reflection during compilation: why would that not be compatible with whatever the runtime is? Shouldn't that be unaffected by runtime and purely depend on the compiler's support for reflect? Or am I looking at this…

Play uses it specifically for in it’s JSON module; you can define readers and writers that allow you to parse the structure of a JSON object. To avoid having to be very explicit, you can define a case class that directly mirrors the structure of that object. e.g. given some case class that looks like this: case class SomeObj(someInt: Int) you could do: val theObj = SomeObj((json \ “someInt”).as[Int]) or implicit val…

The tricks that Play JSON does don't need runtime reflection. Macros don't use runtime capabilities at all and all macros work in Scala.js. I'm actually surprised by claims of Play JSON needing the runtime reflection of "scala.reflect".

No, Play JSON doesn't work because it wraps Jackson, a Java library.

Re: Scala Native

#146
post #45
post #4

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

Do you see any possibilities to undo/mitigate JVM-specific design decision which handicap the language? For example could you not erase generics or would that cause too much problems incompatibilities?

That's a very interesting aspect that's also being explored in our lab under Dotty [1] project and it's Linker [2] subprojects. It's not a direct goal of Scala Native.

[1] https://github.com/lampepfl/dotty

[2] https://github.com/dotty-linker

Re: Scala Native

#147

Earlier quoted context omitted.

Why do you say low development overhead isn't one of them? Outside of the one-time cost you pay to learn the language (which is higher than Go and most languages), Scala makes it super easy to write correct code quickly. The developer workflow of incremental compile + REPL + unit tests is great.

Probably depends on the code base, but having worked with Scala for a few years, there are a lot of things that causes development overhead. First things that come to mind: slow compile times, there are usually several ways to do one thing and also docs/guides are inconsistent, overused operator overloading in libraries (almost have to learn new DSL syntax for some libs), and it is not always easy to comprehend code…

not bagging anything you're saying, but I found slow compile times more or less go away if I open an sbt and type ~ compile to have it auto compile on save

Re: Scala Native

#149
post #4

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

On what OS does it run right now?

Scala Native is currently being developed on Darwin/Intel/x64.

If you can compile and run C code with Clang on some platform, it's reasonable to expect Scala Native to be run there eventually as we're based on the the same underlying compiler toolchain. Currently we mostly aim at POSIX environments.

Post reply on HN