[HN Gopher] Swift Project in 2023
___________________________________________________________________
Swift Project in 2023
Author : Austin_Conlon
Score : 38 points
Date : 2022-11-18 17:37 UTC (5 hours ago)
(HTM) web link (www.swift.org)
(TXT) w3m dump (www.swift.org)
| Kukumber wrote:
| Apple has its own better Rust now
|
| Swift:
|
| - Servers
|
| - OS
|
| - Apps with a wonderful SwiftUI framework
|
| - C++ Interop
|
| - Ownership model
|
| - Crossplatform
| galangalalgol wrote:
| The c++ interop would be nice in rust. The main complaint I'd
| heard with swift was how slow it is, especially if you dont
| compile with -Ounchecked. So a lot slower than rust even with
| -Ounchecked, and with it, slower than gc languages in general
| ocaml haskell that sort of thing. Has that gotten better? If
| so, safety and performance with c++ interop would be nice.
| Arcanum-XIII wrote:
| Well, every time I heard about the SwiftUI it's to complain
| about the hidden complexity and difficulty to debug it. Not so
| sure it's a true plus! And it's only valid on Mac/iOS
| tarentel wrote:
| SwiftUI is about 90% production ready if you're targeting the
| latest OS. The other 10% can be very nightmarish though if
| you run into any issues.
| jakey_bakey wrote:
| SwiftUI was historically pretty dire to debug, but in the 3
| years since release it's come on in leaps and bounds - Apple,
| for once, released something before it was production-ready
| and actually listened to feedback
| dmitriid wrote:
| Is it a better Rust? The whole language evolution looks like
| "let's just throw things at the wall with random syntax, maybe
| it will stick" and "if syntax doesn't work, let's do random
| one-off constructs, and see if those stick".
| nativecoinc wrote:
| Programming languages, even so-called general purpose ones,
| really need to have a general niche. Swift is for application
| programming while Rust is for systems programming. Which
| doesn't mean that they can't do things in the other niche. But
| it does mean that they will not be used to such a wide extent
| that they will be seen as "better" than the other language for
| that opposite niche.
|
| One illustrative facts is that Rust in practice cares about
| each individual allocation. Meanwhile Swift has the wonderful
| value-semantics collection implemented by way of copy-on-write
| (cow) atomically reference-counted pointers.
| pjmlp wrote:
| From the point of view of Apple, Swift is also a systems
| programming language, it is even part of its official
| documentation.
| johnthuss wrote:
| Since it is open source and supports Linux and Windows too we
| all have it, not just Apple.
| Daedren wrote:
| SwiftUI is not open source and doesn't support other
| platforms.
| Kukumber wrote:
| SwiftUI is not Swift, it's a framework for iOS/macOS
|
| Swift is crossplatform, whether you like it or not
| pjmlp wrote:
| Languages alone don't matter.
|
| Swift's ecosystem is on Apple's platforms, and it is ok,
| plenty of jobs there.
| bsaul wrote:
| Swift isn't crossplatform by any stretch. _Some people_ may
| have succeeded in building reusable swift code across different
| platforms, but that was by going through a lots of hops, and is
| barely documented (i'm talking for example building a lib
| working on both ios and android, which requires creating your
| own toolchain).
|
| A recent post of the forum wanted to build a crossplatform
| working group, but as you can see in OP, it wasn't met with a
| lot of enthusiasm by the core team.
|
| Obviously, as long as apple is the only major corp behind
| swift, it isn't going anywhere outside apple platforms.
|
| The day rust reaches some kind of ergonomics acceptable to non-
| system programmers you can be sure swift will only be used for
| UIKit / Swift interfacing and that's it.
| msie wrote:
| Any website to follow who's doing extensive Linux programming
| with Swift and writing about it?
| runjake wrote:
| I'm not sure if any exist, but this link[1] pulls up this
| link[2].
|
| 1. https://pinboard.in/t:swift/t:linux/
|
| 2. https://www.kodeco.com/8325890-a-complete-guide-to-swift-
| dev... (formerly raywenderlich.com)
| hazn wrote:
| I am fascinated by how the general community perceives swift. The
| PL theory community seems to appreciate its innovations, while
| the (online) dev community sees it as Apple's own C#.
|
| Ultimately, I think Swift is a hugely underrated language, mainly
| because of outdated criticism.
| d3nj4l wrote:
| > The PL theory community seems to appreciate its innovations
|
| I'm curious as to what these innovations are. I've not looked
| too deeply into Swift - I've played around with SwiftUI a bit
| and nothing else - but from what I saw I didn't see any
| fundamentally novel ways to do things. People talk about
| protocols/actors etc, but I've seen other languages that do
| those and (IMO) better. If anything, I thought the emphasis on
| creating new forms of syntax for things that should've been
| built as more fundamental, orthogonal concepts (eg. `guard let`
| etc.) would've made it more distasteful to the PL theory crowd,
| who love orthogonality IME.
|
| (I'm sorry if I'm coming off as sarcastic/combative, I'm
| genuinely curious about this!)
| favorited wrote:
| The Swift story around ABI stability and library evolution is
| pretty unique. Relatedly, its approach to generics doesn't
| fall into either of the 2 traditional paths (either box
| everything like Java and C#, or template instantiation like
| C++ or Rust).
|
| https://faultlore.com/blah/swift-abi/
|
| https://www.youtube.com/watch?v=ctS8FzqcRug
| cwzwarich wrote:
| The closest thing to Swift's approach to polymorphism in
| the academic world is intensional polymorphism:
|
| https://www.cs.cmu.edu/~rwh/papers/intensional/popl95.pdf
| hazn wrote:
| How Swift Achieved Dynamic Linking Where Rust Couldn't:
| https://faultlore.com/blah/swift-abi/
|
| Many programming languages list Swift as inspiration:
| https://www.val-lang.dev/
|
| Rust's optional bindings are inspired by swift:
| https://doc.rust-lang.org/reference/influences.html (Many
| people who worked on Rust also worked on Swift, like the
| creator of rust)
|
| The SwiftUI framework you mentioned uses inspiring syntax,
| which has been tried do be emulated (Jetpack Compose, Druid).
| However, nobody got it as magical as Swift did. The way
| SwiftUI Syntax combines pl theory and developer usability is
| amazing.
| pjmlp wrote:
| Val is being designed by former Swift devs, no wonder.
|
| Dynamic linking in AOT compiled languages exists for
| decades, other priorities in other ecosystems.
|
| Groovy DSL for Swing was one of the first languages with
| such approach.
|
| However all in all, it is a great language for the Apple
| ecosystem.
| FlyingSnake wrote:
| >nobody got it as magical as Swift did.
|
| I was with you till this line. SwiftUI was so half baked
| for several versions that it took them 3 years to get a
| respectable navigation API. SwiftUI is great but it still
| has rough edges.
| d3nj4l wrote:
| Thank you!
|
| The point on ABI compat is interesting - I guess that's the
| sort of thing that makes Swift truly an "end to end"
| language. Though at the same time, the focus on dynamic
| linking is a source of one common complaint with swift,
| IIRC - people often complain that the language features
| they use are tied to OS versions.
|
| > which has been tried do be emulated (Jetpack Compose,
| Druid). However, nobody got it as magical as Swift did.
|
| That's interesting, too. I'm not a UI programmer by any
| means, and from what little I tried of SwiftUI and JP
| Compose (though I have written more server-side Kotlin and
| found it perfectly pleasant) I didn't see a significant
| difference. Do you have any further reading I can look into
| this further?
| pjmlp wrote:
| Well, the fact is that it is as open source as Objective-C, and
| that it has hardly helped the latter without the frameworks
| that really matter.
|
| There is no issue in being Apple's C#, this is the only way for
| bringing safety computing forward, having the platform owner
| making it happen no matter what.
| johnthuss wrote:
| I don't think this is true. Apple provides a fairly
| substantial standard library along with the open source
| version of Swift, which they never did for Objective-C.
| pjmlp wrote:
| We have very different point of views what fairly
| substantial means, specially in absence of any Apple
| ecosystem key framework and XCode tooling.
| ofrzeta wrote:
| Open Source Swift will never become a language for
| graphical applications. Same problem as with Objective-C
| as you said. There's GNUstep but look how far they have
| come in decades.
|
| On the other hand a bunch of useful libs (based on said
| standard lib) for server-side Swift is realistic.
| pjmlp wrote:
| Server side Swift lags behind the competition and only
| makes sense for Apple shops to write their apps backends.
| bsaul wrote:
| Even for apple shops, it doesn't really makes sense. It
| is a myth to think that you can share anything of value
| between client and servers, except dumb data types that
| you'll probably want to define in protobuf anyway for
| various reasons.
|
| As for knowing the language, you'd gain the two weeks it
| takes to learn go, but you'll loose all the ecosystem of
| quality libraries.
| virgildotcodes wrote:
| Does this documentation workgroup focus also extend to the
| documentation of Apple APIs? The pessimist in me thinks no, but
| I'm hoping to be wrong.
| halfmatthalfcat wrote:
| I've very anxiously awaiting Swift on Server's
| development/maturity. My love for Scala/Akka (especially with the
| latest licensing changes) could potentially be replaced if they
| nail Distributed Actors.
| ofrzeta wrote:
| Did you take a look at Dotnet Orleans?
| bradhilton wrote:
| Glad to see they are still working on differentiable Swift.
| zapnuk wrote:
| Better AWS Lambda support would be nice. There is a runtime by
| the server workgroup but afaik it requires docker as an
| intermediate for compilation.
|
| If would be awesome if the cross compilation support is as good
| as it is in Go such that you could build your lambda executable
| with `GOOS=linux GOARCH=amd64 go build -o main main.go`.
___________________________________________________________________
(page generated 2022-11-18 23:02 UTC)