Live data from Hacker News

IBM Stops Server Side Swift Framework Development

forums.swift.org

51–60 of 99 posts

Re: IBM Stops Server Side Swift Framework Development

#51

Earlier quoted context omitted.

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.

Re: IBM Stops Server Side Swift Framework Development

#52
post #17

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 /…

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.

Re: IBM Stops Server Side Swift Framework Development

#53
post #17

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 /…

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

Re: IBM Stops Server Side Swift Framework Development

#54
post #34

Earlier quoted context omitted.

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.

Re: IBM Stops Server Side Swift Framework Development

#55
post #4

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.

Re: IBM Stops Server Side Swift Framework Development

#57

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 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/

Re: IBM Stops Server Side Swift Framework Development

#58

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.

Re: IBM Stops Server Side Swift Framework Development

#59
post #43

Earlier quoted context omitted.

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 learnin…

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…

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...

Re: IBM Stops Server Side Swift Framework Development

#60

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.

> 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.

Post reply on HN