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)
2 Likes
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.
Short and mid-term goals
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.
Long-term goals
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.
Other activity
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
40 Likes
This is wonderful work! A big “Thank You!” to everyone who is pushing Scala Native forward.
13 Likes
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:
- Does the Scala-Native community know the remaining work toward any degree of official multithreaded support in Scala Native? or
- Is it a case of not yet even knowing what the unknowns are?
3 Likes
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.
9 Likes
If I am reading your post correctly, this is how GitHub - lolgab/snunit: Scala Native HTTP server based on NGINX Unit works.
2 Likes
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
3 Likes
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.
7 Likes
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…
6 Likes
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?
3 Likes
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.
20 Likes
This is AWESOME to see/hear!
Hello,
Indeed, I confirm that the Scala Center does not work on Scala Native currently. I’ve posted a slightly more detailed message about that here: The Typelevel stack and Scala Native - #8 by julienrf
2 Likes
I would say for most projects to become successful there needs to be some killer “app” or feature, for scala-native this is what comes to mind
- Potential for higher performance than JDK/GraalVM. This is result of the fact that both JDK and GraalVM use the JVM bytecode and the translation from Scala source to JVM bytecode loses information that can be used for higher performance. Techniques such as fusion which along with a way to track purity can provide higher performance, as well as knowing immutable datastructures (one of the reasons why OCaml’s GC is so fast is it can take advantage of this)
- More fine grained control of the GC. While the JVM is a world class GC it is a double edged sourced in a lot of cases particularly when it comes to controlling the GC in a fine grained manner (i.e. not globally with flags). scala-native has much nicer interopt with C (allowing you to bypass the GC entirely) and with the flexibility of the scala language can provide better abstractions for controlling the GC, i.e. think of Rust style regions represented as a Scala
traitthat you can mixin with datastructures where you want to control when GC happens. Issues like this (and others) is in my view one of the main reasons why Java has never taken off when it comes to games (or at least non trivial games) and along with a proper multithreading implementation I can even see game engines using Rust + Scala native (with scala-native for higher level stuff such as game logic) and Rust with the engine, both being compiled together with LLVM - CLI apps/IOT: As you mentioned startup time is not usually that much of a difference but it can still matter. With having native binaries you do have other options opened up, such as much easier packaging options (don’t need to package or worry about a JDK). While GraalVM can also solve this problem, scala-native’s footprint by default is smaller which also means it can work nicely with IOT style devices.
- GUI apps. While swing exists, the ergonomics and design of the GUI toolkit can be argued as questionable. For example, Intellij ended up having to fork OpenJDK (see Home · JetBrains/JetBrainsRuntime Wiki · GitHub) in order to add capabilities such as HiDPI as well fixing the performance issues (mainly latency) associated with the JDK. Ontop of this, Scala’s language design is in my opinion is one of the nicest languages to program GUI’s in. Its blend of OO and functional programming really gives you the best of both worlds to write GUI’s (while OO is definitely overused, one area where it still shines is UI toolkits). This along with modular features such as
traits makes Scala extremely powerful in modelling GUI’s. For these reasons scala-native is much more prepositioned to integrate better with native ui toolkits than JDK/Java/GraalVM.
2 Likes
In addition to this, GraalVM can be quite painful to set up (for instance, logging and cloud libraries have taken me more time than I wished to), and the resulting binaries are quite large. Scala Native produce smaller and more performant binaries, which is great for a whole range of apps: microservices, CLI, native GUI, …
5 Likes