Small update: JUnit support was merged into Scala Native master.
This will be important for anyone wanting to port a library, which already has JUnit-based tests, to Scala Native.
It will also be a productivity boost for contributing to Scala Native itself, since we can now e.g. port features from Scala.js using the exact same tests, without adaptation.
The implementation was ported verbatim from Scala.js, with some adaptations for Scala Native, so the same features and limitations apply.
I think Martin’s idea of targeting the Python ecosystem, if possible, would be an amazing game-changer. That would be why you use Scala-Native.
I have yet to hear any other reason that would be very compelling. Huge complex programs that really benefit from Scala’s abstraction capabilities tend to tolerate JVM startup latencies pretty well. If it’s simple enough to run in 0.2s, almost all the time you can get it done just fine in Go or somesuch.
“I already know Scala and don’t want to learn another language” also isn’t all that compelling unless Scala can actually solve problems in that domain better than the other language, or cross-compiling Scala libraries is really easy (which isn’t entirely true so far).
“I want it as fast as possible” almost always will end in “so use Rust or C++”, because they routinely beat all sorts of other languages that are native but use GC. Furthermore, Rust gives you tools to get a lot of speed safely. It’s very hard to compete with Rust here.
But easy access to Python libraries would change everything. Python’s two secret weapons are: starting out, the syntax is really easy; and it has amazing libraries for everything. I don’t know if it’s possible–and I don’t know how Swift has been doing–but I would really like to live in a world where it is possible and has already happened.
This project is getting a touch stale but I believe this perhaps a way to bridge the gap to Python. https://github.com/shadaj/scalapy According to this, it looks like the plans were to support Scala Native as well - in master?. https://github.com/shadaj/scalapy/blob/master/CHANGELOG.md
I am bullish about Scala Native especially if we can get from 0.4.0-M2 to M3 and get Scala 2.12/2.13 support going. Denys did a fabulous job of getting close to JVM speeds in his tests using Commix, the concurrent Immix GC. Commix needs a M3 release. Getting the Scala Center on board is big but we also need community support.
Having JUnit support (Thanks @ergys) means that Scala Native can test Java libs against JVM and Native. Also, all downstream Scala libraries can use the same tests for all three platforms, JVM, Scala.js and Native which is great for cross compiling.
Scala Native using clang and LLVM like Swift, Objective C and a host of other languages allows it to potentially support different processors and platforms that even the JVM doesn’t support. One big benefit is that java.lang.Object doesn’t have the memory overhead it does on the JVM.
Yes, Scala Native needs some work but I think it has a bright future but it also needs people to try it out and get involved. It took Scala a long time and lots of people and work to get where it is today. Scala.js also took quite a while to get really good. The power of Scala Native is the Scala language we love where we have complete control over the future.
Hi All,
I just want to report that I got Scala Native working on Raspberry Pi using Ubuntu 64bit OS. This is the released 0.4.0-M2 version. Since this is an ARM processor and the OS supports Java, I was able to just compile directly on the Raspberry Pi. Certainly this processor has lots of horsepower and memory but just compiling based on the platform LLVM target triple works out of the box. I didn’t do any extensive study, just “hello world”, so some of the platform could have ARM processor problems - not super likely but just want to mention.
More details in the tweet and responses.
Cheers!
Wow that’s amazing. I will try and see if something similar is possible for an even smaller instruction set (like 30-40 instructions in AVR microcontrollers)
After the first Scala Native release under the Scala Center’s care, it’s time to check the progress of our goals and step in the new cycle of planning.
Our major goal in this category was supporting Scala 2.12 and 2.13. It was fully accomplished with complete support for their latest releases - 2.12.13 and 2.13.4.
The effort investment in building solid foundations for reflection support enabled us to provide a more robust testing interface. For both of them Scala Native and Scala.js now share a standardized API. We believe it will help developers to cross-publish for both platforms.
Scala Native is now providing native runtime for the JUnit testing framework. It can be used by users to integrate with their existing JVM test-bases as well as to cross-test between the 3 execution platforms: JVM, Scala Native, and Scala.js. This also improved our quality assurance - we can now reuse the rich test-base defined in Scala.js, and in the future, we will be able to run tests against the JVM implementations to provide the highest possible compliance in our Java standard library implementation.
The Scala Center committed to improve and enhance Native interoperability and some steps have been taken in fulfilling this goal. We have improved interop for C function pointers - they can now be created via implicit conversion from ordinary scala.Function, as well as created from / cast to arbitrary pointer type. Also, the type-safety of some native methods was improved. We are currently working on other interop features that might be introduced in future releases, e.g.: easier definition of fixed-size arrays and structural types, or linking Scala code as native libraries.
With recent support for Scala 2.12 and 2.13, we’re keeping up with support for the latest Scala 2 releases. We also realize the need for the future support of Scala 3 andwe are going to provide it as soon as other more urgent issues will be addressed and polished. Among these we can mention support for multithreading, compliance with various processor architectures, providing an implementation of missing methods in the Java standard library.
Besides, the main goals the Scala Center has provided multiple bug fixes addressing various aspects of Scala Native, their list can be found in the latest changelog. We have also improved the Scala Native configuration interface in the sbt plugin to be more compact, easier to use and maintain.
Finally it is important to acknowledge and celebrate contributions from our community including multiple bug fixes, as well as new features like cross-compilation, support for Java default methods in Scala 2.11, providing bindings for native libraries or pending work on support for 32-bit architecture.
Check out our release 0.4.0 blog post describing the most user-impacting changes introduced and stay tuned for the next updates.
– The Scala Center Team
This is wonderful work! A big “Thank You!” to everyone who is pushing Scala Native forward.
Improve and enhance native interoperability, so that Scala Native can support as many libraries as possible.
The A#1 obstacle to pursuing this goal in earnest on, say, Apple OSes (iOS/MacOS frameworks) & Microsoft OSes (UWP) is the official lack of support of multithreadedness whatsoever in Scala Native. Single-threaded usage of Apple frameworks restricts them to trivial usage, not suitable for AppStore development at all (even if I were to contribute a Scala-Native language projection mechanism, to borrow Microsoft Xlang’s terminology).
How big of an obstacle is multithreaded support in Scala Native foreseen to be, say, via Scala’s Thread? What I am asking effectively is:
When reading this topic, it strikes me that many of the arguments why Scala native “might be not so useful” seem to perceive native programming as a hostile, cumbersome and somewhat painful and outdated environment.
However, the world of native programming has also evolved considerably over the last two decades. There are mature libraries and frameworks, and people are using likewise modern concepts, techniques and abstractions. Admittedly, the learning curve can be steep at times.
And while in fact it might be not so compelling to port an application designed for the JVM ecosystem into a native environment (instead of just using a clever wrapper or runtime) – I do see a promising perspective for a certain kind of application actually rooted within the a modern native programming style. Because, what is often quite expensive and cumbersome in the native frameworks is the implementation of advanced control logic and handling of metadata.
Consider e.g. some 3D graphics, model generation or simulation stuff. You’d certainly not need to implement the I/O for raw data in Scala. This would likely be some kind of engine, and thus receiving commands via pipe or a network connection, and you wouldn’t need Scala for any of this either. You’d certainly use a completely deterministic memory management for the “heavy lifting” anyway, cleanly built with the techniques of the native world. However, it would be very compelling to embed an advanced language as Scala to control how the processing proceeds, and to build rule based systems, constraint solving or an advanced description language, or selection of heuristics based on metadata.
Based on such a vision of a hybrid system, the most important missing part right now would be a good ability to interface with concurrent processing done within the native part. The computation part would e.g. use a thread / worker pool and lock free data structures from the native world, futures, coroutines, async I/O, you name it. However, a “command and control” part written in Scala-native would then have to face the challenge to receive callbacks and dispatch instructions from/into multiple threads or workers.
With the current state of affairs, you’d probably do all of the concurrency stuff entirely within the native framework and run the “command and control” part (Scala) within a single thread and attached through a dispatcher queue, similar to the way UI toolkits typically deal with user interactions.
If I am reading your post correctly, this is how GitHub - lolgab/snunit: Scala Native HTTP server based on NGINX Unit works.
Hi,
I would be interested in compiling smart contracts to WASM format for layer 1 blockchains using Scala.
Ethereum foundation is planning to rewrite their smart contract execution layer (EVM) to Ethereum WebAssembly (ewasm)
Project: Ethereum WebAssembly (ewasm) - Ethereum WebAssembly
A lot of other blockchains support WASM as a compilation format, check out this thread:
Greetings from Ukraine
Roman T
Since this post is about scala center supporting scala-native, it’s worth mentioning that they have stopped doing so. Scala-native is once again entirely community driven with no support from any scala organization. Or so I was told, can anyone confirm?
I don’t think that’s correct.
In fact, the onus is on you to provide more evidence than hearsay that Scala Center has changed its support position on this.
Can you provide a link, or tweet, or a person’s/organization’s name as a source for is currently the first step in creating a rumor?
It looks like Scala Native had a release yesterday (2022/09/01):
http://www.scala-native.org/en/stable/changelog/0.4.7.html
@chaotic3quilibrium @rcano It is true that by the end of 2021 the Scala Center is no longer actively involved in Scala Native project. I’m not aware of any official announcement of this decision. The list of active Scala Center projects no longer enlists Scala Native.
Me, as an employee of VirtusLab I’m still actively involved in the maintenance of this project. I was also responsible for developing Scala Native when I was a member of the Scala Center team. As you can see Scala Native still gets updates (eg. support for Scala 3.2.0 in yesterday’s 0.4.7 release). It is also actively developed by the community.
Tysvm for that update. Do you have any idea why Scala Center is no longer supporting it? And if they plan to do so in the future?
Unfortunately, I don’t have any information in this area. However, I’m convinced VirtusLab would actively continue contribution to Scala Native. We can see potential of this project.
Keep in mind that Scala Center’s resources are quite limited, especially when you consider the number of projects they are supporting – they’re doing a lot with relatively few people. I can’t speak with any authority, but I suspect it comes down to resources and priorities…
Taken from the meeting notes of the last Scala Center Advisory Board meeting:
Martin was also recently awarded an Advanced Grant from the Swiss National Science Foundation (SNSF) to support research, including funding for graduate students. He has tweeted some information about the grant. Note also that the grant includes support for Scala Native. [emphasis mine]
Does that mean EPFL will also be working on Scala Native, or how does that grant coincide with the ongoing efforts that VirtusLab is doing on Scala Native?
EPFL and Virtuslab will work together on Scala Native. Provided we find the right people. Which reminds me, there’s still an open job search for great compiler hackers: Looking for Compiler Engineers.