Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IBM Stops Server Side Swift Framework Development

forums.swift.org

Post reply on HN
Print view View original

61–70 of 99 posts

Re: IBM Stops Server Side Swift Framework Development

#61

Post by favorited »

Klonoar wrote: post #27
mythz wrote: 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 /…

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.

Re: IBM Stops Server Side Swift Framework Development

#62

Post by thomasfortes »

brobinson wrote: post #54
thomasfortes wrote: post #50

Earlier quoted context omitted.

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

Re: IBM Stops Server Side Swift Framework Development

#63

Post by K0SM0S »

thosakwe wrote: post #35
sansnomme wrote: post #25

Earlier quoted context omitted.

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.

Re: IBM Stops Server Side Swift Framework Development

#64

Post by xvilka »

favorited wrote: post #59
xvilka wrote: post #43

Earlier quoted context omitted.

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

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

Re: IBM Stops Server Side Swift Framework Development

#65

Post by cbkeller »

favorited wrote: post #59
xvilka wrote: post #43

Earlier quoted context omitted.

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

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

Re: IBM Stops Server Side Swift Framework Development

#66

Post by favorited »

xvilka wrote: post #64
favorited wrote: post #59

Earlier quoted context omitted.

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

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.

Re: IBM Stops Server Side Swift Framework Development

#67

Post by cbkeller »

favorited wrote: post #66
xvilka wrote: post #64

Earlier quoted context omitted.

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

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.

Re: IBM Stops Server Side Swift Framework Development

#68

Post by fulafel »

mythz wrote: 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 /…

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

Re: IBM Stops Server Side Swift Framework Development

#69

Post by lucasmullens »

banachtarski wrote: post #48
mythz wrote: 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 /…

Prediction: React Native will be dead in 3 years.

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

Re: IBM Stops Server Side Swift Framework Development

#70

Post by therockhead »

favorited wrote: post #61
Klonoar wrote: post #27

Earlier quoted context omitted.

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.
Post reply on HN