[HN Gopher] Apple announces full Swift rewrite of the Foundation...
___________________________________________________________________
Apple announces full Swift rewrite of the Foundation framework
(2022)
Author : frizlab
Score : 250 points
Date : 2023-01-11 15:01 UTC (7 hours ago)
(HTM) web link (www.infoq.com)
(TXT) w3m dump (www.infoq.com)
| justinator wrote:
| [flagged]
| gl-prod wrote:
| anyways
| Octokiddie wrote:
| The article quotes this:
|
| > With a native Swift implementation of Foundation, the framework
| no longer pays conversion costs between C and Swift, resulting in
| faster performance.
|
| and this:
|
| > A reimplementation of Calendar in Swift is 1.5x to 18x as fast
| as the C one (calling from Swift in various synthetic benchmarks
| like creation, date calculation).
|
| First, that range of 1.5x-18x is kind of huge. Why?
|
| Second, why would the intro with C be such a big performance
| penalty even assuming it's just 1.5x? I know there must be an
| overhead, but why so large?
|
| Also, why single out the Calendar? Is it somehow representative?
| vkou wrote:
| More importantly, why single out something like date
| calculation? Does that really eat a meaningful number of CPU
| cycles that needs to be optimized?
| dvh wrote:
| I know nothing about their c codebase but I assume it's because
| when the language is hard, you tend to keep it as simple as
| possible. When every line stops being a foot gun, you start
| using optimizations you wouldn't dare before.
| wlesieutre wrote:
| Similar post by Michael Tsai with some quick summary points of
| the impact of this:
|
| https://mjtsai.com/blog/2022/12/12/the-swifty-future-of-foun...
| ofcourseyoudo wrote:
| Thanks for that, always appreciaet Tsai's perspective and this
| part stuck out to me:
|
| >it sounds like the plan is to rewrite it in Swift and extend
| Swift to allow Objective-C to call the Swift implementation of
| the old API
| phillco wrote:
| I really like his style of 1) summarising articles he links
| to 2) attaching follow up from elsewhere on the internet,
| it's a nice pattern I'm surprised hasn't been more widely
| copied
| eatonphil wrote:
| I don't know Swift too well but my impression is that the support
| on Linux within the Foundation is not complete. (Also, is
| Foundation the same thing as what one might normally term a
| standard library? I can't tell.)
|
| Does this change imply better (eventual) support on non-Darwin
| systems? Or maybe I've misread it and the change is unrelated.
| mplewis9z wrote:
| > my impression is that the support on Linux within the
| Foundation is not complete
|
| It is not, but it's like 95% of the way there in my experience
| - most things that are missing are relatively recent additions
| that have some complex OS interactions, like filesystem I/O
| with language-level concurrency features.
|
| > Does this change imply better (eventual) support on non-
| Darwin systems?
|
| Yes. The non-Darwin Foundation version is already rewrite that
| takes a lot of effort to keep in lock-step with the closed-
| source Objective-C version, so unifying the implementations in
| Swift will both reduce the amount of maintenance effort and
| promote non-Darwin platorms to more of a "first-party" status.
|
| > Also, is Foundation the same thing as what one might normally
| term a standard library?
|
| It's more of a standard library++, including some things that
| other languages include in their standard libraries (Date/Time
| models) but also other things that are common to put in third-
| party libraries (networking, etc.). You do not need to use
| Foundation for basic things like arrays or concurrency that are
| built into the normal standard library.
| avisser wrote:
| <bikeshed> It feels off to call things like Array part of any
| library when you have array literal syntax `let oddNumbers =
| [1, 3, 5, 7, 9, 11, 13, 15]`
|
| I'd call that a language feature. Or maybe with Swift there
| is a blurry line between the two?
| mayoff wrote:
| Array is defined in the Swift standard library, but the
| compiler knows about the type directly, and also recognizes
| various @_semantics("array.blah") annotations that appear
| in the standard library source code. I believe the
| semantics annotations are primarily to help the optimizer.
|
| https://github.com/apple/swift/blob/main/stdlib/public/core
| /...
| saagarjha wrote:
| Arrays are part of the Swift standard library. Foundation
| is another library that provides access to things like I/O,
| networking, calendars, etc.
| eatonphil wrote:
| > complex OS interactions, like filesystem I/O with language-
| level concurrency features.
|
| Do you mean like io_uring? That wouldn't be too surprising.
| Even Go doesn't have that in the standard library yet.
|
| > so unifying the implementations in Swift will both reduce
| the amount of maintenance effort and promote non-Darwin
| platorms to more of a "first-party" status.
|
| That's what I was hoping for. Thanks!
| pkulak wrote:
| Swift is great because it's the only alternative to Objective
| C. I don't really think anyone is clamoring for it to move into
| non-Apple domains.
| frizlab wrote:
| I know I do. Swift is an amazing language, truly.
| klodolph wrote:
| Foundation is more like a standard library for Objective C.
| Some components are not needed in Swift.
| dcow wrote:
| For high level applications, Foundation is almost always
| imported and can pretty much be assumed. It's kind of a de
| facto standard library extension. The problem as you put it is
| that what's available on macOS/iOS is not fully available on
| other platforms. So you can't just take some software that uses
| Foundation and compile it for a non-apple system without
| potentially running into a bunch of things you need to
| implement or polyfill or whatever you want to call it.
| Foundation has been growing its support for other platforms
| over the years, so the situation has been getting better. But
| it's been hard to take the "open source cross platform" goal of
| Swift seriously when they there is clearly a priority given to
| apple platforms.
| birdymcbird wrote:
| Someone knowing existing pattern help me understand this. right
| now when i use these "foundation" apis in swift it is doing c
| call? so they rewriting now the c code in swift? (dont do ios or
| mac code so now sure)
|
| me dont understand what make it faster now. i once wrote some jni
| code to call c++ library from java. does mean there some similar
| code to do cross language call? they get rid of it and so things
| now faster?
|
| offtopic but debugging crashes in c++ over jni call was super
| hard. logs not work and me not figure out how to fix. wonder if
| they had similar "troubles" and this make everything easier :)
|
| always feel skeptical when seeing large code base have "rewrite".
| try many time in me career thinking there good reasons but super
| hard and not best value in end
| saagarjha wrote:
| Most of Foundation on Darwin used to call into Objective-C
| code. This is going to be replaced with Swift code while
| keeping the API the same.
| Reason077 wrote:
| Conversely, will existing Obj-C (and hybrid Swift/Obj-C) apps
| be able to call the new Swift Foundation?
|
| And will it be binary-compatible with existing apps, or will
| Apple just ship a separate compatibility version of
| Foundation for use by legacy apps?
| machinekob wrote:
| It's a lot of obj-c/c on apple and syscalls on other platforms,
| I think the biggest point its to get rid of annoying obj-c
| calls and make it fully cross platform as its a nightmare for
| both safety and performance in many cases to call objc.
| meitham wrote:
| Could someone please explain what exactly is the "Foundation"?
| oneplane wrote:
| It's the base framework where types like NSObject, NSString,
| NSDictionary etc. are defined. It's right there in the article.
| It also explains why it exists, what others exist, and what a
| rewrite will bring.
| wahnfrieden wrote:
| The Foundation framework is a cornerstone of most macOS and iOS
| apps, providing a large number of ubiquitous abstractions,
| including NSObject, NSString, NSArray and NSDictionary, and
| many more.
| KyeRussell wrote:
| It's not respectful to not read the link and instead ask
| somebody to summarise it for you.
| meitham wrote:
| You're making the wrong assumption! I have read the article
| before I asked, and still have no idea what it is! Saying it
| provides these abstraction NSObject, NSString, NSArray tells
| me nothing! The article is clearly written towards readers
| familiar with Apple ecosystem.
| Bud wrote:
| [dead]
| the_solenoid wrote:
| Todd, you owe me $20.
|
| (Todd said this would never happen)
|
| Also, this is great news, and it will be interesting to see what
| kind of real-world changes in performance this has.
| hinkley wrote:
| I really should have started using Long Bets years ago.
|
| Ten years ago a "Tanya" told me she would _never_ use an ebook
| to read literature. I'm pretty sure if I went to her house
| today I'd find 2. In fact I may be the only person I know who
| doesn't own one (not wanting one and being fundamentally
| against them are two different things).
|
| That's the most memorable but I've had these sorts of "over my
| dead body" conversations on a hundred topics over the years.
| xwowsersx wrote:
| Had never heard of Long Bets, I really like it
| (https://longbets.org/ for others who, like me, were
| unfamiliar). Is there a way to see the month and day of month
| when the bet or prediction was made? I can see the duration,
| e.g. "Duration 4 years 02017-02020", but don't see the actual
| date.
| eimrine wrote:
| Maybe Tanya reads a lot of PDF as kind of default format for
| all kinds of technical things and very common format for
| downloadable ebooks. AFAIK ebook readers are terrible in pdf
| rendering.
| deathanatos wrote:
| > _AFAIK ebook readers are terrible in pdf rendering._
|
| They're not really comparable formats. PDFs are documents
| rendered onto virtual paper: there is only so much a mobile
| device can do there, as a PDF is likely rendered as an 81/2
| by 11 or A4, which isn't going to be great on a tiny mobile
| screen. Bad tradeoffs between tiny text or pan-and-scan.
|
| eBooks, OTOH, are reflowable: ePub is "just" a ZIP of
| HTML1. But the viewer can lay them out appropriately, so
| they can be formatted to fit your device, whether that's a
| tablet, a phone, or something else.
|
| IMO if you want to read something on a device, ePub > PDF
| for those reasons. PDF is good for print, & ensuring that
| what comes out of the printer has a shot at resembling the
| screen. (Though there are a good number of print settings
| to mess that up, too.) And, as a passably portable document
| format, if you're just doing short term viewing or
| something.
|
| 1Plus a lot of other metadata that I'm eliding; it's a fair
| bit more complicated, of course.
| [deleted]
| mpweiher wrote:
| Things will get even slower.
| zuhsetaqi wrote:
| Why do you think it'll be slower? The article says the
| opposite
| KerrAvon wrote:
| Available data so far seems to show that the pure Swift
| implementations are faster than the Objective-C ones even
| when called from ObjC clients.
|
| I don't have a link, so feel free to treat as hearsay, but
| FYI.
| mpweiher wrote:
| You don't have a link to the data because this is not true.
|
| Swift is generally slower than Objective-C, often
| significantly so. There are cases where it is faster, but
| those are rare.
|
| Yes, I have measured.
|
| One example is JSON and Swift codable, which is comically
| slow, see:
|
| _Somewhat Less Lethargic JSON Support for iOS /macOS, Part
| 1: The Status Quo_
|
| https://blog.metaobject.com/2020/04/somewhat-less-
| lethargic-...
|
| Punch line: Swift codable does around 10MB/s, despite all
| the supposed performance goodies and compiler support
| everyone always talks about and nobody appears to ever
| measure. A pure Objective-C implementation does 284MB/s.
|
| I also did a more general survey for my book[1]. While
| that's been a while, I haven't seen any indication that
| things have fundamentally changed, and lots of indications
| that they haven't.
| acdha wrote:
| What are you basing that on? It seems unlikely that they'd
| reverse the ongoing trend of improved performance, especially
| at a time when they're shedding backwards compatibility
| concerns with the migration to ARM removing the least-
| maintained apps.
| klodolph wrote:
| Just to explain why Objective C code, in practice, is not
| especially fast:
|
| You generally make the choice between writing something in
| pure C, which gives you plenty of performance but little
| safety, or using Objective C classes and methods, which gives
| you plenty of safety but you're paying the price for dynamic
| dispatch (objc_msgSend) and pointer indirections all the
| time.
|
| Swift makes it easier to eliminate things like dynamic
| dispatch while still keeping the safety. So it should be
| normal and expected that a rewrite from Objective C to Swift
| would result in a speedup (and increase in code size).
| dilap wrote:
| In practice would be what the resulting apps turn out like.
|
| In my experience, old-school ObjC iOS and Mac apps
| generally tended to be quite snappy.
|
| On the other hand, the new Swift hotness of Messages and
| Settings on macOS are noticably slower than what they're
| replacing.
|
| Of course I haven't done a comprehensive inventory, but I
| certainly don't have the general impression of things
| getting faster with Swift. (Are there examples of this?)
|
| My guess is any theoretical gains are generally swamped by
| the language culture of complex abstractions.
| saagarjha wrote:
| Messages is largely an Objective-C codebase.
| dilap wrote:
| Ah, my bad, I just assumed the new version would be in
| Swift.
| klodolph wrote:
| Somebody rewrote an app in Swift -> the app is slower.
|
| Somebody rewrote a library in Swift -> the library is
| faster.
|
| There's a lot to talk about and unpack here. My
| experience is that people develop a different mindset
| when they do library development, because any code that
| they write will be code that they're forced to support
| for decades to come. You put bad code in an app and you
| can simply rip it out with the next revision, no
| questions asked. So you are much more likely to end up
| with questionable code in an app than in a library.
|
| I'm also old enough to remember not only the same
| complaints when people were rewriting apps into Objective
| C (lots of early Mac OS X apps were Carbon, including
| Finder), but when the same complaints were made about
| rewrites from assembler into C. Every decade your
| computer has a hundred times more computing power and
| your code takes 10x as much footprint, so you come out
| ahead, on average. It's just that any given year you
| might come out behind.
| mpweiher wrote:
| While this is what a lot of people believe, it happens to
| not be true.
|
| For more details, see _iOS and macOS Performance Tuning:
| Cocoa, Cocoa Touch, Objective-C, and Swift_ , Addison-
| Wesley
|
| https://www.amazon.com/iOS-macOS-Performance-Tuning-
| Objectiv...
|
| If you don't want to read a book, here is an example as a
| series of blog posts:
| https://blog.metaobject.com/2020/04/somewhat-less-
| lethargic-...
| klodolph wrote:
| I read the blog post, but it just seems to provide a
| single example of a case where some particular piece of
| Objective C code was faster than the equivalent piece of
| code in Swift. Maybe there's something I'm missing
| here... what should I be looking for in these blog posts?
| lostlogin wrote:
| What has been getting slower for you?
| macinjosh wrote:
| I was in a line once at WWDC in 2011. I happened to be in front
| of a group of Apple engineers. I overheard them discussing a
| rumored functional-ish language that Apple was to switch to from
| Obj-C. They didn't know what it was but they seemed skeptical
| that it would ever be put into real use. Glad to see it only took
| 11 years for it to permeate down to the Foundation framework. :)
| [deleted]
| whimsicalism wrote:
| Seems generous to describe as functional language, but I guess
| if you're coming from Obj-C...
| ChrisMarshallNY wrote:
| This will take a while, but I'm looking forward to it.
|
| It's probably another big step towards "Swift everywhere,"
| without worrying about bridging to C.
|
| I've been doing little but Swift since 2014, and really like the
| language. I'm still "on the fence" about SwiftUI, but that's
| mostly because of the level of support from Apple, and the _[im]_
| maturity of the system. This will help with that.
| qaq wrote:
| Waiting for things to settle down on the server side and will
| gladly use Swift for web APIs once dust settles as the lang is
| really nice for the most part.
| manmal wrote:
| Yes, and it means Swift scripts and modules that don't
| reference UIKit/AppKit/SwiftUI/Combine will run on Linux and
| possibly Windows with zero or little modification.
|
| I'm a little sad though that they didn't start this endeavor
| years ago, because IMO Rust has already built so much momentum
| that it will win (for the popular, medium to long term
| definition of ,,winning").
| password1 wrote:
| Why do you think Swift and Rust are competing on the same
| grounds or for the same objective? Genuinely curious, i don't
| know much about Rust.
| manmal wrote:
| I watched a Rust intro video recently that provided a
| perspective I liked, so I'll share that here: MS, Apple,
| Google (and more) all relied heavily on C for low level
| code that needed to be as performant as possible. It turned
| out though that C's memory management is so problematic
| that many/most security issues are caused by it. To address
| that, Google invented Go, Apple made Swift, Mozilla gave us
| Rust etc.
|
| MS is interesting - they tried to write memory safe C and
| invested heavily, but admitted defeat eventually - and
| started using Rust. And I think that's what will happen at
| most companies eventually. Rust has a lot going for it
| (faster than C sometimes, excellent WASM support etc).
| Swift might have been another contender, but Apple kept
| things too close to their chest for too long IMO.
|
| As another poster wrote, Swift certainly won't die at Apple
| (and their ecosystem), and Google will certainly keep Go
| alive. But I think Rust will eventually be used at
| many/most other companies for anything security or
| performance critical. Maybe it will replace C as the de
| facto low level language.
| msk-lywenn wrote:
| I used rust for a while. When I saw and read about swift,
| my immediate thought was: "hey, this looks like rust's easy
| mode"
| nicoburns wrote:
| Aside from Swift having automatic reference counting, and
| Rust relying more heavily on its borrow checker, Swift and
| are super similar languages. If what you want is an
| ergonomic language that lets you combine the best of ML
| type systems with C family imperative programming then
| they're the two obvious choices.
| kybernetyk wrote:
| I would not describe Rust as being particularly
| ergonomic. While it is a suitable replacement for C++,
| that is not necessarily a high standard to meet.
| jakewins wrote:
| The segment in this interview where Chris talks about Rust
| and compares the design decisions they made in Swift tied
| the two languages closely in my head: https://atp.fm/371
|
| the section on the future hopes for Swift similarly; it
| seems both Rust and Swift contend to replace C++ in many
| use cases
| ChrisMarshallNY wrote:
| I don't particularly care, whether or not Swift ever leaves
| the Apple ecosystem (like ObjC). In that domain, Rust will
| never "win." I think that Rust is an awesome server language,
| though, and I'm glad to see it gain traction. I just hope
| that it doesn't get trashed by a bunch of junk dependencies,
| written in it.
|
| I find using apps written, using hybrid systems, or PWAs, to
| be quite painful (on Apple devices -and that includes that
| awful JS TVOS system), so I am a big proponent of _real_
| native apps.
| [deleted]
| manmal wrote:
| I think whoever ,,wins", it would be necessary to have good
| interop at least. Currently, Rust devs are integrating core
| libs into native iOS apps by going the C route. All this
| work to make everything memory safe, and then this.
| mplewis9z wrote:
| > Yes, and it means Swift scripts and modules that don't
| reference UIKit/AppKit/SwiftUI/Combine will run on Linux and
| possibly Windows with zero or little modification.
|
| This is already pretty much true today, aside from the few,
| mostly down-in-the-weeds holes in Foundation on Linux that
| will be solved once this rewrite is complete.
|
| Cross-platform command-line tools, web backends, and things
| like AWS Lambdas are all possible and pretty easy to do
| today.
| hyperhello wrote:
| "A reimplementation of Calendar in Swift is 1.5x to 18x as fast
| as the C one (calling from Swift in various synthetic benchmarks
| like creation, date calculation)."
|
| I'm sure it is, but this is not solving the right problem at all.
| Calendar is all UI. It needs to be lovingly gone over, not this.
| mpweiher wrote:
| Note the somewhat disingenuous performance claim:
|
| The reimplementation itself is _not_ 1.5x to 18x as fast as the
| C one. It is calling from Swift that is faster.
|
| Yes, they correct in the parenthesis, but that's not how
| parenthetical expressions work:
|
| _A parenthetical expression is extra information added to a
| sentence or question that clarifies, explains, or adds
| information without changing the basic meaning. Think of it as
| an aside providing readers with helpful information that they
| don't absolutely have to have, but that is helpful to them._
|
| https://grammar.yourdictionary.com/style-and-usage/parenthet...
|
| So basically, they are fixing the problem they've been having
| with bridging performance, which of course is due purely to
| them mis-designing Swift in such a way that it doesn't bridge
| well with all the existing code they have.
| dev_tty01 wrote:
| No, I think you are misunderstanding the parenthetical claim.
| They are still benchmarking the actual reimplementation, they
| are just parenthetically pointing out that the
| reimplementations are being called from Swift, not Obj-C.
|
| The reimplementation itself is 1.5x to 18x. They are using
| the parenthetical in precisely the way the style and usage
| guide suggests, adding the additional information that the
| new implementation is called from Swift.
| stephencanon wrote:
| That quote is talking about the Foundation type named Calendar
| (https://developer.apple.com/documentation/foundation/calenda..
| .), not Calendar.app.
| newZWhoDis wrote:
| Calendar/Date is the foundation for all time handling in iOS
| apps. If you see a string with a date in it it was probably
| handled by this system.
| jeremy_wiebe wrote:
| This post is referring to NSCalendar and Swift's Calendar
| class.
|
| > NSCalendar objects encapsulate information about systems of
| reckoning time in which the beginning, length, and divisions of
| a year are defined.
|
| > The Swift overlay to the Foundation framework provides the
| Calendar structure, which bridges to the NSCalendar class.
|
| https://developer.apple.com/documentation/foundation/nscalen...
| w10-1 wrote:
| Correction: rewrite of PARTS of Foundation
|
| There already was an open-source project to rewrite ALL of
| foundation, but it had stalled on the shores of having to re-
| implement everything:
| https://github.com/apple/swift-corelibs-foundation
|
| The news is actually that Apple is now instead trying to define
| the bits/parts to support via Swift on all platforms (the
| original API's will always be supported on Darwin).
|
| The announcement:
| https://www.swift.org/blog/future-of-foundation/
|
| The discussion, with hairy details about which bits, esp. for
| async: https://forums.swift.org/t/what-s-next-
| for-foundation/61939/103
|
| The plan is to divide up Foundation into more- and less-essential
| parts, to get more-essential parts locked down so people can rely
| on them.
|
| What's Foundation? Swift's most-core library is the stdlib,
| tightly coupled to the compiler/language version, providing
| things like arrays, dictionary, etc., and available wherever
| Swift is. Beyond that, Foundation is the library with core API's
| for common features, e.g., for dates and concurrency. Stdlib is
| fully cross-platform and Swift-specific, but Foundation is a
| beast with API's dating to NExT with support for 20 years of
| API's.
|
| Microsoft famously arrived at porridge for an operating system by
| maintaining backwards compatibility. Apple has cracked open Swift
| by developing in the open, but it's still Apple-funded and Apple-
| driven. Library and some integration support for other platforms
| has always had to come from community (notably compnerd's heroic
| effort to make-things-work on windows, and a revolving cast
| wanting Linux support for their server API's).
|
| But there's no good reason to impose the whole Foundation history
| on other platforms. And there may be a movement inside Apple to
| migrate internal code to newer async API's, designed after the
| recent Apple-silicon generation.
|
| For developers with server experience and some free time in a
| tech lull, it could be a good opportunity to help rebuild a new,
| er, foundation for computing on all devices, that's native but
| type- and memory-safe. The community is large and mature, but
| there is plenty of room for others.
| [deleted]
| [deleted]
| smoldesu wrote:
| It simply sounds like there isn't much demand for Swift from
| the Open Source community. Apple certainly makes a big push for
| it internally, but outside their platform, Swift doesn't have
| much momentum.
|
| If Apple wants people to use Swift like a first-class runtime,
| they should stop treating third-parties like second-class
| citizens. They have $200 billion dollars in cold, hard cash -
| surely some of it could go towards the selfless development of
| a universal future computing platform, right?
| gernb wrote:
| They want lock-in. If you write something in Swift and it's
| not easily portable to other platforms then you might decide
| porting is not worth the effort.
| oblio wrote:
| The proprietary mobile OS vendor for which you have to use
| their proprietary desktop OS to build apps isn't popular in
| the open source crowd? Shocking, really.
| [deleted]
| KingLancelot wrote:
| 9 years after the created this language they're only now
| beginning to do this?
| [deleted]
| dcow wrote:
| I am pretty certain that _most_ of high level use cases for Rust
| could be replaced with Swift, with increased developer velocity,
| if Swift was actually cross platform. And that 's coming from a
| Rust fan. It will be interesting to see how effective this
| rewrite is.
| [deleted]
| rattray wrote:
| Interesting. Asking as someone who's never programmed with
| Swift or Rust, but is familiar with the syntax/ideas of each,
| I'm curious why you say that?
| dcow wrote:
| If you don't care about performance and "zero cost
| abstractions" and are more interested in Rust for its memory
| safety, then most of your Rust programs end up with a lot of
| syntactic and library bloat to add those "costly" (but
| convenient) abstractions back in, like explicitly cloning or
| wrapping types in Rc and Arc or just always taking ownership
| of borrowed data by constructing owned types with it. And
| then there are lifetimes which can be and are elided in
| almost all uses cases so they're ultimately just confusing
| whenever you actually have to deal with them. C.f. Swift,
| where the default is in my experience what "higher level"
| rust programs end up looking like, but with much nicer and
| cleaner syntax. And Swift has a very nice rather memory safe
| API for calling into C or otherwise just generally accessing
| scoped pointers when needed. This same api can actually be
| used to expose more performant apis to underlying data etc.
| when needed. It's kinda the reverse of Rust.
|
| It feels like Rust is two languages in one: a high
| performance zero cost abstraction language that tracks
| pointer ownership, and a package rich and hyper explicit
| application language build atop all the guts. That's why I
| say high-level application use cases, because most high-level
| applications are not concerned with raw performance but
| rather with functionality and user experience. The parts that
| are concerned with throughput can be implemented using
| tooling where those knobs are available. I have enjoyed
| writing a cli and api server and various libraries in Rust.
| But every so often I am left wondering when Swift might be
| able to replace it for my higher level concerns.
| Alternatively, it would be neat to see some effort put behind
| a "convenient rust" type of compile mode for modules where
| you could compile with things like implied clones, unified
| owned vs reference types, auto-arc/box, etc.
| yyyk wrote:
| >If you don't care about performance and "zero cost
| abstractions" and are more interested in Rust for its
| memory safety...
|
| Just about GC language has similar tradeoffs. The question
| here would be why Swift over Go/C#/Java/Python/Typescript?
| rattray wrote:
| Makes sense, thank you for explaining!
|
| Personally I'd love to see a forked flavor of TypeScript
| with static compilation and multithreading (which implies a
| lot more immutability, etc). Maybe I should give Swift a
| try...
| etse wrote:
| How would you compare Swift with Kotlin in terms of being a
| good stand-in for high-level Rust?
|
| I've not paid attention to Kotlin in a while, but it seems like
| there's more progress at supporting Kotlin across more
| platforms (Kotlin native, web?, etc). I'm curious if people
| feel that the language features and design are at about parity,
| or if one is significantly stronger/weaker.
| dcow wrote:
| I haven't seriously used Kotlin in 4-5 years. I too was
| excited about it supporting native compiles and web assembly
| but I have no firsthand experience with how far those efforts
| got.
| manmal wrote:
| Last time I toyed with Kotlin Multiplattform (bit less than a
| year ago) it provided only really weird Objective-C bindings
| for use in iOS/macOS. Like, a statically defined List turned
| into an Obj-C iterator. Enum and sealed classes were quite
| problematic either - I honestly would not consider using KMM
| for anything but a PoC.
|
| BTW, JetBrains recently sunsetted AppCode, so they are
| bleeding their Swift talent now. I suspect that doesn't bode
| so well for Kotlin's Swift interop.
| neonsunset wrote:
| Another scenario where an often missed and underrated choice
| would be C#.
|
| Nowadays it runs everywhere and supports a variety of
| deployment targets (relying on local runtime, packaging it
| together into a single somewhat compact binary, natively
| compiling the code (NativeAOT, it's good but has some
| limitations) or mixing and matching all of the above).
|
| It is also one of the best high-level languages to write
| performance-oriented code with, especially so with .NET 7
| which allows writing cross-platform SIMD code in a similar
| fashion to Rust's 'portable-simd' crate.
| kitsunesoba wrote:
| My experience is probably colored by .NET/WinUI but when I
| was dabbling in writing a Windows desktop app a few months
| ago I can't say I loved C#. My background has no Java in it
| so maybe that's why, but a lot of things that come standard
| as part of Swift seem to be in external libraries with
| .NET/C#, and it felt like some things were different for
| the sake of being different. Point in case, with Swift and
| Kotlin I've gotten used to chaining various transformation
| functions (map, compactMap, flatMap, filter, sort, reduce,
| etc) and some of these don't have a 1:1 equivalent in C#
| which was a huge hit to productivity, even if the same
| result is achievable via other means.
|
| And while it's tangential, Xaml drives me absolutely
| bonkers. It's like the worst parts of iOS Storyboards and
| Android Framework XML layouts except there's no escape
| hatch for those looking to build a UI in pure code (Android
| Framework is a bit of an offender here too, but Jetpack
| Compose looks to remedy that).
| FlyingSnake wrote:
| > _some of these don 't have a 1:1 equivalent in C# which
| was a huge hit to productivity_
|
| This is interesting because all these magical functions
| (zip, map, Rx etc) have roots in LINQ which sprung from
| .Net world. I find it hard to believe that the battle
| tested CLR and C# doesn't have the equivalent functions.
| lmm wrote:
| > all these magical functions (zip, map, Rx etc) have
| roots in LINQ which sprung from .Net world
|
| No they don't. They're essentially unchanged from ML back
| in the 1970s. The part that was new in C# was the SQL-
| like syntax on top of them, and most subsequent languages
| haven't considered that worth adopting.
| neonsunset wrote:
| All these are part of standard library. Map is Select,
| Filter is Where, Reduce is Aggregate, etc. You can write
| C# in a functional style easily, it is one of the
| premiere features.
|
| UI frameworks on the other hand...I feel your pain.
| kitsunesoba wrote:
| I did find and use Select and Where at least, but I
| recall running into caveats with them or with their
| interactions with other parts of the language that meant
| that they couldn't be used identically. I don't remember
| specifically what it was since it's been a while but I
| remember it being frustrating. I should probably find a
| cheat sheet of equivalents if I try writing it again.
| kitsunesoba wrote:
| Kotlin is about as nice as Swift until you run into some bit
| where it's interfacing with Java and then it becomes a lot
| less fun. Swift I think handles Obj-C/C interior a bit more
| gracefully by comparison. Various bits of other JVM baggage
| also aren't great.
|
| That said I've only used Kotlin in the context of Android
| development. It might be nicer elsewhere.
| eatonphil wrote:
| Swift has the distinction (for better and worse) of not being
| tied to the JVM.
| dcow wrote:
| Kotlin-native is an effort to compile directly to your
| target non-jvm machine.
| FlyingSnake wrote:
| Apart from language syntax similarities, Kotlin and Swift are
| fundamentally different languages, one runs on a VM (ok
| there's KNative) and other runs on bare metal.
|
| Kotlin has it's roots in JVM and the early language design
| choices clearly reflect that. Kotlin/Native will find it very
| hard to break free of it's JVM counterpart because it can't
| diverge too much from it to maintain compatibility.
| seanalltogether wrote:
| I think the fact that Rust won't provide inheritance based OOP
| workflows means that something like swift will always be
| valuable, especially for application development.
| Gigachad wrote:
| What is the value provided by inheritance? It was my
| understanding that this was deliberately excluded from Rust
| as it's now seen as a bit of an anti pattern mostly inferior
| to traits.
| sacnoradhq wrote:
| None. It's code organizational syntactic sugar and
| abstraction that incurs a runtime penalty (vtables).
|
| Go ditched OO for similar reasons.
|
| Haskell, Erlang, and more get along fine without OO.
|
| (OO crested with Smalltalk, Java, Ruby, Python, and JS
| (more prototypal though). Let's not talk about C++98)
| FlyingSnake wrote:
| If the foundation is rewritten in Swift, it will become a very
| potent alternative to Rust for this use case. Swift+LSP has
| good enough IDE support and the developer experience and
| debugging capabilities should make possible.
| ChubbyGlasses wrote:
| Swift and Carbon both seem like very strong contenders in this
| space. Swift is already a really strong language albeit a
| little too tied to Apple's ecosystem. This along with the
| ownership manifesto slated for Swift 6 (and C++ interop) should
| make it easier to use it everywhere. In particular, I see a lot
| of value for tooling (eg JS code bundlers and such) that are
| rewritten in "thinner" languages for performance needs without
| sacrificing developer productivity.
| pkulak wrote:
| I don't know if you can write high-throughput systems with 100%
| reference counted GC. Swift is targeted at UI work pretty hard.
| [deleted]
| dcow wrote:
| Well that's why I said high level application use cases and
| not systems. Ideally I'd love to see a compile mode for
| modules where certain conveniences were enabled like: auto-
| clone, unified reference/owned types, disabled lifetimes and
| instead borrows become auto-wrapped-arcs, etc. That way you
| could care about that stuff in modules where it matters, and
| ignore it in areas where you prefer convenience over zero-
| cost abstractions and raw performance.
| georgelyon wrote:
| You could take a look a swift-nio
| (https://github.com/apple/swift-nio) which is a pretty high-
| throughput system. swift-nio does this using _some_
| reference-counted GC where it simplifies the code and doesn
| 't affect performance. Otherwise, value-types are used which
| incur no GC overhead (unless they are copy-on-write, and
| backed by something that requires reference counting).
| lmm wrote:
| > I am pretty certain that most of high level use cases for
| Rust could be replaced with Swift, with increased developer
| velocity, if Swift was actually cross platform.
|
| Sure, or really OCaml or any other language with ML-family
| features (other replies have already mentioned Kotlin or C#).
| But the fact that it took Rust to get adoption and not OCaml
| suggests that it's not language functionality that drives
| adoption; Rust has something that those languages don't. (My
| theory is that it succeeds by being the first decent language
| that can match C's performance-on-silly-microbenchmark numbers)
| kitsunesoba wrote:
| I would love to be able to write cross-platform desktops apps
| in Swift. The language isn't perfect of course but I enjoy it a
| lot more than the alternatives I've tried.
|
| That possibility is still a ways down the road of course but
| Foundation getting a cross platform rewrite is a nice step in
| that direction.
| rattray wrote:
| If you or others on this thread are interested in working on
| a Swift compiler for Windows, please reach out to me :) a
| good friend is hiring a team to make this happen.
| Someone wrote:
| How will that be different from Apple's Swift toolchain for
| Windows (https://www.swift.org/blog/swift-on-windows/)?
| rattray wrote:
| https://youtu.be/bOMQiMxh5Bc?t=430
|
| relevant listen is about 2min long
| Someone wrote:
| To me, that sounds as if most of the work would not be on
| the compiler but on improving the development experience
| (IDE, debugging support).
|
| On the other hand, your comment said _"working on _a_
| Swift compiler for Windows"_. To me, that sounded like a
| new compiler, not adding missing features to the existing
| one. Which of the two is it?
| theLiminator wrote:
| Afaik Swift is pretty close to using Rc and Arc everywhere.
| Does swift do some more escape analysis than Rust?
| janef0421 wrote:
| Swift only uses reference counting when working with objects;
| Structs are optimised using copy-on-write. There's currently
| work on implementing move and ownership semantics, similar to
| Rust, but opt-in rather than by default.
| manmal wrote:
| I haven't read that much on Rust, but that should be pretty
| much it.
|
| Swift has an emphasis on value types, which often are stored
| on the stack, but only up to a certain size. Copy-on-write
| makes this feasible - often, those value types are passed by
| reference until a write actually occurs, but that's opaque to
| the dev. Value types can have pointers to reference-counted
| types - if a value type is passed/copied, any pointer it owns
| is retained (weirdly enough, they claim that value types have
| no ,,lifetime", but at some point those refs have to be
| released - we just have to trust the compiler in this).
| [deleted]
| Gigachad wrote:
| The removal of C from Android and iOS is going to pay off
| massively. The current state of things where every government is
| sitting on an endless collection of exploits is not ideal.
| smoldesu wrote:
| Considering that both Google and Apple are cardholding members
| of PRISM, it sounds like a bit of a frying pan vs fire
| situation to me.
| typon wrote:
| Yes, but that's OUR surveillance and we're cool with that
| davidkuennen wrote:
| Apple has such an unpredictable stance on software development.
|
| For example after all these years and lots of requests for such a
| feature it's still not possible to get notified about new reviews
| for your apps, but it's possible to get notified when a user
| edits a review after you've replied to it.
| [deleted]
| rufius wrote:
| Apple's style reminds me a lot of something I once read (and
| later experienced) about Japan and tourism:
|
| > (roughly) Japan is a country for the Japanese. While they may
| welcome you and invite you to experience their country and
| culture, the country is very much setup to serve the Japanese
| populace.
|
| Apple feels similarly. They build what they need and enough to
| capture the revenue they want, but I don't perceive them to
| really cater to external needs beyond what will monetize.
| threeseed wrote:
| > but I don't perceive them to really cater to external needs
| beyond what will monetize
|
| So then why does all of Apple's operating systems and apps
| receive updates at all.
|
| Your argument is completely illogical.
| pvg wrote:
| Very short discussion last month:
|
| https://news.ycombinator.com/item?id=33923484
| andrewmcwatters wrote:
| > A reimplementation of Calendar in Swift is 1.5x to 18x as fast
| as the C one (calling from Swift in various synthetic benchmarks
| like creation, date calculation).
|
| These sorts of statements in the industry always make me ask, "So
| did you guys make something terribly slow first, and then bring
| performance back close to where it originally was?"
|
| I'm not sure if the current Calendar app was ported to Swift, was
| originally Objective-C based, and such efforts to move Foundation
| to Swift will just... make Calendar fast again?
|
| Also, Calendar doesn't seem to be particularly slow in the first
| place. But I love performance engineering, and quality of life is
| big, so... hey cool.
| MBCook wrote:
| They're not talking about the app.
|
| They're talking about the Calendar class in Foundation.
| psmyrdek wrote:
| How prospective it is to jump on the iOS bandwagon in 2023?
| [deleted]
| bfrog wrote:
| So apple seems to be dropping c like languages, Microsoft says
| new stuff should not be written in c like languages anymore, and
| google has steadily worked towards using rust and go in place of
| c and c++ where it makes sense to do so it seems.
|
| There seems to be a trend here.
| phpisthebest wrote:
| >>Microsoft says new stuff should not be written in c like
| languages anymore
|
| Microsoft is dropping C#? Source for that?
| bfrog wrote:
| C# is a lot closer to Java if anything, should clarify to be
| c and c++
| mplewis9z wrote:
| Calling C# a C-like language is like saying JavaScript is a
| descendant of Java.
| babypuncher wrote:
| C# is C-like in syntax only.
|
| Syntax isn't the reason why C and C++ are falling out of
| favor.
| AppleBananaPie wrote:
| could be worded better but from context in the sentence I
| read that as c/c++
| jon-wood wrote:
| I think the GP probably poorly phrased that. "Memory unsafe
| languages" would be a better term, apart from the basic
| syntax C# really isn't very C-like.
| diroussel wrote:
| C# is not a C-like language. It's a managed runtime with
| garbage collection.
|
| However Mark Russinovich, CTO of Azure did say that it's time
| to drop C and C++
|
| https://twitter.com/markrussinovich/status/15719951172335042.
| ..
| ccouzens wrote:
| Based on the context I think by "c like" they meant languages
| with a culture of dealing with raw pointers. c# is c by name
| and curly braces, but primarily uses managed memory
| danielvaughn wrote:
| Forgive me, is swift not in the c family? I could have sworn
| that it was, but I'm not overly familiar with it.
| SimDeBeau wrote:
| It was built to interop well with obj-c which is a c
| superset, but it's not a c-family language more than
| something like c# or kotlin
| kibwen wrote:
| Lots of languages, including Java and Javascript, have been
| described as being "in the C family", but this papers over a
| whole lot of important details. Swift is a low-ish-level
| imperative-ish language with C-ish syntax.
| obliquely wrote:
| You could just as plausibly say that Swift is a high-ish-
| level functional-ish language with a modern syntax. Whereas
| C blows up at runtime, Swift nags-and-whines at compile
| time - in that way it's very unlike C. All that said "in
| the C family" is highly ambiguous at best...
| BuckRogers wrote:
| When I hear that C family languages are no longer to be
| utilized, I'm assuming they mean memory unsafe options. C
| & C++.
|
| Everything else is just as good of an idea as the next. C
| family is the most successful language paradigm in the
| history of software. Abandoning those constructs would be
| suicide. Nothing would get done.
| pyth0 wrote:
| I would think it is. It runs on the Objective-C runtime and
| has interop with it and C.
| [deleted]
| lmm wrote:
| The writing has been on the wall for decades for anyone who was
| paying attention. But it takes time for a whole industry to
| shift.
| alberth wrote:
| What remaining Apple frameworks are not yet written in Swift?
| saagarjha wrote:
| Most of them. Very few frameworks are actually written
| primarily in Swift.
| alberth wrote:
| Would the macOS kernel (Mach) ever be rewritten in Swift?
|
| And if so, what benefit would it provide?
| [deleted]
___________________________________________________________________
(page generated 2023-01-11 23:00 UTC)