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

71–80 of 99 posts

Re: IBM Stops Server Side Swift Framework Development

#71

Post by bsaul »

mhd wrote: post #37
mythz wrote: post #24

Earlier quoted context omitted.

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

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

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.

Re: IBM Stops Server Side Swift Framework Development

#72

Post by bsaul »

K0SM0S wrote: post #63
thosakwe wrote: post #35

Earlier quoted context omitted.

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

Re: IBM Stops Server Side Swift Framework Development

#73

Post by bsaul »

briandear wrote: post #47
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 /…

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.

Re: IBM Stops Server Side Swift Framework Development

#74

Post by ofrzeta »

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.

Re: IBM Stops Server Side Swift Framework Development

#75

Post by mhd »

mythz wrote: post #41
mhd wrote: post #37

Earlier quoted context omitted.

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

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

> 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")

Re: IBM Stops Server Side Swift Framework Development

#76

Post by ptx »

tessting wrote: post #40
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 /…

Is Kotlin Native any good?

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.

Re: IBM Stops Server Side Swift Framework Development

#77

Post by ptx »

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.

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

Re: IBM Stops Server Side Swift Framework Development

#78

Post by actionowl »

favorited wrote: post #57
actionowl wrote: post #36

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/

I did not know this, good to hear!

Re: IBM Stops Server Side Swift Framework Development

#79

Post by k__ »

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

Re: IBM Stops Server Side Swift Framework Development

#80

Post by stoicShell »

bsaul wrote: post #72
K0SM0S wrote: post #63

Earlier quoted context omitted.

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