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 once I've rewritten to avoid them, Swift can happily compile my 7-8k LOC code-base in ~6s.
Is there a list somewhere of Swift compiler issues to avoid? Seems like "avoiding certain coding techniques" is what is currently necessary until Apple gets back on top of things...
One other example FWIW: having a largish array of Int arrays causes the compiler to either go into an endless loop or simply take too long, UNLESS the type of the array is specified.
var data = [[1,2,3],[4,5,6], ... ] // > 20 elements -> compiler hangs
as opposed to:
var data:[[Int]] = [[1,2,3],[4,5,6], ... ] // compiles quickly
Finding Swift really buggy atm - where XCode, Swift Compiler and SourceCode service routinely crashes multiple times a day for me. A lot of my time is spent sympathizing with the compiler and getting hit with hard fought lessons on what things to avoid - basically don't step too far outside the Swift Programming Guide. Apple's also glacially slow at responding to bug reports - I'm keenly waiting on the next Q/A release of XCode/Swift.
Dogfooding usually implies that the technology is used in mainline business operations. It needs to be more than building a demo, it needs to provide sustenance.
I don't think I'm doing anything too fancy, but who knows? I probably have too many conversions to Objective-C objects that I used to workaround beta compiler issues that are probably fixed by now, but I haven't found a lot of guidance on what to avoid (I'm declaring types pretty much everywhere) and since the compiler isn't crashing, the list of compiler crashes doesn't really help.
It's a shame because Swift is a neat language. But because Xcode doesn't support incremental compilation for Swift, a single character change causes the entire project to rebuild. Couple that with LLDB crashing because I'm including Objective-C frameworks (via Cocoapods), and the whole experience becomes absolutely terrible.
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.
So, the Swift compiler is slow? I mean, I expected it to be slower than Objective-C due to its dynamic nature, but that slow?
Disclosure: I write Android apps, so I'm only occasionally peeking at how the iOS dev scene is developing. I've already been thinking of trying to write Android apps in Scala, but maybe this Swift to Java compiler is also worth looking at
From what I known, Kotlin or Xtend are better options than Scala, regarding execution speed of the current code generation and package size, even with ProGuard.
Apple only just today released an update to the compiler that enabled incremental builds. Before that it had to recompile everything every time. That alone will probably make a big difference.
I don't have time to look, but when I signed up, I was given the option for a free trial and the option to spend $500+ depending on the package. I'll have to look closer, but I suspect this is xaraminesque.
Looks pretty shady. Proprietary code through-and-through, and it's "cross platform" because it compiles down to their own proprietary language. It's unclear how you deal with native libraries, if at all.
I know this guys from long time. Their RemObjects/DataAbstract is IMHO the best remoting framework ever done (I have use Delphi, .NET, Python, Obj-C, VisualFoxPro and test several frameworks for that).
They are supporting their implementation of Pascal for several years now, and my experience of using DataAbstract from obj-c show the interfacing is good.
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 would have no recourse to shut it down, prior to putting in the time to pick it up.
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.
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.
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.)
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.
> Swift is statically typed, so it doesn't really compete with JS or Clojure.
This seems to imply that developers make a static vs. dynamic choice separately prior to and separate from evaluating other aspects of languages to choose between them. While some developers may do that all the time, and some may do that some of the time, I don't think its true as a generalization.
Certainly Go is statically-typed, and often portrayed as competing fairly directly with Ruby/Python, which are not.
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.
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.
Except there isn't any VM when the code is AOT compiled to native code with NGEN, MDIL in Windows Phone 8, .NET Native, or in iOS.
The presence of garbage collection has nothing to do with being native or not.
Besides a language runtime and VM aren't the same thing.
Actually Swift makes use of Objective-C runtime to achieve interoperability with Objective-C libraries.
Oberon, Oberon-2, Modula-3, Component Pascal, D, Spec#, Dafny are all examples of languages that compile to native code, were used to write operating systems and use garbage collection.
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.
The point I was trying to get across is that by cross-compiling from C/C++ with Emscripten, static type information can be used to give native performance, that a program written directly in Javascript wouldn't. It's still AOT in that sense - it's not like JIT where only hot bits of code get converted to native to code, and only then when some heuristics have determined what actual types the code ends up dealing with at runtime.
I'm not sure how you claim to be the authority on 'CS speak', but it's a sufficiently blurred line here, for reasons I clearly explained and which you seem unable to understand.
Emscripten/asm.js can use static information to generate Javascript which can be compiled to native code, before the code in question is run, aka Ahead of Time.
Ahead of time compilation is used to describe the process of generating machine code at compilation time, in a form that can be executed directly by a processor without any additional transformation process.
Which clearly is not happening here, as the code is converted into JavaScript and relies on a JavaScript implementation to run. Regardless of the optimization processes used by the JavaScript engine.
Swift is just a language specification. It cannot be patented or copyright-ed. Anyone is free to make tools around the language specification. Just like there are many compilers for C/C++ on different platforms, we intend to make one for Swift on Linux/Windows.
The fact that arrays and dictionaries are classes rather than structs is a major problem with this. That's a massive semantic difference between their implementation and Apple's, and it's one that won't show up as a compile-time error. Taking code written for Apple's implementation and using it on Silver is likely to result in a nightmare of crazy debugging trying to track down all the cases where you're now sharing arrays/dictionaries rather than copying them. This really needs to be fixed, and if it's truly impossible, IMO it's bad enough that the thing should be scrapped.
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.
So much this. It'd be an excellent alternative to Go, with it's nice type system and pretty advanced PL features: I'd love to write web services in Swift, but that's contingent on being able to deploy it to Linux et al.
Maybe you should check out OCaml then. It can be deployed to Linux/Windows/Mac OS X without problems, ARM devices. Offers native compilation and can even be compiled to JavaScript. The compiler is fast and freely available.
The type systems is even better and more advanced. Coming from Swift I was kinda surprised that its pattern matching was a statement and not an expression, as typical functional languages do.
The state of OCaml documentation is not great... I have had such a pain finding documentation. Generally, the only source for it is the French university that created/promotes it [0]. But even their pages are often almost a decade old and I have frequently found errors in the documentation.
Overall, while OCaml is a truly beautiful language (and I do really enjoy writing in it[1]), it is really tough to get work done efficiently because so few resources seem to exist.
With that said, I discovered a mod_ocaml Apache module implementation[2] (that is really outdated and not very efficient) and moved it to github. (I am not the author, nor have I had time to work on it either.) But if there was any interest in reviving this, I'd certainly give it a go. This seems to be a potentially viable way to increase interest in server-side OCaml usage.
> The state of OCaml documentation is not great... I have had such a pain finding documentation. Generally, the only source for it is the French university that created/promotes it.
That might have been true 5 years ago, but the OCaml Community site [0] is rather easy to find and links to many tutorials and books. Among these is the excellent Real World OCaml [1] book which is pretty great for experienced developers switching languages and available in print and freely online. Other resources for more beginning programmers exist as well. The INRIA resources are, indeed, rather poor and except fro the language reference, rather outdated.
Directly programming for Apache hasn't been popular for years now in any language I know (actually, only mod_php is popular, if at all, mod_python is completely dead and no idea about mod_perl). Usually languages have their own servers that get reverse-proxied by a frontend server like Apache or Nginx. And for this purpose Ocsigen [2] has been available (allowing an front-and-backend OCaml approach). If something simpler is desired, CoHTTP [3] exists, which is both a HTTP client and server. Reviving mod_ocaml is, in my opinion a waste of time and effort.
Great points. I was being too vague. My biggest gripe was that I could only learn more of the syntax from the INRIA documentation. The books and OCaml websites definitely covered a lot of general programming recipes and more common paradigms. Ultimately since there were still so few examples I always ended up having to look at the actual language reference for useful information. As we're aware though, it is outdated. In particular, I found really getting a handle on object-oriented OCaml was tough. Probably just because other aspects of OCaml could be guessed/inferred from SML/*ML documentation.
My comments on mod_ocaml were also a little vague. When I began server-side programming I loved mod_php because of how simple it was. I only brought up mod_ocaml because (if it worked) it is probably the single easiest way to start writing ocaml web pages. Given, it is absolutely not performant whatsoever. I just kinda saw it as a gateway from hobbyist-level interest.
I started working on a Swift web framework this summer, but I abandoned it because the language kept changing too fast for me to keep up. If I get some free time, I'll pick it up again.
> is the Java version now a JVM language, like Scala and Groovy
I guess so, ditto with .net and android -- that's what happens when a programming language creator, here Apple, specs out a language at the same time they implement it. Could be why Swift is getting many implementations whereas a language only paying lip service to the idea of a spec, say Groovy after Dec 1995, is still stuck on one impl.
Actually I am really of the opposite opinion! Since I am not interested in developing games but rather in cross-platform support I think that Silver is what Haxe should have been!
Apple needs to buy this company in 3, 2, 1... This is an ideal start to countering the concepts from Xamarin out of the .net camp and I would love to see them build up some form of XAML-like UI tech and tooling for x-plat UI dev so you could push the envelope on code-reuse. That would take a big dump of capital.
It would also make for a push in the market for this style of x-plat dev. If you can get to the major and minor platforms with one code-base and a single-stack dev team, oh what a smooth world it could be.
Windows 10 on all devices, written in Swift to a universal in visual studio. Wonder if I'd get to see a macbook running windows with a dev writing swift in VS.
Swift developers, building across platforms, can get their Apple-loving code into enterprises through the front door so Apple hardware can start coming through that way as well. Push the Apple brand via programming language in order to sell more hardware.
Is the longview really that a closed platform with a narrowly used language will increase the share of revenue from Mac sales?
Swift + walled garden are OK for selling phones, but for OSX to go beyond <10% of PC marketshare, they could use a language to erode resistance to Macs in the biggest markets for PCs. Microsoft puts Office on the Mac. Now, you can also have business systems built on Swift that can work on shiny Mac hardware AND crusty Windows boxes.
You buy this company because they love Swift and can help get a foothold on dev teams in the enterprise. No matter how many kids come up using Swift to make their phone apps, they are going to get pushed into building C# and java, and a bunch of other languages, using other hardware and tools, when they joins the ranks. You buy this company so you can control the direction of their efforts and use it to put more eggs in other baskets.
I don't think apple wants to push for cross platform development. Looking at the last decades I would sustain the opposite idea, they are trying to just build tools who can work only on their own ecosystem
