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

91–99 of 99 posts

Re: IBM Stops Server Side Swift Framework Development

#91

Post by taharvey »

wwright wrote: post #8
thrower123 wrote: post #7

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

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?

Re: IBM Stops Server Side Swift Framework Development

#92

Post by stoicShell »

bsaul wrote: post #85
stoicShell wrote: post #80

Earlier quoted context omitted.

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

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.

Re: IBM Stops Server Side Swift Framework Development

#93

Post by byt143 »

taharvey wrote: post #90
cbkeller wrote: post #65

Earlier quoted context omitted.

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=1…

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?

Re: IBM Stops Server Side Swift Framework Development

#94

Post by wwright »

taharvey wrote: post #91
wwright wrote: post #8

Earlier quoted context omitted.

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

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.

Re: IBM Stops Server Side Swift Framework Development

#95

Post by wwright »

zepto wrote: post #11
wwright wrote: post #8

Earlier quoted context omitted.

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.

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

Re: IBM Stops Server Side Swift Framework Development

#96

Post by gurkendoktor »

happytoexplain wrote: post #28
wwright wrote: post #8

Earlier quoted context omitted.

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

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

Re: IBM Stops Server Side Swift Framework Development

#97

Post by taharvey »

wwright wrote: post #94
taharvey wrote: post #91

Earlier quoted context omitted.

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…

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.

Re: IBM Stops Server Side Swift Framework Development

#98

Post by taharvey »

byt143 wrote: post #93
taharvey wrote: post #90

Earlier quoted context omitted.

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.

Re: IBM Stops Server Side Swift Framework Development

#99

Post by iLemming »

crymer11 wrote: post #30
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 /…

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