Live data from Hacker News

Silver: A free implementation of Swift for .NET, Java, Android, and Cocoa

elementscompiler.com

61–70 of 109 posts

Re: Silver: A free implementation of Swift for .NET, Java, Android, and Cocoa

#61
post #43

Earlier quoted context omitted.

The point is to AOT compile to native code.

In fact that's exactly what it does: https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilat...

When talking about AOT compilation, we generally tend to mean that the compiler produces a binary consisting of machine code at some unspecified time before the user attempts to run the application.

In the context of that blog post, there are two compilation steps: First emscripten would be used to produce JS. Then Mozilla's JS engine would compile that JS down to machine code at runtime.

They call the latter step with OdinMonkey AOT when they compile the entire thing at runtime, but before starting execution. But the way most people differentiate, this would still be considered JIT - it still depends on executing the compiler each time the application is started.

Re: Silver: A free implementation of Swift for .NET, Java, Android, and Cocoa

#62
post #32

I just want to write web apps in Swift. Any news on that front?

Well if this compiler works as advertised, you should be able to use Java / .NET libraries for web applications.

You can use it with ASP.NET, JSP and whatnot, correct.

Re: Silver: A free implementation of Swift for .NET, Java, Android, and Cocoa

#63
post #27

I'm curious to know how well it performs. I spent the better part of this weekend rewriting 4k lines of Swift in Objective-C because I couldn't deal with the 60-90 second compile times.

Swift has some land mine issues where the compiler can hit snags handling certain snippets of code (e.g casting to/from Any/AnyObject, method overloading based on constraints, etc) which if you have enough of them will segfault the compiler with something along the lines of "expression too complicated, break it down". I've had to rewrite my approach a few times because of this to avoid certain coding techniques, but…

Are you saying you are OK with compiler performance affecting the design (and possibly quality) of your code??

Re: Silver: A free implementation of Swift for .NET, Java, Android, and Cocoa

#64
post #16

This looks interesting, although adding language extensions makes me a bit nervous. What's the ABI compatibility story when targeting Cocoa? Can I mix and match with native Swift classes? Is the native Swift runtime used?

The language extensions are there to support concepts that don't exist in Swift, for example await and exception handling are pretty much a requirement when targetting .NET and Java/Android.

It's ABI compatible with Cocoa, all classes end up usable from Cocoa.

It does not use the swift runtime.

Re: Silver: A free implementation of Swift for .NET, Java, Android, and Cocoa

#65
post #20
post #14

Earlier quoted context omitted.

Silver itself might be free, but I think only if you bought the compiler already, http://elementscompiler.com/elements/pricing.aspx

> Silver itself might be free, but I think only if you bought the compiler already, so it isn't free software at all.

We make three compilers. Oxygene, C# and Swift. The Swift compiler is/will be completely free use for everybody — no purchase required.

Re: Silver: A free implementation of Swift for .NET, Java, Android, and Cocoa

#66
post #12

Earlier quoted context omitted.

Programming languages cannot be copyrighted. It doesn't look like they've reimplemented any Apple APIs, so there wouldn't appear to be any room for an Oracle-style lawsuit claiming that standard library code was copied. I don't know what the trademark situation might be, though.

> Programming languages cannot be copyrighted Are you sure? I'm genuinely curious to see a reference/precedent. Also, does that restrict patentability of programming language features? (I personally can see PLs not being copyrightable, but being patentable.)

For Europe, there's http://en.wikipedia.org/wiki/SAS_Institute_Inc_v_World_Progr....

There's not really any case law I'm aware of in the US, mostly because nobody's ever tried. Copyright doesn't cover "facts, ideas, systems, or methods of operation". You can trademark the name of a language, and its documentation and any distributed software are under copyright, but the process required to translate that language into machine code isn't eligible for copyright.

Parts of the implementation might be patentable, but I don't know of any cases of anyone successfully patenting a programming language.

The Oracle vs. Google lawsuit is still going back and forth in the courts. It's worth noting that even Oracle isn't claiming that the parts of Android that involve parsing and compiling Java code are infringing on their copyright. The matter of controversy is that they claim copyright on the design of the Java standard library.

Swift's standard library is pretty much Cocoa, which isn't being rewritten here.

Re: Silver: A free implementation of Swift for .NET, Java, Android, and Cocoa

#67
post #35
post #13

Earlier quoted context omitted.

Swift is statically typed, so it doesn't really compete with JS or Clojure. The company already has a C# implementation for sale. Also, Swift was designed to compile to native code, unlike any of the other three languages.

.NET has NGEN since 1.0.

And .NET code _does_ compile to native code even without NGEN - it just does it 'Just In Time'. It's pretty close to native code just before that step, so the actual native compilation is very fast.

Re: Silver: A free implementation of Swift for .NET, Java, Android, and Cocoa

#68
post #35
post #13

Earlier quoted context omitted.

Swift is statically typed, so it doesn't really compete with JS or Clojure. The company already has a C# implementation for sale. Also, Swift was designed to compile to native code, unlike any of the other three languages.

.NET has NGEN since 1.0.

Sorry, I was imprecise.

Swift was designed for the iOS platform as a replacement for Apple's dialect of Objective C. This is an unmanaged environment. There's no VM or garbage collection, although both languages support automatic reference counting.

C# was designed for the CLR and has a large standard library that relies on garbage collection. It also has features permitting calls into unmanaged code, but the language was still designed for a VM.

Re: Silver: A free implementation of Swift for .NET, Java, Android, and Cocoa

#69

Cool! But, is it possible that this violates Apple's TOS or any legal limitation on use of the Swift language? I remember there being a lot of heated discussion about making Swift officially open source back when it was announced, but I don't recall ever hearing anyone suggest a community project to make an OSS compiler for it. This is most interesting, but I'd love to know that Apple would be okay with this, or woul…

The problem is not whether it is legal to use Swift in a 3rd party environment, but the lack of support in the 3rd party eco-system per se means the attempt would vanish, in time.

I believe most of us who actually use Objective-C choose it not because the language itself is designed to be simple and elegant, (and yes the language is simple and elegant,) but because the Cocoa and Cocoa-Touch are well supported by Apple. No offence to the effort outside of APPL, but it is not enough to support a full-fledged eco-system with all 3rd-party F/OSS written in Objective-C that is compatible with what Apple currently uses in order to build reusable components. GNUStep has existed for so many years, and Étoilé for years as well, but I did not see emergence of adoption in community comparable to that of other popular F/OSS frameworks, e.g. Mono and Qt. And I do not see how this issue could be circumvented, unless some big player shows up and adopt any of these projects, like what Google did to Android.

Re: Silver: A free implementation of Swift for .NET, Java, Android, and Cocoa

#70
post #63
post #27

Earlier quoted context omitted.

Swift has some land mine issues where the compiler can hit snags handling certain snippets of code (e.g casting to/from Any/AnyObject, method overloading based on constraints, etc) which if you have enough of them will segfault the compiler with something along the lines of "expression too complicated, break it down". I've had to rewrite my approach a few times because of this to avoid certain coding techniques, but…

Are you saying you are OK with compiler performance affecting the design (and possibly quality) of your code??

Nobody says you have to OK with something you mitigated against.

I remember on several occasions fighting Visual C++ over code it bombed out on. Having a precompiled header scheme to make up for poor performance. Yes it sucks, but you don't do these things because you think it's acceptable, it's because the alternative is more painful.

Post reply on HN