This proposal looks like it's from 2017 (there are more recent commits, but they are just typo fixes). It was briefly discussed here at the time: https://news.ycombinator.com/item?id=13669001
Anybody familiar with Swift development have updates on whether it went anywhere and what the current state is? As someone not in this particular loop, not immediately clear to me why a 6-year-old proposal was linked here.
I read Graydon's recent "If I were a BDFI" essay and found myself mostly sympathizing, especially with the "I wanted Rust to have potentially costly abstractions, because that's the point of abstractions, pay a known cost to solve common problems". It seems Rust was taken over by the "zero cost abstractions at all costs" crowd. Graydon seems at peace with that because it's what the community wanted. But I think it's also obvious that he was frustrated by the regression to the mean that comes with shared ownership/leadership.
Then I thought that what we really need is a Swift-like language with the ability to remove costly abstractions when you don't want to pay the cost, but that default to ergonomically solving the problems that the majority of programs need to solve. You should opt-in to more semantic complexity, not be encumbered by it by default. Rust's obsession with performance above all else confuses me. But I also guess it's nice to have a safe space for performance sensitive programmers. But like how can a systems language not have a stable ABI? Very mixed messages.
Ultimately this "Rust with better ergonomics" language could be Swift. I do think it is more usable across platforms than people give it credit for. But it's also missing the "let me dip down into lower level but more complicated semantics when I need to" option. Having a stable ABI is awesome, though. I really can't wait for the day where I can start a portable project in Swift without a second thought.
> Rust's obsession with performance above all else confuses me.
It's kind of a requirement if they hope to replace C/C++ as a systems language, as those remain the goto answer for "I need maximum control", short of assembly.
And they want to replace C/C++ to fix all their safety problems.
I work in embedded systems, where C remains a holdout, with all its problems. Rust's performance-oriented direction makes it a viable consideration for us.
My understanding of zero cost abstractions is that they predominantly happen at compile time (and thus commonly appear in language semantics or the type system) and literally cost nothing at runtime. This has other costs like semantic complexity, but almost never performance.
Regardless, I don't buy that Rust couldn’t present a more opinionated and complete programming experience without allowing the same performance characteristics that it has today. The whole async situation is awful. Lifetimes are a stupid leaky abstraction 99% of the time. My point is that there’s almost never a scenario where you e.g. need to bother with passing around a struct with a reference with a lifetime. 99% of the time you just take ownership of the data or use an Arc<Box<T>> and 99% of the time that’s not a performance problem. What I think is stupid is that Rust elevates and enshrines the 1% use cases and makes the 99% experience worse off for it. I love Rust. But it could do a better job of solving the 99% cases nicely while allowing a “zero cost escape hatch” where you could say “actually I do want a stack allocated reference without atomic reference counting” and pay the semantic price 1% of the time rather than 99% of the time, similar to Swift’s approach.
Obviously my experience had been shaped by the projects I’ve worked on. But I also think Swift is an entirely more ergonomic and practical language. If you think Rust is a viable option then, unless you’re anti-Apple, Swift with ownership semantics most certainly is too. Seriously.
I’m interested in how this works (this thread is now getting old so I’m not sure there will be replies…)
One of the important aspects of a stable ABI is the ability for clients to continue to work even after the size of a remote type changes… for instance, if Foo is a type defined in Foo.dll, and I link to it, and my code does `Foo *f = new Foo()`, the compiler will emit code that malloc’s `sizeof(Foo)` bytes on the heap. If later on, Foo gets a new member variable “m”, it will increase in size, and now code in Foo.dll will segfault if it tries to access `this->m`, if a client allocated it.
COM solves this by basically not letting you do `new Foo`, but instead you have to ask COM itself to allocate and return an instance for you, with something like `CoCreateInstance`. This allows .dll’s to evolve even if the size of the object changes, by abstracting away things like size information so that clients don’t care about it. ObjC solves this similarly with `[SomeClass alloc]`, where clients just ask the class to alloc itself and returns a pointer (which is delayed until runtime, not in the emitted code), and Swift solves it with value witness tables which delay the lookup of size/stride information until runtime.
I don’t understand how, you can write .dll’s with not only a stable ABI, but the ability to actually evolve your types, in plain vanilla C++… I think the language itself has painted itself into a corner that prevents things like this.
In what way? OS API’s can’t reasonably be copy/pasted into every binary on the system. It’s one thing to have large executables for third party apps you install, but you’d get tired of the wasted disk space really quickly if every binary in the OS had to statically link in the implementation of every library it used.
It’s not just disk space either, but the ability for an OS as a platform to swap out implementations of their API’s with new ones, without requiring every app to be recompiled. It’s the reason macOS is able to implement things like dark mode, or a new UI theme, or any other “horizontal” feature that works across all apps; you need dynamic linking for that to be possible.
The quality of implementation of the Swift compiler is in no way comparable to Rust's. It's super easy to cause its type check to timeout, which is something I haven't seen when using Rust. I even managed to make it crash several times. It also lacks some pretty standard features such as turning off warnings of a certain type or on a certain line. The language itself is quite problematic when compared to Rust, too. For instance, Swift doesn't have the orphan rule, so it's possible that 2 packages implement the same protocol for the same type, and when this happens currently there are no solutions; there is this strange design decision that classes and structs should be different things and each have their own set of random limitations; and there is SwiftUI, which hacks on the syntax itself, making statements no longer mean what they are supposed to mean.
> It's super easy to cause its type check to timeout, which is something I haven't seen when using Rust.
Yeah, the operator overloading design makes it too easy to construct an exponential search space.
> For instance, Swift doesn't have the orphan rule, so it's possible that 2 packages implement the same protocol for the same type, and when this happens currently there are no solutions;
> there is this strange design decision that classes and structs should be different things and each have their own set of random limitations
structs in Swift are the same as structs in Rust, and a class is a heap-allocated reference counted box, like an Arc<Box<T>>. What are the random limitations? As far as I'm aware the behavioral differences between structs and classes are entirely explainable by the above.
> and there is SwiftUI, which hacks on the syntax itself, making statements no longer mean what they are supposed to mean
> structs in Swift are the same as structs in Rust, and a class is a heap-allocated reference counted box, like an Arc<Box<T>>.
Yeah, and by representing the differences this way, Rust allows you to easily decide whether an object is used directly or is wrapped in a rc box when its used, instead of when it's defined, often not by you, and when you change your mind you don't need to change all methods or functions than mutates it and all their call sites.
> Result builders are a language feature and not part of SwiftUI
I admit that this is the first time I see the term result builders. This is never mentioned in any SwiftUI documentation I've seen, so I guess I should extend my complaint to include quality of docs :p. Whatever this is called you seem to agree that the syntax is hacked and it can get hard to understand what something means
> Yeah, and by representing the differences this way, Rust allows you to easily decide whether an object is used directly or is wrapped in a rc box when its used, instead of when it's defined, often not by you, and when you change your mind you don't need to change all methods or functions than mutates it and all their call sites
Changing a value type into a reference type is a pretty fundamental transformation because your local mutations now become non-local. Its not clear the Rust approach makes this any easier either, since you’d still have to update all call sites that perform mutation if suddenly one of your value types was now always wrapped in a box.
> Whatever this is called you seem to agree that the syntax is hacked and it can get hard to understand what something means
Result builders are just a way to build data types from the results of top-level expressions (hence their name). It’s not just a SwiftUI thing, they’re also used for regular expressions for example: https://github.com/apple/swift-evolution/blob/main/proposals...
I spent some time with Swift-on-the-server last year and definitely felt like the class/struct difference made sense.
But I have to agree, from a novice eye at least, result builders look to be a feature added to support SwiftUI and limited other use cases. Have you seen many examples of third party libraries successfully using them?
And while we're here, do the introduction of macros in Swift 5.9 allow room for replacing result builders with something more uniformly useful?
The regex result builder is awful. It's very obviously a feature which was developed to make SwiftUI look good in WWDC presentations at the expense of everything else, and no one's found anything that they're actually useful for even with some effort to pretend that it's not just there for SwiftUI.
this trend of apple building api that only serves to make good-looking wwdc talks but fall short under real life usage is one of the worst things... It has now reached a point where people don't trust anything apple dev say during those presentations, because they know there's a limitation hidden somewhere.
That is sorta how I feel. Regardless how people feel about Swift. Having dabbled in Swift over the past couple of weeks, getting paid to sling C# and doing Rust in my open source work, Swift feels like a perfect mix between C# and Rust. You want C#, but some of the niceties of Rust. Or you want Rust with some of the niceties of objects on C#.
yeah agreed.
It just feels like it’s going to be hard for it to escape people’s hesitation due to the level of Apple influence/control.
I wonder why golang didn’t seem to experience the same issue
Speaking only for myself, I’ve tried to learn Swift but you really need to be developing an app on an Apple OS to be able to get practice on the breadth of the language.
Go, by comparison, can be learned in a couple of days, and it’s trivial to build a useful CLI with it.
So from my perspective, the barriers to entry for Swift are much higher, but it’s mostly due to the domain rather than the sponsor.
There are some things in Swift that definitely are not as easy going as on Golang. Swift I think, at least offers a good starting point (the bits are there), but it is so hard to find good Swift documentation or blog posts that are not centered around the idea of making an iOS app. Even trying to find decent blog posts where someone shows off or talks about writing command line macos apps is virtually non-existent. Swift for sure, has the building blocks to do it, but you really gotta dig to find that stuff.
As an example. I have been dabbling with controlling my Roku from a watchOS app. Roku devices respond to a call on 239.255.255.250:1900 with a SSDP packet over UDP. Try finding good and recent tutorial on doing UDP programming and it is non-existent.
Yeah, I guess that’s my point. Most people use Swift for building apps, but anything else like servers or CLIs and all the tutorials go nowhere, because… most people use Swift for apps.
So yeah I had a similar experience. And Go is much more aligned with my use cases so hints are everywhere.
To be clear I still want to learn Swift. But the time investment is much, much greater.
that's fair, I was thinking of it more as an "easier alternative to Rust" than "is it any harder to learn than Go", which puts things in a very different frame :)
Not for all cases, sure. It would be challenging to write an OS kernel or low level device firmware in Swift, but for a lot of other use cases it is absolutely a viable alternative to C and C++.
Apple is doing exactly that. They’ve already shipped stuff written that way. I think the Secure Enclave code is now Swift.
I’m pretty sure they have extra stuff on top at the moment to help them write ultra-strong/safe code that the released language doesn’t support directly yet.
But they are moving in that direction. Just because most people use Swift as a language where they don’t have to worry about memory allocation and with the large standard library doesn’t mean that’s all it can do.
Swift on the server is really quite well supported now. Frameworks like Vapor work fully, there's a thriving ecosystem. And above all, Apple clearly wants this to work. Apple aren't deploying macOS servers for their backend services.
Swift is most comparable to Kotlin in the current crop of languages and the Kotlin team is doing their best to get multiplatform, backend, KotlinJS, and native everywhere. Kotlin dominates Android obviously, but is growing quickly on the backend. The other implementations are still early but they continue to be improved.
I don't see Swift anywhere outside of Apple and don't see why anyone would reach for it instead of Kotlin.
It also doesn't help that JetBrains has an IDE that makes development in the language so nice people are willing to pay for it and Xcode easily is the worst user experience of any current product developed by Apple.
I see people claim this frequently that Kotlin is used a lot on the backend, but there’s very little evidence that this is true.
I absolutely will concede that Swift is in practice an Apple only language, but I feel Kotlin is essentially an Android only language in practice as well.
Nope, Kotlin is plenty popular on backend, so much so it's mundane to see it in popular frameworks like Spring and Play. It helps that it's designed to coexist with Java.
About a year ago, Swift on linux was a bit of a minefield. Only parts of Foundation were implemented, and you couldn't use the Linux toolkit on a Mac to cross-compile or even just link against the Linux version of Foundation. The recentish move to reimplement Foundation in Swift natively is a big win, and I haven't tracked how close that project is.
Unusable. People seem to be concerned about Rust's ecosystem dying, but Swift's ecosystem is essentially Apple's system built-in libs + a handful of good open source packages. You need to do everything yourself when Apple's sys libs are not accessible.
With this year's WWDC announcements, it seems more obvious than ever that Combine was a bridge technology that has served its purpose now that Swift concurrency is taking over, and those things are open source. Doesn't help with SwiftUI, but just open sourcing it wouldn't have helped much that much without also having platform bindings, given that it uses UIKit on iOS and AppKit on Mac.
That's true, Combine is a dead technology. Frustrating as I prefer it in a lot of cases to Swift concurrency, but I've been an Rx fan for a decade or so.
As mentioned, Swift has official distributions for Windows, ubuntu et al., and VSCode is the default solution. Most of the effort is driven by the server workgroup.
Note Swift's interoperability story with C/C++ is also getting much better.
The key to success is to know what libraries are supported.
It's not as good as Xcode, but you can set up a serviceable Swift dev environment on Linux with VS Code and the official Swift VS Code plugin which adds LSP and debugger support. It's easiest to set up in Ubuntu and Fedora but should be possible in in other distros.
I haven't toyed with Swift under Windows, but the devs behind Arc Browser have been hiring people to work on improving Windows tooling and writing a Swift wrapper for WinUI 3.
It’s been in the mainline Fedora repos for several releases now, so it’s just a dnf away if you use Fedora. Installation isn’t too difficult on most of the other mainstream Linux distros either by following the installation instructions on Swift’s website.
I do have a mac, but before I get too invested in Swift, I would like to know I can take it else where. I haven't tried out Swift on my linux box yet, but from reading stuff in the repos and forums, it works. I guess it depends on what you think the value add for Swift is. Some, and there is a reasonable argument, is the value add of swift over other languages is when your on an apple device taking advantage of Apple APIs/tight integration in their ecosystem. Vapor exists for server side swift, which is where I really want to take a look at swift on linux.
Having seen a few references on here to Rust kicking the bucket…is that a risk with Rust?
This is a good-faith, non-trolling question. Rust is way out of my wheelhouse, but it’s obviously gained enough momentum that even I’m aware of it. Is there some language or community issue?
The project had had a string of governance issues recently. The old leadership structure fell apart (2 years ago) due to irreconcilable disagreements. Then the informal temporary replacement governance, due to a sequence of miscommunications and process failures, committed a major slight against a prominent C community member who had been scheduled to speak at a Rust conference (1 week ago). Said temporary governance system is currently (as in, should be done in 1-2 days max) being replaced by the new permanent governance council, which will hopefully improve things.
In any case, Rust is unlikely to fail because it is the only viable option in its niche (safe systems programming language that can replace C++ everywhere), and has gotten a large amount of investment from major corporations.
I wouldn't say it definitely owns that niche, yet, until there is empirical evidence of how using Rust correlates to safer software. Until then, I think it's a hope founded on a substantive argument (ie. the borrow checker) that is still at risk of not achieving its goals.
The Android team posted something on that topic about 6 months ago [0, HN discussion at 1].
One potentially relevant highlight:
> To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code.
> Historical vulnerability density is greater than 1/kLOC (1 vulnerability per thousand lines of code) in many of Android’s C/C++ components (e.g. media, Bluetooth, NFC, etc). Based on this historical vulnerability density, it’s likely that using Rust has already prevented hundreds of vulnerabilities from reaching production.
The post has more details, and I think the entire thing is worth a read.
There is a lot of drama in the project leadership (and has been since the beginning), but that's mostly irrelevant to people just using the language. This latest flareup is about a conference keynote speaker, not something relevant to the language itself.
If the project becomes dysfunctional enough, it can always be forked, as it is fully OSS.
As a rust mostly-outsider, I saw some recent drama (of the interpersonal kind) related to some unilateral action taken by a member of the rust team without a consensus, to downgrade someone’s conference talk, but I haven’t heard of anything that fundamentally impacts the language today. If they alienate their community, maybe in the long term there may be issues, but I certainly don’t make language decisions based on drama in the community. I may have easily misread this though, and would be happy to hear if it’s something bigger than it seemed to me.
This proposal looks like it's from 2017 (there are more recent commits, but they are just typo fixes). It was briefly discussed here at the time: https://news.ycombinator.com/item?id=13669001
Anybody familiar with Swift development have updates on whether it went anywhere and what the current state is? As someone not in this particular loop, not immediately clear to me why a 6-year-old proposal was linked here.
Swift 5.9 dropped at WWDC, and with it came with noncopyable value types:
https://github.com/apple/swift-evolution/blob/main/proposals...
as well as a way to explicitly move types:
https://github.com/apple/swift-evolution/blob/main/proposals...
I haven’t read either in-depth, though!
Just last week owning and borrowing parameters got accepted as well. https://github.com/apple/swift-evolution/blob/main/proposals...
It’s been the focus for a while especially after the concurrency work. It’s probably the final major feature before Swift 6
The best description I know is https://www.hackingwithswift.com/articles/258/whats-new-in-s..., which refers to a few Swift Evolution docs:
https://github.com/apple/swift-evolution/blob/main/proposals...
https://github.com/apple/swift-evolution/blob/main/proposals...
https://github.com/apple/swift-evolution/blob/main/proposals...
The first is explicitly marked as “Implementation: Swift 5.9, without no-implicit-copy constraint”, but it seems the others also ¿partly? are in.
Year added above. Thanks!
For current Rust users, if Rust kicks the bucket, Swift is a good plan B.
I find it very notable that Graydon Hoare, the "founder" of Rust, went on to work at Apple on Swift for a while.
Also, Swift had tremendous work to implement ABI stability[1], which really allows it to be used as an OS API, which Rust can't do.
[1] https://faultlore.com/blah/swift-abi/
I read Graydon's recent "If I were a BDFI" essay and found myself mostly sympathizing, especially with the "I wanted Rust to have potentially costly abstractions, because that's the point of abstractions, pay a known cost to solve common problems". It seems Rust was taken over by the "zero cost abstractions at all costs" crowd. Graydon seems at peace with that because it's what the community wanted. But I think it's also obvious that he was frustrated by the regression to the mean that comes with shared ownership/leadership.
Then I thought that what we really need is a Swift-like language with the ability to remove costly abstractions when you don't want to pay the cost, but that default to ergonomically solving the problems that the majority of programs need to solve. You should opt-in to more semantic complexity, not be encumbered by it by default. Rust's obsession with performance above all else confuses me. But I also guess it's nice to have a safe space for performance sensitive programmers. But like how can a systems language not have a stable ABI? Very mixed messages.
Ultimately this "Rust with better ergonomics" language could be Swift. I do think it is more usable across platforms than people give it credit for. But it's also missing the "let me dip down into lower level but more complicated semantics when I need to" option. Having a stable ABI is awesome, though. I really can't wait for the day where I can start a portable project in Swift without a second thought.
> Rust's obsession with performance above all else confuses me.
It's kind of a requirement if they hope to replace C/C++ as a systems language, as those remain the goto answer for "I need maximum control", short of assembly.
And they want to replace C/C++ to fix all their safety problems.
I work in embedded systems, where C remains a holdout, with all its problems. Rust's performance-oriented direction makes it a viable consideration for us.
I understand the need to compete with C/C++.
My understanding of zero cost abstractions is that they predominantly happen at compile time (and thus commonly appear in language semantics or the type system) and literally cost nothing at runtime. This has other costs like semantic complexity, but almost never performance.
Regardless, I don't buy that Rust couldn’t present a more opinionated and complete programming experience without allowing the same performance characteristics that it has today. The whole async situation is awful. Lifetimes are a stupid leaky abstraction 99% of the time. My point is that there’s almost never a scenario where you e.g. need to bother with passing around a struct with a reference with a lifetime. 99% of the time you just take ownership of the data or use an Arc<Box<T>> and 99% of the time that’s not a performance problem. What I think is stupid is that Rust elevates and enshrines the 1% use cases and makes the 99% experience worse off for it. I love Rust. But it could do a better job of solving the 99% cases nicely while allowing a “zero cost escape hatch” where you could say “actually I do want a stack allocated reference without atomic reference counting” and pay the semantic price 1% of the time rather than 99% of the time, similar to Swift’s approach.
Obviously my experience had been shaped by the projects I’ve worked on. But I also think Swift is an entirely more ergonomic and practical language. If you think Rust is a viable option then, unless you’re anti-Apple, Swift with ownership semantics most certainly is too. Seriously.
But the problem with zero-cost abstractions is that even if the runtime cost is 0, the compile time (and the human time) can become quiet large.
E.g. https://www.youtube.com/watch?v=rHIkrotSwcc
Zero-cost abstractions are exactly that:
- you only pay for what you use
- if you use it, you couldn't implement it better yourself
There's no such thing as literally zero cost, obviously.
Graydon was saying that even this fairly reasonable pair of conditions got in the way of some nicer abstractions.
It worked for Microsoft VC++ for a long time.
Nowadays they rely on COM for that purpose, which is nice as idea, if the tooling wasn't so clunky.
MSVC++ 2015 or later has a stable ABI independent of COM.
I’m interested in how this works (this thread is now getting old so I’m not sure there will be replies…)
One of the important aspects of a stable ABI is the ability for clients to continue to work even after the size of a remote type changes… for instance, if Foo is a type defined in Foo.dll, and I link to it, and my code does `Foo *f = new Foo()`, the compiler will emit code that malloc’s `sizeof(Foo)` bytes on the heap. If later on, Foo gets a new member variable “m”, it will increase in size, and now code in Foo.dll will segfault if it tries to access `this->m`, if a client allocated it.
COM solves this by basically not letting you do `new Foo`, but instead you have to ask COM itself to allocate and return an instance for you, with something like `CoCreateInstance`. This allows .dll’s to evolve even if the size of the object changes, by abstracting away things like size information so that clients don’t care about it. ObjC solves this similarly with `[SomeClass alloc]`, where clients just ask the class to alloc itself and returns a pointer (which is delayed until runtime, not in the emitted code), and Swift solves it with value witness tables which delay the lookup of size/stride information until runtime.
I don’t understand how, you can write .dll’s with not only a stable ABI, but the ability to actually evolve your types, in plain vanilla C++… I think the language itself has painted itself into a corner that prevents things like this.
Yes, hence one of the reasons why WinRT came to be, as COM evolution.
You get .NET metadata, IInspectable, and an improved type system, basically .NET CLS.
It doesn't expose everything C++ can do, but enough C with classes, OOP ABI and generics.
https://learn.microsoft.com/en-us/uwp/winrt-cref/winmd-files
Basically what COM vNext was going to be, if it wasn't for .NET pivot (see Ext-VOS).
However the tooling is as clunky as using ATL.
Which is creating a bunch of headaches for full ISO C++20 semantics, and most likely needs to be fixed by when ISO C++23 gets fully supported.
One example where this shows up is [[no_unique_address]].
> which really allows it to be used as an OS API, which Rust can't do.
I think that's a massive simplification
In what way? OS API’s can’t reasonably be copy/pasted into every binary on the system. It’s one thing to have large executables for third party apps you install, but you’d get tired of the wasted disk space really quickly if every binary in the OS had to statically link in the implementation of every library it used.
It’s not just disk space either, but the ability for an OS as a platform to swap out implementations of their API’s with new ones, without requiring every app to be recompiled. It’s the reason macOS is able to implement things like dark mode, or a new UI theme, or any other “horizontal” feature that works across all apps; you need dynamic linking for that to be possible.
The quality of implementation of the Swift compiler is in no way comparable to Rust's. It's super easy to cause its type check to timeout, which is something I haven't seen when using Rust. I even managed to make it crash several times. It also lacks some pretty standard features such as turning off warnings of a certain type or on a certain line. The language itself is quite problematic when compared to Rust, too. For instance, Swift doesn't have the orphan rule, so it's possible that 2 packages implement the same protocol for the same type, and when this happens currently there are no solutions; there is this strange design decision that classes and structs should be different things and each have their own set of random limitations; and there is SwiftUI, which hacks on the syntax itself, making statements no longer mean what they are supposed to mean.
> It's super easy to cause its type check to timeout, which is something I haven't seen when using Rust.
Yeah, the operator overloading design makes it too easy to construct an exponential search space.
> For instance, Swift doesn't have the orphan rule, so it's possible that 2 packages implement the same protocol for the same type, and when this happens currently there are no solutions;
There's now a warning about this: https://github.com/apple/swift-evolution/blob/main/proposals.... What other solutions can there be other than making it a hard error? It seems like an inherent drawback of typeclasses over first-class modules.
> there is this strange design decision that classes and structs should be different things and each have their own set of random limitations
structs in Swift are the same as structs in Rust, and a class is a heap-allocated reference counted box, like an Arc<Box<T>>. What are the random limitations? As far as I'm aware the behavioral differences between structs and classes are entirely explainable by the above.
> and there is SwiftUI, which hacks on the syntax itself, making statements no longer mean what they are supposed to mean
Result builders are a language feature and not part of SwiftUI: https://github.com/apple/swift-evolution/blob/main/proposals...
> structs in Swift are the same as structs in Rust, and a class is a heap-allocated reference counted box, like an Arc<Box<T>>.
Yeah, and by representing the differences this way, Rust allows you to easily decide whether an object is used directly or is wrapped in a rc box when its used, instead of when it's defined, often not by you, and when you change your mind you don't need to change all methods or functions than mutates it and all their call sites.
> Result builders are a language feature and not part of SwiftUI
I admit that this is the first time I see the term result builders. This is never mentioned in any SwiftUI documentation I've seen, so I guess I should extend my complaint to include quality of docs :p. Whatever this is called you seem to agree that the syntax is hacked and it can get hard to understand what something means
> Yeah, and by representing the differences this way, Rust allows you to easily decide whether an object is used directly or is wrapped in a rc box when its used, instead of when it's defined, often not by you, and when you change your mind you don't need to change all methods or functions than mutates it and all their call sites
Changing a value type into a reference type is a pretty fundamental transformation because your local mutations now become non-local. Its not clear the Rust approach makes this any easier either, since you’d still have to update all call sites that perform mutation if suddenly one of your value types was now always wrapped in a box.
> Whatever this is called you seem to agree that the syntax is hacked and it can get hard to understand what something means
Result builders are just a way to build data types from the results of top-level expressions (hence their name). It’s not just a SwiftUI thing, they’re also used for regular expressions for example: https://github.com/apple/swift-evolution/blob/main/proposals...
I spent some time with Swift-on-the-server last year and definitely felt like the class/struct difference made sense.
But I have to agree, from a novice eye at least, result builders look to be a feature added to support SwiftUI and limited other use cases. Have you seen many examples of third party libraries successfully using them?
And while we're here, do the introduction of macros in Swift 5.9 allow room for replacing result builders with something more uniformly useful?
Result builders are pretty popular in third party libraries, too. There's good use of them in Pointfree's libraries Parsing (https://github.com/pointfreeco/swift-parsing) and Composable Architecture (https://pointfreeco.github.io/swift-composable-architecture/...).
A quick search in the package index also finds things like these:
- https://swiftpackageindex.com/davidcaddy/DCSettings
- https://swiftpackageindex.com/tdeleon/relax/2.1.0/documentat...
- https://swiftpackageindex.com/mkj-is/PathBuilder
- https://swiftpackageindex.com/Saelyria/Artemis
- https://swiftpackageindex.com/FluidGroup/MondrianLayout
etc.
The regex result builder is awful. It's very obviously a feature which was developed to make SwiftUI look good in WWDC presentations at the expense of everything else, and no one's found anything that they're actually useful for even with some effort to pretend that it's not just there for SwiftUI.
this trend of apple building api that only serves to make good-looking wwdc talks but fall short under real life usage is one of the worst things... It has now reached a point where people don't trust anything apple dev say during those presentations, because they know there's a limitation hidden somewhere.
Not if you're using anything other than macOS or iOS derived systems.
That would change very quickly if the Rust ecosystem dies.
That is sorta how I feel. Regardless how people feel about Swift. Having dabbled in Swift over the past couple of weeks, getting paid to sling C# and doing Rust in my open source work, Swift feels like a perfect mix between C# and Rust. You want C#, but some of the niceties of Rust. Or you want Rust with some of the niceties of objects on C#.
yeah agreed. It just feels like it’s going to be hard for it to escape people’s hesitation due to the level of Apple influence/control. I wonder why golang didn’t seem to experience the same issue
Speaking only for myself, I’ve tried to learn Swift but you really need to be developing an app on an Apple OS to be able to get practice on the breadth of the language.
Go, by comparison, can be learned in a couple of days, and it’s trivial to build a useful CLI with it.
So from my perspective, the barriers to entry for Swift are much higher, but it’s mostly due to the domain rather than the sponsor.
There are some things in Swift that definitely are not as easy going as on Golang. Swift I think, at least offers a good starting point (the bits are there), but it is so hard to find good Swift documentation or blog posts that are not centered around the idea of making an iOS app. Even trying to find decent blog posts where someone shows off or talks about writing command line macos apps is virtually non-existent. Swift for sure, has the building blocks to do it, but you really gotta dig to find that stuff.
As an example. I have been dabbling with controlling my Roku from a watchOS app. Roku devices respond to a call on 239.255.255.250:1900 with a SSDP packet over UDP. Try finding good and recent tutorial on doing UDP programming and it is non-existent.
Yeah, I guess that’s my point. Most people use Swift for building apps, but anything else like servers or CLIs and all the tutorials go nowhere, because… most people use Swift for apps.
So yeah I had a similar experience. And Go is much more aligned with my use cases so hints are everywhere.
To be clear I still want to learn Swift. But the time investment is much, much greater.
that's fair, I was thinking of it more as an "easier alternative to Rust" than "is it any harder to learn than Go", which puts things in a very different frame :)
Swift is not a C or C++ replacement, so there is no indication that would happen.
Not for all cases, sure. It would be challenging to write an OS kernel or low level device firmware in Swift, but for a lot of other use cases it is absolutely a viable alternative to C and C++.
Apple is doing exactly that. They’ve already shipped stuff written that way. I think the Secure Enclave code is now Swift.
I’m pretty sure they have extra stuff on top at the moment to help them write ultra-strong/safe code that the released language doesn’t support directly yet.
But they are moving in that direction. Just because most people use Swift as a language where they don’t have to worry about memory allocation and with the large standard library doesn’t mean that’s all it can do.
It surely is from Apple's point of view, it is even expliclity mentioned on its documentation.
Apple doesn't care about what outsiders think, they own the platform.
What? Huh?
You forgot Windows, Linux, WASM in browser, WASI envs
Swift is next to useless on any platform other than Apple's.
Swift on the server is really quite well supported now. Frameworks like Vapor work fully, there's a thriving ecosystem. And above all, Apple clearly wants this to work. Apple aren't deploying macOS servers for their backend services.
[flagged]
Swift is most comparable to Kotlin in the current crop of languages and the Kotlin team is doing their best to get multiplatform, backend, KotlinJS, and native everywhere. Kotlin dominates Android obviously, but is growing quickly on the backend. The other implementations are still early but they continue to be improved.
I don't see Swift anywhere outside of Apple and don't see why anyone would reach for it instead of Kotlin.
It also doesn't help that JetBrains has an IDE that makes development in the language so nice people are willing to pay for it and Xcode easily is the worst user experience of any current product developed by Apple.
I see people claim this frequently that Kotlin is used a lot on the backend, but there’s very little evidence that this is true.
I absolutely will concede that Swift is in practice an Apple only language, but I feel Kotlin is essentially an Android only language in practice as well.
Nope, Kotlin is plenty popular on backend, so much so it's mundane to see it in popular frameworks like Spring and Play. It helps that it's designed to coexist with Java.
It is almost meaningless, about 10% if at all.
We had a bunch of Kotlin on the server at Airbnb in 2018.
DoorDash moved their python backend to kotlin afaik
About a year ago, Swift on linux was a bit of a minefield. Only parts of Foundation were implemented, and you couldn't use the Linux toolkit on a Mac to cross-compile or even just link against the Linux version of Foundation. The recentish move to reimplement Foundation in Swift natively is a big win, and I haven't tracked how close that project is.
> and I haven't tracked how close that project is.
It's a while away yet. Exciting prospect though!
It's my experience as someone who wants to use Swift on something other than macOS/iOS.
I’ve been interested in Swift for a while, but have no MacOS devices. What’s the status of swift on Windows/Linux?
Unusable. People seem to be concerned about Rust's ecosystem dying, but Swift's ecosystem is essentially Apple's system built-in libs + a handful of good open source packages. You need to do everything yourself when Apple's sys libs are not accessible.
It is frustrating that Combine and SwiftUI were not open sourced, though there are few other Apple packages I find I want to reach for on Linux
With this year's WWDC announcements, it seems more obvious than ever that Combine was a bridge technology that has served its purpose now that Swift concurrency is taking over, and those things are open source. Doesn't help with SwiftUI, but just open sourcing it wouldn't have helped much that much without also having platform bindings, given that it uses UIKit on iOS and AppKit on Mac.
That's true, Combine is a dead technology. Frustrating as I prefer it in a lot of cases to Swift concurrency, but I've been an Rx fan for a decade or so.
As mentioned, Swift has official distributions for Windows, ubuntu et al., and VSCode is the default solution. Most of the effort is driven by the server workgroup.
Note Swift's interoperability story with C/C++ is also getting much better.
The key to success is to know what libraries are supported.
- subgroup: https://www.swift.org/server/
- getting started: https://www.swift.org/server/guides/
- wwdc 22 video: https://developer.apple.com/videos/play/wwdc2022/110360/)
- forums: https://forums.swift.org/c/server/43)
I find Swift runs faster on a Linux guest of MacOS than on MacOS itself (but that could be my setup).
There's a group called "The Browser Company of New York" building a new web browser called arc in swift and they're targeting Windows first.
How were building the ARC windows all with Swift - https://youtu.be/Xa_fNuaSE_I
https://github.com/thebrowsercompany
It's not as good as Xcode, but you can set up a serviceable Swift dev environment on Linux with VS Code and the official Swift VS Code plugin which adds LSP and debugger support. It's easiest to set up in Ubuntu and Fedora but should be possible in in other distros.
I haven't toyed with Swift under Windows, but the devs behind Arc Browser have been hiring people to work on improving Windows tooling and writing a Swift wrapper for WinUI 3.
It’s been in the mainline Fedora repos for several releases now, so it’s just a dnf away if you use Fedora. Installation isn’t too difficult on most of the other mainstream Linux distros either by following the installation instructions on Swift’s website.
I do have a mac, but before I get too invested in Swift, I would like to know I can take it else where. I haven't tried out Swift on my linux box yet, but from reading stuff in the repos and forums, it works. I guess it depends on what you think the value add for Swift is. Some, and there is a reasonable argument, is the value add of swift over other languages is when your on an apple device taking advantage of Apple APIs/tight integration in their ecosystem. Vapor exists for server side swift, which is where I really want to take a look at swift on linux.
Having seen a few references on here to Rust kicking the bucket…is that a risk with Rust?
This is a good-faith, non-trolling question. Rust is way out of my wheelhouse, but it’s obviously gained enough momentum that even I’m aware of it. Is there some language or community issue?
The project had had a string of governance issues recently. The old leadership structure fell apart (2 years ago) due to irreconcilable disagreements. Then the informal temporary replacement governance, due to a sequence of miscommunications and process failures, committed a major slight against a prominent C community member who had been scheduled to speak at a Rust conference (1 week ago). Said temporary governance system is currently (as in, should be done in 1-2 days max) being replaced by the new permanent governance council, which will hopefully improve things.
In any case, Rust is unlikely to fail because it is the only viable option in its niche (safe systems programming language that can replace C++ everywhere), and has gotten a large amount of investment from major corporations.
I wouldn't say it definitely owns that niche, yet, until there is empirical evidence of how using Rust correlates to safer software. Until then, I think it's a hope founded on a substantive argument (ie. the borrow checker) that is still at risk of not achieving its goals.
The Android team posted something on that topic about 6 months ago [0, HN discussion at 1].
One potentially relevant highlight:
> To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code.
> Historical vulnerability density is greater than 1/kLOC (1 vulnerability per thousand lines of code) in many of Android’s C/C++ components (e.g. media, Bluetooth, NFC, etc). Based on this historical vulnerability density, it’s likely that using Rust has already prevented hundreds of vulnerabilities from reaching production.
The post has more details, and I think the entire thing is worth a read.
[0]: https://security.googleblog.com/2022/12/memory-safe-language...
[1]: https://news.ycombinator.com/item?id=33819616
> Having seen a few references on here to Rust kicking the bucket…is that a risk with Rust?
IMO Rust is long past the point (in terms of real world usage, commercial backing, etc) where it might “kick the bucket”.
No.
There is a lot of drama in the project leadership (and has been since the beginning), but that's mostly irrelevant to people just using the language. This latest flareup is about a conference keynote speaker, not something relevant to the language itself.
If the project becomes dysfunctional enough, it can always be forked, as it is fully OSS.
As a rust mostly-outsider, I saw some recent drama (of the interpersonal kind) related to some unilateral action taken by a member of the rust team without a consensus, to downgrade someone’s conference talk, but I haven’t heard of anything that fundamentally impacts the language today. If they alienate their community, maybe in the long term there may be issues, but I certainly don’t make language decisions based on drama in the community. I may have easily misread this though, and would be happy to hear if it’s something bigger than it seemed to me.
At this point Haxe or Zig would be far better candidates, but this depends on why Rust was chosen in the first place.
What would it take to make it plan A? My take: rust-level WASM support and a decent standard library.
> Rust kicks the bucket,
Sorry, what?
https://en.wikipedia.org/wiki/Kick_the_bucket
I can't wait for the day they add ownership semantics to JavaScript and Python.
Mojo aims to implement a superset of python, and supports ownership:
https://docs.modular.com/mojo/programming-manual.html#argume...
(same creator as Swift)