IBM Stops Server Side Swift Framework Development | Hacker News Reader

IBM Stops Server Side Swift Framework Development

forums.swift.org

156 pointssamcat11697 comments

Two guys that IBM was paying to work on server-side Swift are stepping down from the server working group (presumably because IBM decided not to pay them to do that anymore).

I think these guys were best known for Kitura, the (previously) IBM-backed web app framework.

I don't do web apps in Swift "for realz" (I use TypeScript and tools like Angular and Koa.js for that kind of thing), but I do use Swift on Linux and have built some toy ones using both Kitura and Vapor.

My impression is that Vapor gained a lot more traction than Kitura did, so in some ways this might just be "the market choosing" and Kitura heading for the sunset.

While it's sad to see IBM go, Vapor and the Swift Server working group are alive and more active than ever

https://github.com/vapor/vapor/ https://swift.org/server/

Amazon has also created a Swift web framework: https://github.com/amzn/smoke-framework

I’m excited for Vapor 4! Also love all the Vapor Red stuff.

Pretty clear signal that there's low appetite for full stack development in Swift.

What are other promising future "end-to-end" (i.e. Web / Server / Mobile) development platforms are there? IMO these are the main contenders:

    - JS / node.js / React Native (Android/iOS) (+ other transpile 2 JS langs, e.g. TypeScript, Clojure, Scala, OCaml, etc)
    - Kotlin to JavaScript / JVM / Android / Kotlin Native (iOS)
    - C# Blazor / ASP .NET Core / Xamarin (Android/iOS)
    - Dart JS / Dart VM / Flutter (Android/iOS)

Rust/Go/C++ could get some mentions, but I don't think they have enough community or commercial backing to become a popular mainstream option.

For better or worse, I assume Rust and Go (and other future languages) will begin to start taking advantage of js VMs and js toolkits (frontend) via targeting (compilation) WASM at some point.

People are actually already building stuff in Rust / <native code) / Rust (compiled to WASM running in a browser).

The frontend frameworks in Rust are surprisingly good, and I wouldn't be too surprised if this becomes a mainstream option at some point.

That said, I generally find there isn't all that much advantage to sharing a frontend and backend language.

Yeah they're mentions because it's being done in small niches (there's also Ruby/Haxe + many other transpile to JS languages), I just think they'll always lag behind the other popular and well supported contenders listed. I could be wrong but that's my impression after having worked on all of them which all provide decent development development experiences and end results - though they vary in strength amongst the different categories.

So you list Dart as being well supported on the server side? Did I miss some killer app/framework recently?

Self-plug: https://angel-dart.dev

It may not have the popularity but it has a well resourced technical team behind its development resulting in the Dart VM being a highly tuned technically brilliant piece of engineering. It has great support for server scenarios like gRPC [1] which I'd imagine is a popular back-end for Flutter iOS/Android Apps which is my personal #1 pick atm for native cross-plat iOS/Android development.

I was an early adopter and saw promise in Dart based on the strength of its technical team (originally led by Lars Bak, Kasper Lund, Gilad Bracha, Bob Nystrom, etc) so invested a lot of time in developing a express-like web framework [2], Jade View Engine [3], Redis Client [4], JSON Client, etc. It had a nice/clean development experience, well-designed / fast libraries and APIs even back then, but abandoned it 6 years ago after going to work full-time on my own Startup and have been out of the loop of Dart VM/Server since then. Here's a short list of Dart web server frameworks I could find after a quick Google Search:

https://medium.com/@suragch/web-server-frameworks-for-dart-1...

Looks like Aqueduct [6] is the most popular at 1.4k stars, though I'd expect Dart Server is not going to see a major uptick until Google commits to a major project initiative like they're doing with Flutter & Angular Dart. So it might only see traction as a Dart gRPC server which can still provide an end-to-end development experience with SPA development with Angular Dart / gRPC Web / gRPC Dart and Flutter / gRPC Dart which I'll also add after having gone through a comparison of gRPC clients in different languages [6], Dart has basically the nicest async development experience [7].

[1] https://grpc.io/docs/quickstart/dart/

[2] https://github.com/dartist/express

[3] https://github.com/dartist/jaded

[4] https://github.com/dartist/redis_client

[5] https://github.com/stablekernel/aqueduct

[6] https://github.com/NetCoreApps/todo-world/tree/master/src/cl...

[7] https://github.com/NetCoreApps/todo-world/blob/master/src/cl...

> Dart Server is not going to see a major uptick until Google commits to a major project initiative like they're doing with Flutter & Angular Dart.

That's one of the important points for me. Google's commitment to Dart is... well.. Google-ish.

The original intention as an alternative browser VM is done, most of the founding team left, and for years only the Google Ads team kept it alive.

The Flutter "happened" and Dart had its "Ruby on Rails" moment. Now it seems tied to Fuchsia, too. A popular Non-google project would seem good, otherwise the comparison to Swift seems more appropriate than Go.

With WASM being the new hot thing, I fully expect something Blazor-Ish to become quite popular in the Go world, and to be honest, once compiler output is going down, it's not that hard: the frontend stack is embarassingly shallow.

I actually liked what I saw of Dart and like Bob Nystrom's way of communicating (he responds, but isn't all out evangelizing like e.g. some people representing projects that start with "R"). So don't get me wrong, it's great to see some enthusiasm, and it actually brought me back to fiddle around with it a bit over the holidays. But I still believe that's more my "I liked my Palm Pre/WinPhone 10 better than Android/iOS" side than the one correctly reading trends...

(I'm a Perl developer ATM, I clearly don't know a thing about "resume-building")

Dart originally got me more interested for its server side because of how the actor model seems presumably at its core. There aren’t so many languages like that.

More niche, but Scala is high quality for web/server/Android. (iOS is possible but not as good)

Scala.js / Scala JVM / RoboVM

Pretty niche indeed. Have you actually pulled off a PWA + Android + iOS in Scala?

PWA is easy enough with Scala/Scala.js but I assumed that Android + iOS was a sufficiently painful process to warrant avoiding the attempt. Thought about mixing in Cordova or perhaps Ionic via the excellent ScalablyTyped typings library, but the path of least resistance is to just use TS on the frontend.

Not iOS, but Android.

Coworker's article:

https://dzone.com/articles/why-i-dont-regret-moving-our-andr...

The parent post counted "Kotlin Native" as iOS. If you're willing to do that, you might consider "Scala Native" for iOS.

Dart, if you consider Flutter an alternative to JS.

+1 for this, from a technical standpoint. Unfortunately there's just not a lot of interest in it (for end-to-end use, not just mobile). But some people who use it swear by it.

I think the "recent" move to web apps by Flutter may spark interest up quite a bit. It's effectively native performance for the web, Android and iOS in one codebase. Combine that with a language that's easy to pick up from Js, and I would assume the business benefits would quickly make it a strong contender.

Except last time i checked, flutter for web renders everything in a 2D canvas, which for some reasons doesn’t feel that great.

Would you care to educate me on why that is bad thing? (I'm a Jr web dev, it's not that obvious to me, although I suspect such a 'graphics-first' approach on the web leads to difficulties with resizing, responsive design, etc?)

We’ll see how it works out, but my guess is the end result is going to be the same as with every other platform flutter has integrated: it needs to perfectly replicate the behavior of every native UI component on every mobile os / browser otherwise it’ll feel something’s wrong. For example scrolling, right clicking, resizing, zooming, button click, link colors, css animations, are all behaviors that could have various subtle behavior variations depending on the browser and its content (not to mention extensions such as ad blockers).

Also, integrating with other js components will likely be impossible as well ( try to integrate the google maps js component into your layout... good luck)

And browsers update way way more often than mobile os.

Mmmh, OK, I see, thanks a lot for explaining.

The UX you describe seems to fall in the 'naughty websites' category in my book, indeed. I think there's a "uncanny valley" of atrocious UX where it's "almost like the real thing but not quite" and it feels very disorienting. I'm pretty sure that wouldn't fly with most projects.

This and what you mention about js components imply that, what, we should expect each and every useful project out there to increase manhours to make some interface for flutter? I mean, short of a fits-all transpiling-middleware that takes in Js to output whatever Flutter needs to work with it, it's just not happening.

I'm not sure Flutter is as general a framework as we make it out to be; that it targets many platforms doesn't mean it targets many use-cases, let alone all of them. Afaik, it's a heavily 2D-graphics oriented solution, great for design-rich projects, and I had failed to see the restrictions (apps being their own little worlds) until you outlined what it means when translated for the web.

For the web I'd bet on some combination of wasm over this any day, tbh, combined with progressive web apps it seems a stronger, more general/opened proposition.

Thanks again for the good food for thought.

Rust actually seems to have significant backing from both Mozilla and Microsoft (in varying forms, but it's there).

I mean, if you asked me today to spit out a backend + web frontend + native app, I'd actually have no qualms about committing to Rust as an option. It's nowhere near perfect, but not as far off as people think either.

I think Rust is a great language, but until I see a successful app ecosystem start there's no way I'd consider it for a mobile app.

I think Kenny Kerr's Rust/WinRT project is going to be great on Windows (and Kerr already proved he can accomplish this kind of project with C++/WinRT), but Rust's language model is so fundamentally different from iOS and Android's that I can't imagine it being feasible any time soon.

I think it will eat into the C++ market share on mobile, which is a common strategy for larger apps that need to share business logic with native UI.

ClojureScript / Clojure / React Native

It's too sad that majority of devs don't even realize how nice, stable and pragmatic Clojure ecosystem has become.

I would also note that there are Blazor experiments going on right now for purposes of targeting things like Xamarin and WinUI (both official and unofficial), so one could potentially see Blazor as a single unified framework for all deployment targets on the Microsoft-side of the house in the not-too-distant future. The class partial support offered by the latest version of Razor Components would make it really easy to separate view logic depending on platform (you can use media queries & js interop to discover platform type on web). I.e. you could have MyComponent.razor w/ all the logic, and then MyComponent.Xamarin.razor, MyComponent.WinUI.razor, etc.

E.g.: https://github.com/Daddoon/BlazorMobile and some initial discussion https://github.com/aspnet/AspNetCore/issues/11471

Maybe OCaml/Reason?

I love ocaml/reason and write a fair amount of code in both (both native and to javascript with bucklescript), but as a backend server the ocaml native ecosystem is far from ideal.

If I was asked to do a full stack project with reason today I would write node bindings and use them.

May I ask what your dev setup is? I've tried to get vscode + Reason language server working a few times (following the disparate sets of instructions on the site and Github repos) and was never successful.

I mostly use linux and emacs, but I have the reason language server working everywhere, emacs, vscode, sublime and neovim.

IIRC, the vscode only needed the extension from the store...

I had issues too.

I installed the Reason extension from Jared, I think, and started a new project.

My main problem was that I needed bs-platform installed globally AND locally in the repository. Otherwise the extension would display some errors that the bs-platform could not be found, which didn't help first, because I already installed it, haha.

Is Kotlin Native any good?

I just started looking into and according to a few of my sources it isn't ready for primetime due to crashing issues and other problems with linux kernel versions

The threading model is not quite decided and the compiler is currently quite slow, but these things are being worked on and I think it looks very promising.

The Objective-C interoperability doesn't fully support generics, so writing iOS apps entirely in Kotlin is inconvenient, but some companies are apparently (it was said at KotlinConf) already using it to share business logic on iOS.

How about Python based frameworks? Django/Flask? I know they are not suitable for Mobile..

Yeah Python is a clear powerhouse on the server, but as its weak a target in browsers & mobiles I didn't list it as a candidate for end-to-end development.

Except all the people doing full stack swift tended to have gravitated towards Vapor. This IBM thing is a signal of nothing.

Ibm is a strong brand in the enterprise sector. Such a big name pulling off is at least the sign that the tech didn’t catch up in their world.

I don’t think server side swift has any chance against the other contender, it just has nothing special to offer and it’s often not even on par with competing technologies (go simplicity and concurrency, java ecosystem, python dynamic nature, rust safety, etc.). It doesn’t even have async...

I would be surprised if anyone but iOS devs use it.

Ps: and don’t get me wrong,i absolutely love its syntax and type system. But it’s not immediately obvious to someone already familiar with another PL.

Prediction: React Native will be dead in 3 years.

Why? It's already been around for 5 years and has certainly grown in popularity.

Frankly, it's awful. Measuring performance apples to apples, React Native is nearly strictly slower than a web application on mobile. As PWAs gain feature parity, I think there will be little to no point to React Native. Because of a lack of JIT capabilities, React Native JS just can't run nearly as fast as React on the web for example. That, coupled with bad architecture. Too much is deferred - you have deferred batching in react, followed by more deferred batching to create native layouts. This results in poor responsiveness. For toy applications you may not notice, but the architecture simply doesn't scale.

> As PWAs gain feature parity, I think there will be little to no point to React Native I absolutely agree, but it'll take Apple more than a few years to be willing to make iPhones have native app/PWA feature parity.

> Because of a lack of JIT capabilities There's the new Hermes engine which should speed things up

The main reason React Native will stick around is that it lets React developers more easily transition to native, and there's a ton of React developers.

My point is that React on web is already faster than React Native today (and it feels perfectly natural, in fact, better). The entire point of going to React Native in the first place was ostensibly for responsiveness/performance, and given that it gives neither, I don't see what purpose React developers have to switch (except that it gives the illusion of "speed").

I've been extremely impressed by Crystal. Coming from Ruby, I had very little trouble picking it up. And performance is simply phenomenal.

The other day, I noticed a slow-running python data transformation job, mostly string comparisons. It was on pace to take 18h to finish. Within half an hour, I had a Crystal version, ported line-by-line, that took 3 minutes(!) to finish.

ReasonML is also a strong contender. Facebook's Messenger website is written in ReasonML [0] and compiling ReasonML for server work is pretty good. You can share a lot between the two codebases. People even write desktop applications using it, checkout Revery [1]. The applications that it produces are so fast, they are a delight to use. It's also very compatible with OCaml so you can get advantages from that ecosystem as well.

[0] https://twitter.com/jordwalke/status/1177373197517221888?s=2... [1] https://github.com/revery-ui/revery

There's also web-native in "end-to-end" solutions space, which drops the requirement for mobile-native support.

Swift on the server is very new and has very small market share. At one time there were 3+ Swift frameworks competing for mindspace against piles of well established frameworks in other languages. That one framework is falling out of the mix isn't a big surprise.

Apple really ought to invest more in server side Swift directly themselves. I feel like it has a lot of potential, and what the community has done with limited resources is impressive, but it's not really going to be able to gain substantial traction without a lot more weight behind it imo

These things take time. A lot of people at Apple are heavily invested in Swift on the server, including the Swift core team: https://swift.org/server/

Swift itself still needs time to mature, too. Things like the memory model, async/await, generics, etc. The future is bright, it will just require some patience to get there.

There seems to be very little promotional stuff about the runtime for server-side. What's the story with that for Swift?

I don't think many people are going to start learning Swift just to build servers with it unless the platform/runtime provides something special. Otherwise it'll stay isolated just to the current iOS devs.

It's not a big surprise. A language is not only the language but also the ecosystem such as standard libs. Now when you have a language like Swift where half of the standard lib is not available on the dominant server platform (Linux) not many people are going to use it. Which is kind of sad because I like(d) Swift. Too bad no one was willing to untie the language from the Apple frameworks but obviously there was no party with enough resources to re-implement all of the ecosystem in a cross-platform manner.

I am wondering what this means in broader terms, IBM no longer have their weight behind Swift? ( Focusing more on Java which would make more sense from IBM perspective )

Or is this just not working on Web Framework ?

Is it fair to say IBM threw their weight behind Swift?

They were an early adopter and for a while the only other large company putting significant effort into it.

I think this is a very bad sign. Not necessarily because of Kitura (as others have mentioned, Vapor is more popular and quite active), but because IBM was the only major company that was at least somewhat invested in improving the server-side Swift ecosystem. Clearly, apple can't be bothered to fix some of the more serious issues with Swift on Linux.

Just look at the kinds of discussions that e.g. Ian Partridge has contributed to: https://forums.swift.org/u/ianpartridge/summary

It includes substantial work on Docker images, logging, crash debugging, etc.

Maybe google will become a bit more invested in the Swift on Linux side of things, but so far I haven't really seen them invest in the ecosystem (besides pushing differentiable programming, which is cool, but it's mostly satisfying a niche requirement).

FWIW I’d really like to see Swift available in more platforms. At the moment only MacOS and Ubuntu seem to be supported (*BSD and perhaps Windows would be very welcome)

Windows support is coming along nicely.

Windows is unofficially supported, it's just in the 2nd-tier "community" CI environment. There's definitely still a lot of work to go, though.

https://ci-external.swift.org/job/oss-swift-windows-x86_64/

I did not know this, good to hear!

Swift is also available on Fedora/RedHat/Centos 8; simply type “dnf install swift-lang”

* Disclaimer: I’m the packager for swift on those platforms.

Nice! That was NOT the case when I last tried it, and I prefer RHEL-based distros when not using BSD. Thanks!

Curious what this means for Kitura. Last I checked, the three major serverside Swift frameworks were Kitura, Vapor, and Perfect.

Perfect doesn’t look like it’s under active development, and if this means Kitura stops being maintained, it’s down to just Vapor as an active project.

I have tried three web frameworks, indeed, Perfect activities is less active although they came up some interesting UI tools for devs but CLI is always preferred.

I do find Golang has fill microservice space where Kitura couldn’t gain traction.

What are the pros and cons of swift vs Kotlin for the server?

They're very different languages under the hood. Kotlin's biggest strength is also it biggest weakness relative to Swift– it's all built on the JVM. It gets great integration with the mature Java ecosystem, but it has Java's downsides as well.

On the server, the lack of JIT warmup & a smaller overall heap size could be differentiators for Swift, depending on the context.

Does anyone know why IBM initially decided to throw some weight behind Swift?

Could be from their partnership that started 2014. https://www.apple.com/newsroom/2014/07/15Apple-and-IBM-Forge...

Outside of iOS, is there really any traction for Swift development? It certainly feels like it is settling into an also-ran position. And really, mobile apps are turning out to be a dead-end, and people don't seem to be actually investing in native clients anymore, they just slap their website in a browser control.

As an Apple fan and a programming language nerd, I have basically no interest in ever using the language. I spend a lot of time in C++, Haskell, Rust, and Kubernetes, but Swift just feels pointlessly complicated to me. (C++ I think is also pointlessly complicated, but the rest at least have a point ;-)

Swift is no more complicated than Haskell or Rust.

But Swift has had a more specific target platform, where it wouldn't make sense to produce excessively high level generic abstractions.

Whereas a language like Haskell is happy to try some absurdly abstract concepts in the interest of promoting computer science.

If you don't use complicated compiler extensions (which, to be fair, many people do), then Haskell's complexity is more compositional. There are not a lot of fundamental concepts you need to understand; it's just their combination that creates the complexity (such as typeclasses like Monad).

Swift's complexity feels much less compositional. There are still a lot of situations where I won't really know how certain features interact (especially when it comes to generics, associated types, etc.). Also, the documentation on some edge-cases is basically non-existant.

I would Swift is more complex than Haskell, though much more familiar to many programmers. Pure Haskell is pretty simple, all in all. Maybe using it isn’t, given the ecosystem ;-)

Swift and Rust are definitely similar in complexity, but Rust actually merits most of its complexity imo. It gives strong guarantees and a strong foundation for the future; I don’t believe that Swift has that. Swift adds a lot of features for the sake of having them, and I think that will catch up with the language quickly (see C++.)

I'd like to ask what about Swift feels complicated. I'm really curious because I've heard the same thing about Rust, and I also see Swift compared to Rust often.

Can you elaborate? Personally, I thought Swift’s distinction between value and reference types was fantastic. https://academy.realm.io/posts/andy-matuschak-controlling-co...

Wow, that's honestly not an opinion I've heard! I've always felt that Swift is one of the clearest, most comprehensible languages I've ever worked with. It also strikes me as a great balance between simplicity and flexibility/power/features. I don't want to ask you to dive into specifics, since I'm not doing so myself, but I'd love to hear if there's any standout examples of unnecessary complexity for you.

Another Apple ex-fanboy here. I loved the conceptual simplicity of Objective-C and its easy integration with the rest of the C-family world, I really enjoyed Foundation & UIKit around iOS 5, I still use Xcode a lot - but Swift made me slowly move back to a C++/generalist career.

As a random example, take the content of this article: https://www.rightpoint.com/rplabs/switch-method-dispatch-tab...

This is something that my less grumpy iOS developer colleagues regularly stumble over, and yet they keep telling me that Swift is super simple.

Also, Apple's tooling for Swift has gotten less crashy, but not more reliable in my experience. Almost every time I command-click a Swift function in Xcode to find its definition/source, Xcode shows me a random C function with the same name in some completely unrelated header file.

I predict/hope that Combine will be peak Swift, and that it will only accelerate the move to Electron and other portable technologies (go Flutter!).

To the sibling comments, here are some prior threads about other critiques of Swift:

https://news.ycombinator.com/item?id=17278175

https://news.ycombinator.com/item?id=15421073

https://news.ycombinator.com/item?id=13655125

FWIW those comment sections are talking about swift 2 and swift 3. Which are considerably older and lacking many features that clean up those concerns.

What part of Swift being as fast as C++, as safe as Rust, and with the functional type system of Haskell (but actually useful in the real word) is unappealing?

I don’t have the time to dive into specifics like the other comments are asking for, but I can say that all three of these claims are false. Swift has significant performance penalties for a lot of its functionality; Rust is significantly safer and lower overhead (Swift doesn’t do anything about thread safety or mutable aliases, for starters); and Swift’s type system, as far as I know, is not as advanced as Haskell’s (and also significantly less ergonomic when it does match functionality, imo.)

I will say that I think the language made compromises in all three of these directions, though.

I would encourage you to look deeper.

1. We've moved our company code base from tight C/C++ code to Swift. It is just as fast, with higher level syntax. In some cases faster. It has native SIMD types without external libraries too. Moreover, the Swift group has been focusing on correctness over performance to date. The goal has always been, that its deeply typed design can enable optimizations not even possible in c/c++.

2. Several of the founding Rust team moved to the Swift dev team years ago. As of Swift 5, the memory model supports the Rust-like borrowing. One could say Swift at this point is a complete superset of Rust. But, more importantly Swift favors a functional style of value type operations... which are inherently memory safe, and have no concurrency side effects in the first place. Value types together with Swift's very easy to use Dispatch concurrency library work for most use cases... it is viewed that "borrowing" is only a special purpose opt-in feature.

3. Swift is pragmatic. It is functional in its type system, value type operation, and no side-effect philosophy. But it is multi-paradigm, flexible, and designed for the real-world problems that reflect real programming needs... where as Haskell is arguably an academic curiosity and extremely unlikely to become a mainstream general purpose language.

The creator of Swift (and LLVM), Chris Lattner now works for Google. There’s already an experimental version of Tensorflow[1] for Swift. I personally believe that Swift will really shine in differentiable programming and thus machine learning. A little over a decade ago, most of the machine learning community was using either Matlab (and it’s open source clone Octave) or R.

It took a long time for the machine learning eco-system around Python to develop. I believe that’s the case with Swift as well.

[1]: https://www.tensorflow.org/swift/

Julia is better suited for differentiable programming and machine learning. Something like frontend/scripting with Julia, and computing cores with Rust, as an alternative to the ubiquitous Python + C/C++ stack. And there are already more or less established frameworks for Julia:

- FluxML[1] for machine learning

- Zygote[2] for differentiable programming

- Turing[3] for probabilistic programming

- Rich support for GPU[4]

[1] https://fluxml.ai/

[2] https://fluxml.ai/Zygote.jl/latest/

[3] https://turing.ml

[4] https://juliagpu.org/

They examined both Julia and Rust, among others, before deciding to move forward with Swift for Tensorflow.

https://github.com/tensorflow/swift/blob/master/docs/WhySwif...

> We are not experts in Julia, but since its compilation approach is based on type specialization, it may have enough of a representation and infrastructure to host the Graph Program Extraction techniques we rely on.

A quote from your own link. So they admit Julia might be a good fit. The only argument they gave is the "small community size", which is wrong, because Julia data science and any other computational science community is way bigger to almost non-existent Swift one.

Yes, and the next paragraph says:

> picked Swift over Julia because Swift has a much larger community, is syntactically closer to Python, and because we were more familiar with its internal implementation details

So Julia could match well, but the team at Google determined that Swift was a better fit for their new TensorFlow platform.

Well, Julia's technical computing community - arguably the subset that matters here - was much larger than Swift's. The more significant justification IMO, is

> and because we were more familiar with its internal implementation details - which allowed us to implement a prototype much faster.

In any case, both Julia and Swift seem to be making good progress here and I wish them both the best.

> is syntactically closer to Python

How is Swift's syntax in any way similar to Python? Other than not having semicolons, they clearly belong to different language families and don't seem particularly similar. Is there some very specific feature they were referring to here?

Chris Lattner is leading the project, of course they're using the language he designed. Personally I think they substantially underestimated the difficulty of setting up a full technical computing ecosystem in Swift relative to Julia. But, fair enough, if I'd designed Swift I'd probably be dogfooding it too.

Some previous discussions that mention the swift-vs-Julia decision: [1] https://news.ycombinator.com/item?id=19714622 [2] https://news.ycombinator.com/item?id=19884273

Actually this started before Lattner. Richard Wei kicked this off with his DLVM thesis.

Either way, Swift's functional design around a type system has some compiler implications towards solving larger problems that Julia probably will struggle with as it moves forward beyond the goal of just being a faster Python.

Specifically what?

Essentially Swift is in Lattner's words "Syntactic sugar for LLVM"... meaning it was designed from a compilers point of view to provide an ontology for code that a compiler can analyze, interpret, optimize, and enable deeper functionality. Swift backed that ontology with a functional type system that forms a set proofs of the relationships and meaning of your code.

If you take a language like C++, the "atoms" of the code like a Float32, are just hard coded intrinsics in the compiler. As such, they have no ontological meaning in relationship to a Float16, an Int32, or an Array of Strings. In Swift, a float is built from a set of proofs as equatable, hashable, Numeric, FloatingPointNumber, and etc. As related to Julia or Python, a static language built around these proofs, enable compiler's to provide "co-pilot" development assistance, guarantees at runtime, code validation.

Why is this important? With deeper knowledge, a compiler can optimize things in ways that weren't previously possible, extract graphs, and automate code execution in heterogeneous computing evironments.

The guys in our group giggle at Hacker News. The only time they ever even hear about Julia, is when a Swift article shows up here... then all the Julia nerds come out of the woodwork.

Guessing the opposite rarely happens.

> mobile apps are turning out to be a dead-end

Been hearing that for a decade now, but somehow I'm not out of work.

Reply on news.ycombinator.com