8 ms·
Hi all, I'm the author of the project and would gladly answer any questions.
by densh 10y ago
Hi all, I'm the author of the project and would gladly answer any questions.
- spriggan3 10y agoOn what OS does it run right now?
- grenoire 10y agoMentions using LLVM, so all OS should work. Not sure about the stdlib.
- jjnoakes 10y agoAll OSs which LLVM supports should work. Not quite "All OS".
- densh 10y agoScala 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.
- dsabanin 10y agoJust wanted to say thank you for your amazing work!
- badlogic 10y agoHow'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!
- more_original 10y agoLooks like it's currently using the Boehm–Demers–Weiser conservative garbage collector. In scala-native/rtlib/src/main/resources/rt.cpp it includes gc.h and allocates memory using GC_malloc, i.e. not in precise mode.
- airless_bar 10y agoOuch.
- amelius 10y agoThe garbage collector is typically the most difficult part of a language implementation, so I'm not surprised. On the other hand, a simple GC can be sufficient for many projects.
- broodbucket 10y agoThey can still replace it later once they're further along with the rest of the implementation. I doubt they'll keep it.
- densh 10y ago> 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.
- petecox 10y ago> We're reimplementing / porting from Apache Harmony all the things we need. Would GCJ be any use? They had native compilation over a decade ago. (Although developers moved on to IcedTea, iirc)
- 10y ago
- Negative1 10y agoThis 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).
- densh 10y ago> 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.
- Negative1 10y agoAh, so since Scala Native is not built on the JVM you can't just take a pre-existing Java library and make it interop. You need it to be real Scala. The only options then are to use a convertor or manually port the library from Java to Scala?
- shrugger 10y agoIs 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?
- sjrd 10y agoYes. Scala Native is developed at EPFL for real.
- patrickmclaren 10y agoWill Lightbend be supporting this project in any way? The reason I ask is that I see on GitHub that you are the only contributor so far. This project is quite a large commitment for a single person, I'm hesitant to play around with Scala Native without knowing more about future plans for support, milestones, etc. Having said that, this project looks awesome. Nice work so far!
- incepted 10y agoAgreed. 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.
- edko 10y agoCan you please post your slides from Scala Days? EDIT: Thank you! https://github.com/densh/talks/blob/517b20c30dd4aaf390785039cdd002f623eaa91e/2016-05-11-scala-goes-native.pdf https://github.com/densh/talks/blob/517b20c30dd4aaf390785039...
- codecamper 10y agoWhat 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?
- densh 10y agoiOS/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.
- pacala 10y agoFantastic work! * Any plans to strengthen the Scala core lib so one doesn't have to reach out to JVM for mundane tasks like I/O or threading? * Is there a simple way to use raw C / C++ libraries from Scala native? * Is there a http://search.maven.org/ http://search.maven.org/ equivalent?
- densh 10y ago1. That's our long-term goal, but don't expect that to happen overnight. 2. @extern objects are an easy way to call C code. There is no C++ interop at the moment. 3. Not yet.
- dtech 10y agoHeya, your project looks interesting I must say. I was curious, is this mainly a 1-man gig or do you have support from the existing community (e.g. Odersky). I heard some rumors that someone (you) was doing it as a graduation thesis under Odersky, is that true or complete bollocks?
- dtech 10y agoDo 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?
- whateveracct 10y agoIdiomatic Scala doesn't care at all about erased generics. With implicits and macros and libraries built upon them like shapeless, you can do everything you'd want to do with reified generics and more and it'll be done and statically checked at compile time instead of dynamically at run time.
- dtech 10y agoI know there are ways like typetags to work around it, but on the JVM this is never going to run without extra work: def erased[T](xs: List[T]) : String = { xs match { case ns : List[Int] =>"Natural numbers" case fs : List[Double] => "Floating point numbers" case _ : List[T] => "Something else" } } System.out.println(erased(List(1,2,3))) System.out.println(erased(List(1.0,2.0,3.0))) Which is purely because of a JVM runtime limitation. Will native scala behave identically to JVM scala in this case or will you be able to improve?
- bad_user 10y agoThe part that you're missing is that code like this in Scala is totally unnecessary and it never happens: case ns : List[Int] => Worst case scenario, you can always do the following and it would be more idiomatic, no type erasure standing in the way: val listInt = listAny.collect { case x:Int => x } val listDouble = listAny.collect { case x:Double => x } But even that is totally unnecessary. You know why? Because your function does not make sense. What could you possibly do with a function that takes a List[T] and returns a String? The only way this would make sense would be if you are talking about a List[Any] deserialized from somewhere (like some shitty JSON library). But then in Scala we don't really work with Any, that should never happen and if you see libraries that use Any in their API, drop them like they are hot ;-) > Which is purely because of a JVM runtime limitation No it's not. Talk to compiler authors. This is actually a freedom, because by introducing reified generics in the runtime, then language designers either have to deal with inefficiencies due to boxing because of extra conversions, or to limit their type system, so for example you can say goodbye to higher-kinded types. A runtime that has reified generics is not a multi-language runtime. In fact many languages are doing type erasure. Haskell is doing type erasure. And why shouldn't it, I mean, type casting and isInstanceOf checks make no sense in Haskell.
- steeleduncan 10y agoWhat are the plans with tail call optimisation in this version? or do you get that for free from LLVM?
- airless_bar 10y agoThe slides mention that proper tail calls "just work", even mutual ones. :-)
- densh 10y agoWe get that for free from LLVM.
- airless_bar 10y agoHow 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?
- sievebrain 10y agoHi, What is the rationale for doing this, given that the Graal / JVM guys are already developing an AOT compiler which can compile Scala to native binaries? Is this motivated by performance? The desire to write C libraries in Scala? What? Given the high level, dynamic nature of Scala I am skeptical LLVM+Boehm GC will result in faster code. I expect it would result in slower code. EDIT: OK, I just saw the link to your talk below. I feel you should know a few things: 1) The Hotspot team are adding AOT compilation to the JVM. There is a talk on it here. This mostly eliminates warmup time: https://www.youtube.com/watch?v=Xybzyv8qbOc&list=PLX8CzqL3ArzUo2dtMurvpUTAaujPMeuuU&index=16 https://www.youtube.com/watch?v=Xybzyv8qbOc&list=PLX8CzqL3Ar... You can't eliminate warmup time entirely because profile guided on-the-fly optimisation is actually quite powerful and an AOT compiler that doesn't have profile data to work with can't generate code that's as good. But they support tiered AOT, where the AOT compiled code does basic profiling of itself, and then it can still trigger profile-guided JIT compilation if you want to. 2) Interop with native is being heavily worked on in project Panama: another JVM upgrade project. With the current prototype you can feed it arbitrary header files that are parsed with clang, and it generates Java interfacing files that are efficiently compiled (no overhead). There's a Pointer<T> type and so on. 3) Stack allocation isn't so easy to do unless you are willing to pretty wildly violate the safety of the language. It's also been found to not help much when very adventurous JVM implementors tried it anyway (Azul), because a good generational GC makes short lived allocations so cheap. Valhalla is doing value types on the JVM but that's about more than just stack allocation. 4) You can do manual memory management on the JVM already, via the Unsafe class. I'm sure a Scala DSL would make it have a more convenient syntax. 5) Java 9 will have a static linker equivalent that generates stripped, standalone, optimised application packages that don't depend on any separate JVM. The AOT compiler will be a plugin to this static linker. So I don't mean to discourage you if this is a fun research project, but you should be aware that the daydream is not one that the actual Java team are ignoring for mysterious reasons. They're working on it too, and are better funded and taking a more general and compatible approach. By the time you have a tool that's usefully complete it'll take years and by then there might not be much difference between the approaches.
- airless_bar 10y agoWhat Oracle does is cute, but I will put my bet on people who have a solid track record at shipping.