Slightly different goal set there. It all depends on what you want to achieve. If you want to host some existing Java code in your macOS app, then a Java/Cocoa bridge is helpful. If you want to use Swifty cowrite — say some JSP or an Android app — not so much.
To use C#/.NET, you couldn't;t use the Java bridge, you;'d instead need to host the Mono runtime. Doable for Mac, in fact it's a technique we use, and we have an open source bridge framework one can use to generate wrappers for Objective-C (or any other language on Cocoa level) rtf interact with the .NET objects — you can find it at GitHub - remobjects/Marzipan: Easily embed Mono and managed code in your native Cocoa apps (the name predates the "other:" Marzipan by a few years ;). We use this very successfully in our Mac IDE, which is mostly native Cocoa, to host some .NET code).
I guess we need more Fedora nodes before official support could be considered. I don't have much time, but perhaps in the near future I could have a look at setting one up.
I'm running one already in the Community Hosted CI. I'm planning on setting more up once I figure out how to pay for them in a way that doesn't upset my wife .
I saw a talk about it recently (https://www.youtube.com/watch?v=DqsYo_4QWSg) and they say that Kotlin Native runs in a VM-less environment (hence the "native"). So they're doing basically the opposite.
It seems to me like we could probably also do something like that one day. It's cool that they use the same frontend for both JVM and Native targets.
The silver thing looks interesting; I'm happy that the community is working to develop better tooling for the Swift language. As others have said, I'm not a fan of how much it diverges from actual Swift (not just different semantics, also language extensions).
My personal goal is to take an existing core of a macOS app written in Swift (~100KLOC) that implements the main functionality and write a native UI e.g. for Windows, while keeping the core as-is (as much as possible). All I need is either to write the UI in Java/C# and invoke the Swift library, or more preferrably gain the same interaction as I get when I write against Cocoa on macOS in Swift - to write up the UI in Swift, while the UI implementation is in another language. For something like that, "all I need" is a bridge that maps Swift <-> Java/C# basic types (String, Array, Int, ...) and allows me to invoke existing native libraries.
I personally would prefer Swift running out of the VM and invoking the VM when necessary and vice versa. But to be honest, I don't have a deep knowledge of the Java and C# runtimes, so I can't tell how much is this possible or not.
Silver does the same, fwiw. Same front-end (which actually supports 4 languages, Swift, C#, Java and Oxygene; you can even mix them in the same project), and different back-ends (JVM, .NET, Cocoa, as well as native Windows, Linux, Android NDK and WebAssembly).
We're always happy about concrete feedback. We're trying not to add any extensions that aren't absolutely necessary for proper supporting the all platforms (like, you kind of need an "event" concept, if you want to do .NET WinForms or WPF, so we have an extension for that — things like that). We don't add extensions just to "improve" the language based on our own ideas (we have Oxygene for that), we want to stay as close to Swift as we can.
I'd appreciate your thoughts on the extensions we did add.
What I mean is that it would be cool if Silver used the official Swift compiler frontend; that’s what Kotlin are doing.
For example, you say that some evolution proposals are implemented in silver before the official compiler. That’s cool, but if it’s part of your own frontend it won’t benefit the community at large and duplicates effort. How do you know your implementation is correct (especially for some of the less-well-documented parts of the language, like name lookup)? Does it pass the test suite?
The deal with extensions is that if people are writing projects in “Swift”, with the intention of compiling them with Silver and using your own extensions like “_lock”, those projects would not compile with the official compiler.
Again, I’ve invested lots of time getting to know the Swift language, so of course I’m happy when projects like yours increase the value of that knowledge and let me apply it to more kinds of problems. I don’t want to be too critical of something which is in theory a very cool and beneficial project for the Swift community.
Yeah, I'm afraid I don't believe that would work, not with how it integrates with the other languages in the compiler, and the rest of out toolchain.
Well, the idea s that if you're writing, say a .NET WinForms app in Swift with Silver, then you might (or might not, too*) share a lot of back-end code between platforms (e.g. the business logic of your app), but by very definition, the UI portion would be WinForms and this .NET and Silver-specific. So that's where you'd use __event, to stick with that example, and it would not really matter because it's not like your WinForms UI is ever going to ave to cross-compile for Cocoa
(* by which I mean, it's also a fully reasonable scenario, which we see many of out users doing, not not care about the sharing-between-platforms aspect, at all. They just wanna write, say, .NET code, and they wanna use Swift, and trey don't mind if their code isn't cross-platform-able to Cocoa or Xcode-Swift)
One issue with there official test suite is of course that
To be accepted into the Swift source compatibility test suite, a project must:
Target Linux, macOS, or iOS/tvOS/watchOS device
which means that by definition, 90% of those "real life" projects can't just be thrown at our compiler and (even assuming 100% perfect language compatibility, which admittedly we strive too but of course have not fully reached) be compiled as is, because there's more to it than "does the compiler correctly understand every bit of the syntax, because these projects will also depend on APIs that simply aren't there for the other platforms.
(That said, it probably would make sense to throw these at our compiler in a "ignore APIs, just make sure we grok all the syntax, if we assume every identifier we encounter is known" mode, if that's feasible in an non-ambiguous way (might likely not be)).
Ideally, there'd be a set of test suits without any external (read no Cocoa, only Swift Base Library) dependencies, that one could strive for sharing and having both compilers pass fully...
That's the documentation for the source compatibility test suite you're quoting there, designed to make sure external projects still compile as the compiler is updated. There are a lot of Swift tests that fit your requirements in the subdirectories here, but you would need to do some work to filter out the ones that aren't applicable.
While I don't want to rain on anyone's parade, I think that discussing a third-party proprietary reimplementation of Swift that most people probably never heard of before it was mentioned in this thread is derailing the topic of this thread quite a bit.
Very cool, I didn't think efficient COW types were possible on the JVM/.NET. It is great that this is going to happen, thank you for driving it forward!
For developing Swift on Android and iOS, use the Swift Android compiler to ARM/x86 including IDE, cross platform graphics engine, Swift Foundation for Android, SPM support. Download here: www.scade.io
.