[HN Gopher] Swift 6
___________________________________________________________________
Swift 6
Author : todsacerdoti
Score : 243 points
Date : 2024-09-17 19:20 UTC (3 hours ago)
(HTM) web link (www.swift.org)
(TXT) w3m dump (www.swift.org)
| jph wrote:
| Swift 6 is a major leap forward for cross-platform batteries-
| including development IMHO. Foundation is the big win here,
| because it provides so much out of the box.
|
| Swift 6 is the first version with enough low-level improvements
| and cross-platform capabilities to make me curious if the Swift
| team is trying to aim for long-term replacing C, C++, Rust, Zig,
| etc.
| refulgentis wrote:
| Been using Swift since the pre-release announcement that it
| existed.
|
| O'Leary's Law of Swift Comments on HN, much like Betteridge's
| Law of Headlines, says the answer to Swift speculation on HN is
| always no.
|
| If there is any global aim, it is to migrate internal teams
| still working in ObjC/C++ to Swift.
|
| If this sounds close-minded, it's worth talking with an iOS
| developer 1:1 and get info on the day-to-day experience of
| SwiftUI 5 years in, and concurrency/actors 3 years in. They
| have a lot of fires to fight to keep the house standing.
| favorited wrote:
| > Apple is not trying to potentially attempt to aim for maybe
| replacing every other programming language with Swift
|
| Apple's stated goal is to make Swift a viable language up and
| down the technology stack, which goes way beyond Objective-C.
| They are actively working on making Swift viable in baremetal
| environments, firmware, drivers, etc. IIRC they even referred
| to it as a C++ successor language at WWDC this year.
|
| I agree that they're not trying to "replacing every other
| programming language," but they're investing in it becoming a
| viable language choice in most environments.
| refulgentis wrote:
| > they even referred to it as a C++ successor language
|
| Nice!
|
| I'd gently warn against parsing that too closely: having
| been in the community and the weeds starting in 2014(!).
|
| ex. the cross platform Foundation was announced and open
| sourced in 2016.
|
| I'm sure a lot of things were upgraded or more consistent
| and its better etc., but it's a painful to remember what
| was expected + communicated at the time, and how much later
| it is.
| tcmart14 wrote:
| Which I think that makes sense for them to want it to be
| viable all over the stack. It also directly benefits them
| also. I am assuming a lot of the motivation for embedded
| swift is being able to use it in their own stacks. I think
| even the presentation for WWDC gave examples of it being
| used in some pieces of hardware like on the AppleTV?
| rudedogg wrote:
| > They are actively working on making Swift viable in
| baremetal environments, firmware, drivers, etc.
|
| I don't think Swift has a place in these niches FWIW.
| Writing low-level Swift code is very verbose and unnatural.
| Personally I just don't think it's practical to have a
| single language excel across the stack.
| newaccount74 wrote:
| I think the goal of Swift on the server, or embedded Swift,
| is mainly to offer Mac and iOS developers a way to write
| everything in the same language.
|
| Right now, my Mac app depends on a few simple web services
| that are written in a different language. It would be neat
| if those services could be written in Swift, so that I
| could just use the language I already know instead of
| relearning how to do decode JSON in Python/Ruby/PHP.
|
| Swift on the server doesn't have to become widely used. As
| long as there is a simple way to write basic web services,
| it is useful.
| pzo wrote:
| > It would be neat if those services could be written in
| Swift, so that I could just use the language I already
| know
|
| Then somebody else would have to now learn Swift even
| thought they write in different language like: Android
| Developers (Kotlin/Java), React Native devs (JS/TS ),
| Windows Devs, Linux Devs etc. As long as Apple don't
| invest more in official cross-platform tooling Swift is
| not gonna be mainstream (even though I like Swift). They
| have to bless other competing platforms.
| myko wrote:
| John McCall (Swift team) gave a talk on Swift replacing C++
| earlier this year:
| https://www.youtube.com/watch?v=lgivCGdmFrw
|
| Selfishly I wish mixed C targets were a priority before C++
| but I get why this was more important to them
| mpweiher wrote:
| Huh?
|
| Objective-C was in the kernel.
| lukeh wrote:
| In NEXTSTEP, yes, but not macOS.
| MBCook wrote:
| Was it?
|
| Objective-C requires a runtime. I thought the kernel was
| always C/C++.
| favorited wrote:
| There is code in the kernel to enable treating types like
| `os_log_t` and Clang blocks as Objective-C objects higher
| up the stack, but the XNU kernel itself is almost
| entirely C and C++.
| saagarjha wrote:
| Apple says a lot of things at WWDC. Not all of them are
| entirely honest.
| MBCook wrote:
| Do you have any evidence they're not targeting it as
| their main everywhere language?
|
| It's already been used in their libraries, their OSes,
| and even firmware on embedded processors.
| saagarjha wrote:
| I think this conversation has a lot of parallels to their
| public views on SwiftUI. Are they working on it? Yes.
| Will it maybe end up being what they consolidate around
| sometime in the future? Maybe. Does that mean you should
| believe them when they say it's the biggest thing you
| should invest in right now? No.
| lapcat wrote:
| https://live.arstechnica.com/apples-
| wwdc-2014-keynote/images...
| Verdex wrote:
| I feel like the whole issue with c++ is that in order to create
| a language able to do _everything_ you more or less have to
| include a feature set that is 'unharmonious' to say the least.
|
| To me it kind of feels like swift's place here is going to
| replace the subset of c++ that apple is mostly interested in.
| But not necessarily the c++ that they aren't and then likely
| not the c++ that rust et al are able to replace (although I
| guess we'll see what they have in mind as time goes by).
|
| I suspect they'll be disappointed if they try to replace c++ in
| totality. As the end result will likely not be particularly
| habitable.
| MBCook wrote:
| > I suspect they'll be disappointed if they try to replace
| c++ in totality.
|
| Why is that? That is their aim, I think they've made it
| clear.
|
| They're writing all-ish new code in Swift (not always
| practical in existing code) from what I understand. They're
| already using it for the code that runs in places like the
| Secure Enclave or other embedded processors.
|
| Can it replace C++ 100% everywhere today? Probably not. I
| don't know enough to know why. But that absolutely appears to
| be the goal.
| multimoon wrote:
| The most batteries included multiplatform language right now is
| _by far_ Kotlin and nothing else is remotely close. The
| ecosystem is amazing, the language itself is awesome and
| follows sane rules, you can chose between native code, JVM,
| WASM, or JS-IR, or all as backends to compile to (for the exact
| same code) depending on your use case. Compose Multiplatform is
| also wonderful and by far my favorite UI library now and I've
| shipped a fair bit of code with it. It's a single UI library
| that I can share my UI across every platform (including iOS and
| android), and even seamlessly interop with native widgets on
| platforms like iOS if I need to, like the camera viewfinder for
| example.
|
| Kotlin's real strength is the compilers ability to target as
| many different backends as you want and cross compile into any
| platform you want. I have an app in production that save for
| about three lines of swift that declares the view controller
| for iOS specifically, shares its entire codebase all in kotlin
| between Android, iOS, Mac, Linux, and Windows. I could add a
| line to the build file and add web as a target and turn it into
| a web app.
| jb1991 wrote:
| The comment you are replying to was focusing more on the low-
| level features of Swift for systems programming (hence
| comparing it to systems languages). Kotlin is cool but it is
| not a system programming language and the native code
| compilation from Kotlin is not aimed to be.
| iainmerrick wrote:
| That earlier comment didn't actually mention "systems" at
| all (although it does include "low-level").
|
| I feel like "systems programming" is getting increasingly
| ill-defined these days, anyway. If Kotlin and Java aren't
| allowed, how about Go? Are you ruling out all languages
| with garbage collection?
| refulgentis wrote:
| You're right to note systems programming doesn't involve
| GC usually
| MarcusE1W wrote:
| I think systems programming, like system tools or cli
| tool for example can also be done with a garbage
| collector e.g. in Go or Ocaml. For low-level development
| you would usually expect that the program manages memory
| itself, not some garbage collector. This is not black and
| white, some approaches of reference counting for example
| might be suitable for some low-level development. Or in
| some languages you can choose like Nim, D or if I
| understand correctly, now in Swift ?
| pininja wrote:
| A basic litmus test I use for systems programming
| languages is: "can I imagine the Linux kernel including
| this language one day?"
|
| Currently that's C, Rust, and some assembly.. obviously
| there are more languages used for systems programming
| tasks too. Memory management, concurrency, and low-level
| access are also super important in a system language. How
| would you define a systems language?
| saagarjha wrote:
| C++ is sobbing in a corner I guess
| thenewwazoo wrote:
| C++ would sob in a corner, but the Sob static object was
| instantiated before the Tears static object because the
| link order changed and so there's a dangling reference
| and nothing runs any more.
| makeramen wrote:
| Kotlin Native's choice to go with a GC over native memory
| management is my biggest issue with it and really limits its
| use for memory and performance sensitive use cases.
| jwells89 wrote:
| Kotlin isn't bad, but having written plenty of both it and
| Swift, I'd rather write Swift if I had the choice. Their
| syntaxes share a lot of similarities, but subjectively I find
| that Kotlin is less ergonomic, not as conducive to code that
| reads smoothly, and is finicky about odd details in
| comparison. I'll take SPM over Gradle any day too.
|
| On the more minor side of things, Swift's built in JSON
| serialization is super handy. It's really nice to not have to
| increment the dependency counter to parse JSON and makes
| spinning up projects that much faster.
| 6gvONxR4sf7o wrote:
| Every time I read about swift it seems like a nice language, but
| it's a shame its ecosystem is so limited. It's great to see it
| supporting more platforms now. Is the ecosystem in the package
| manager/index also heading the same direction?
| tcmart14 wrote:
| For the question, I think it depends on what you mean. I've
| been able to use SwiftPM on linux without a whole lot of issue.
| So SwiftPM itself doesn't seem to be the blocker here. At least
| I've not had issue in my experimentation. What is maybe more of
| the blocker is the number of libraries that are useful and are
| compiled and tested on Linux. Which for that, the solution is
| just people write libraries/upstream Linux support to existing
| libraries.
| MBCook wrote:
| Making more and more of foundation available (a big part of
| 6) should also help a lot. Fewer external dependencies
| needed, and fewer per-platform libraries if you support
| multiple platforms.
| alas44 wrote:
| Explained to a layman, how nice is this release? Is more
| platforms support gonna make Swift a first class langage?
| moomin wrote:
| I'm honestly not usually that interested in feature lists for
| languages I don't use, but this really does look quite
| compelling. Ownership semantics and C++ integration? Sign me up.
|
| I'd be interested to know how good this integration is in
| practice e.g. could it be used to integrate with Godot directly?
| rescripting wrote:
| Something like this?
| https://github.com/migueldeicaza/SwiftGodot
|
| > SwiftGodot can be used to either build an extension that can
| be added to an existing Godot project, where your code is
| providing services to the game engine, or it can be used as an
| API with SwiftGodotKit which embeds Godot as an application
| that is driven directly from Swift.
|
| Miguel de Icaza gave a great talk on Swift + Godot (among other
| things) https://www.youtube.com/watch?v=tzt36EGKEZo
| Someone wrote:
| > I'd be interested to know how good this integration is in
| practice
|
| I haven't used it, but from looking at the long) video at
| https://youtu.be/ZQc9-seU-5k?si=JMFCWKUZ0vVtst9K (discussed in
| https://news.ycombinator.com/item?id=38444876), it looks pretty
| good.
| jb1991 wrote:
| I've been mixing Swift and C++ in an app and it works pretty
| much as advertised.
| bogidan wrote:
| The download sizes are quite large. 775 MB for swift-6.0-RELEASE-
| ubuntu22.04.tar.gz ~500MB for windows.
|
| Is this shipping an entire copy of LLVM? What could possibly make
| this so large?
| derefr wrote:
| Cross-target toolchain support for shipping _for_ all platforms
| _from_ any platform? (Not sure that 's in there, but if it
| were, it'd be large.)
| favorited wrote:
| Yeah, they contain binaries for Swift itself (the driver
| interface, the compiler, the repl, the package manager, swift-
| format, etc.), as well as the toolchain's dependencies (llvm,
| lldb, clang, the sanitizer runtimes, etc.).
|
| There are other (also large) downloads to enable producing
| static binaries on Linux, and those contain the required system
| libraries (musl libc, libicu, libcrypto, libpthread, etc.).
| Those are about twice as big as they need to be, because they
| bundle x86 and aarch64 together.
| jonathanyc wrote:
| I only want one feature from Swift: faster type-checking. If you
| write a few lines of math, or a moderately complex SwiftUI
| expression, suddenly the typechecker starts timing out. Swift is
| the only language I've ever used with this problem.
|
| https://hachyderm.io/@evanw/109859384302551859
|
| https://www.cocoawithlove.com/blog/2016/07/12/type-checker-i...
|
| https://danielchasehooper.com/posts/why-swift-is-slow/
|
| This isn't mentioned at all in the announcement so I'm kind of
| disappointed.
| refulgentis wrote:
| I wouldn't expect it, ever, frankly. Seen multiple Apple people
| come and go while explaining how they were going to solve that
| (c.f. 2016(!) for link #2)
| zengid wrote:
| Chris Lattner recently explained that because of function
| overloads (and other features), type inference is really hard
| to make fast in Swift, and is why he says that "using Hindley-
| Milner was a mistake". [0]
|
| [0]: https://youtu.be/ENviIxDTmUA?si=FavjcK8IQygnlIwT&t=4417
| saagarjha wrote:
| I don't think Swift uses Hindley-Milner though?
| w10-1 wrote:
| It's a fair point, but radically different 8 years on.
|
| Swift type inference is two-way, so you can often improve
| things by annotating types instead of using inference.
|
| Also, it very easy to have complex builders and nested closures
| that complicate inferencing, so it's a bit of a side-effect of
| how much people use the powerful features.
|
| The big compile-time gotcha now is using macros. To be safe,
| each macro runs in its own process hogging cores, and the new
| Xcode compile scheduler isn't quite sensitive to that, so
| sometimes command-line builds with less parallelism are a fair
| bit faster. The solution there is judicious use, particularly
| of libraries depending heavily on macros.
| tedunangst wrote:
| I can only imagine how terrible things must have been if the
| current state is radically improved. I can lock up xcode by
| doing nothing more than backspacing over a few characters.
| dmart wrote:
| With safe concurrency and typed throws, Swift is starting to look
| a lot like a friendlier Rust to me. Honestly pretty excited to
| take a look at it again, though I doubt it will become my daily
| driver due to the smaller package ecosystem. Hopefully cross-
| platform Foundation is a step towards improving that though.
| steelbrain wrote:
| > Swift is starting to look a lot like a friendlier Rust to me.
|
| That's what i thought and rewrote my cli util in swift. Ran
| great on macOS, tried to build for windows and found out
| there's no well maintained, actively developed http server for
| windows for swift.
|
| Dont let these wooing crowds fool you
| asplake wrote:
| Ha! That seems to answer my next question: what's its story
| for web development? Does it have one?
| myko wrote:
| Vapor works great on Linux and macOS. Haven't tried Windows
| (pretty much only run Steam there these days)
| alexashka wrote:
| You can't compile for Linux from XCode (defacto IDE for all
| things Apple) and all web dev runs on linux.
|
| If you like having an IDE instead of scrolling multi-page
| compiler error dumps in your terminal window - this is a
| complete non-starter.
|
| The leading Swift web framework (Vapor) suggests you use
| Docker to build for Linux. I gave it an honest try - their
| empty starter 'hello world' web server takes more than a
| minute to compile. Ok, but surely it'll be faster after I
| make a one liner change? No - their docker workflow has 0
| compiler caching - you'll be waiting more than a minute
| every time.
|
| Complete non-starter.
|
| I ended up installing a VM, installing the swift compiler
| and _that_ only takes 2-3 _seconds_ to re-compile a 1 liner
| change (in a print statement, in an empty project, lol).
| Consider me very deeply unimpressed.
|
| By comparison - a visual studio code + docker +
| python/ruby/javascript setup is a well oiled, working
| machine.
| JoeMattiello wrote:
| You can install other toolkits for Xcode. There's even an
| aws toolkit.
| alexashka wrote:
| Is it possible to write code in Xcode, press compile and
| have the debugger show me where an error is when
| compiling _for linux_.
|
| If yes, please show me the way because I've failed and
| I've given it an earnest try.
| saagarjha wrote:
| You can use LSP?
| w10-1 wrote:
| > story for web development
|
| Under the hood, Swift-NIO and async Swift is a pretty
| powerful basis for writing performant servers. Aside from
| Vapor, there are other small/fast containers like
| hummingbird.
|
| Not mentioned (surprisingly) is Swift support for
| wasm/wasi, for deploying code directly in the browser.
|
| Also, "some say" that macros could revolutionize both
| static and dynamic generation by moving a good portion of
| site generation to compile time. I'm not aware of any
| libraries realizing that promise yet.
|
| Finally, Swift concurrent actors have supported
| distribution for some time, so you can have all-Swift
| distributed systems, where the client code works with both
| local and remote servers.
| Larrikin wrote:
| Did you look at Kotlin?
| synergy20 wrote:
| Swift does not use virtual machine and garbage collection,
| it competes more to c++ and rust and if Apple is serious
| about pushing it cross platform that's definitely a welcome
| move, in fact, I can't wait even though I have never
| programmed in swift. the main point is that, it's memory
| safe, and seems much easier to code than rust.
| glhaynes wrote:
| Memory safe and, with Swift 6, data race safe.
| timeon wrote:
| > Swift does not use virtual machine and garbage
| collection, it competes more to c++ and rust
|
| Doesn't it use ARC by default?
| azinman2 wrote:
| Which is reference counting, not garbage collection. Ref
| counts free when count = 0. Garbage collection scans all
| object pointers and looks for loops / no missing
| pointers.
| mkl wrote:
| That's _tracing_ garbage collection. Reference counting
| is another type of garbage collection. https://en.wikiped
| ia.org/wiki/Garbage_collection_(computer_s...
| synergy20 wrote:
| it does, I thought ARC is more performant than GC and has
| no stop-the-world issue,thus not a GC
| pebal wrote:
| ARC is a variation of GC. Besides, a tracing GC doesn't
| have to stop the world at all.
| neonsunset wrote:
| Usually, it's the other way around:
| https://benchmarksgame-
| team.pages.debian.net/benchmarksgame/...
|
| binary-trees is almost completely dominated by the time
| spent in allocator code, and stresses its throughput.
| This benchmark showcases how big of a gap is between
| manual per-thread arenas, then tracing generational
| multi-heap GCs, then ARC and more specialized designs
| like Go GC. Honorable mention goes to BEAM which also
| showcases excellent throughput by having process-level
| independent GCs, in this case resembling the behavior of
| .NET's and OpenJDK GC implementations.
| kaba0 wrote:
| > garbage collection
|
| Reference counting _is_ garbage collection, and it
| performs significantly worse from a throughput
| perspective than _tracing_ GC, which is possibly the most
| common metric for web server type workloads.
|
| It really is not nitpicking, we should just really use
| tracing GC when we mean it.
| rudedogg wrote:
| It has nowhere near the performance characteristics of
| those languages. It could, but it doesn't. Look up a
| variety of language benchmarks. It's typically ranked
| around Python/Javascript. You can get as fast as C but
| the code is very atypical.
| azinman2 wrote:
| There's no way it's close to Python. Where are the
| benchmarks?
|
| https://github.com/sh3244/swift-vs-python
|
| Shows a huge difference, as expected for a typed memory-
| safe compiled language using LLVM versus an interpreted
| language with a global interpreter lock.
| rudedogg wrote:
| https://forums.swift.org/t/really-bad-performance-with-
| concu...
| pzo wrote:
| It is slower, like probably ~3x but lets not exaggerate
| that it ranks around python
|
| https://benchmarksgame-
| team.pages.debian.net/benchmarksgame/...
| darby_nine wrote:
| > garbage collection
|
| is reference counting not considered a form of garbage
| collection?
| pzo wrote:
| there is Kotlin Native - "Kotlin/Native is a technology
| for compiling Kotlin code to native binaries which can
| run without a virtual machine."
|
| https://kotlinlang.org/docs/native-overview.html
| vetinari wrote:
| There is kotlin native, which generates native code,
| using the same llvm that c++, rust and swift use. It
| doesn't have to use virtual machine, it is just one of
| targets.
| sandreas wrote:
| Isn't Kotlin based on JVM and Swift is natively compiled?
| That's a pretty significant difference and I'm not aware of
| any "to native" compiler for Kotlin like the NativeAOT
| approach exists for .NET...
| vetinari wrote:
| https://kotlinlang.org/docs/native-overview.html
| amaranth wrote:
| There are in fact two "to native" compilers for Kotlin,
| the one for Kotlin only is called Kotlin Native but you
| can also use graalvm native-image to compile any JVM
| language to native.
| neonsunset wrote:
| All JVM languages are not viable by definition for this
| domain. Object oriented and heavily abstracted nature of
| the underlying runtime implementations prevents their
| effective usage in systems programming due to lack of fast
| FFI, structs, particularly so of custom layout, and the
| historical aversion of the ecosystem to low-level features.
|
| Kotlin native does not count because presently it has
| 0.1-0.001x performance of OpenJDK, it is that bad, and I
| assume is subject to the common subset of features that
| must also be expressible with JVM.
|
| .NET, especially with compilation to native statically
| linked binaries (NativeAOT) is an option, and I believe,
| due to ecosystem maturity as well as very heavy focus on
| performance in all recent .NET versions as well as
| continued improvement of low-level features (portable SIMD,
| byref pointers with simple lifetime analysis, static
| linking with C/C++/Rust/etc.), it is a strong contender.
| Unlike Java, C# has _great_ systems programming story,
| after all, it was influenced as much by C++ as it was by
| Java, sadly many only ever think about the latter.
|
| However, I'm looking forward to Swift 6. Once it is out,
| I'd love to see it offer more opportunities at ensuring
| static dispatch and generic monomorphization (in .NET,
| generics with struct arguments are _always_ monomorphized
| like in Rust, so you have tools for zero-cost abstractions)
| and happy paths allowing to bypass prohibitive cost of ARC
| with new annotations. By using LLVM, Swift has
| theoretically great performance ceiling, even if it does
| not deliver on it just yet, losing to C# by a good margin
| on the more complicated code.
| jakey_bakey wrote:
| How hard is it to build an HTTP server?
|
| (Yeah, this is a dumb question but I'm asking anyway)
| Eric_WVGG wrote:
| Do you mean from first-principles, or letting someone else
| do the work and use a framework?
|
| Apple did the hard work, https://github.com/apple/swift-
| nio.
|
| If you just want a big framework to launch an API, that's
| been around for years: https://vapor.codes
| akvadrako wrote:
| That all depends on your requirements. A few hundred lines
| of code will get you pretty far, but there are about 100
| optional features in common use.
| darby_nine wrote:
| Curious! In what ways do you do you see swift as friendlier
| than Rust? I perceived it as functionally equivalent, although
| Swift had a lot more "magic" involved and it was less clear how
| things might work memory-wise.
| 9dev wrote:
| More magic (thus less required explicitness) and less
| involvement with memory management are typically considered
| as friendly traits in programming languages.
| darby_nine wrote:
| > More magic (thus less required explicitness) and less
| involvement with memory management are typically considered
| as friendly traits in programming languages.
|
| Really depends on the context. I really, really, really
| hated this instinct in the ruby on rails community when I
| was still doing that. Magic is nice until it doesn't work
| the way you expect, which is when it becomes an active
| liability.
|
| I really don't spend much time thinking about memory
| management in Rust, but I can certainly understand why one
| might be happy to not have to design around ownership and
| lifetimes. I really like the explicit nature of it, though,
| makes it super easy to read and reason about code you've
| never seen before.
| porcoda wrote:
| I've migrated to swift for some nontrivial projects that were
| formerly C++. Quite happy so far, and didn't find rust nearly
| as pleasant when I tried the same thing there. I don't want
| explicit memory management very often, so ARC works great for
| me. Haven't had any issues with portability either, although I
| don't test often on windows so I'm not confident there but
| Linux and Mac have been great.
| dogprez wrote:
| I'm glad you found something you like. I just want to make it
| clear that the things about Rust that make it "unfriendly" are
| also the things that make it able to do things other languages
| can't do, like compile-time memory safety. Depending on what
| you are making, that might make little difference. I just
| wanted to make sure you appreciated what Rust can do that other
| languages can't.
| skrrtww wrote:
| I wish they would stop introducing more magic syntaxes.
| schrodinger wrote:
| I agree! I'm a Go programmer, and while I do wish it had some
| more features at times, Swift is an example of how it can
| easily go out of control and ruin a promising language.
|
| For example tests, there's so much magic. How do I know it runs
| the test for each item in the arguments array? What if there
| were multiple arguments? After using Go for close to a decade
| now, I'm really seeing the wisdom of avoiding magic, and making
| your testing code the same language as your building code!
| Compare:
|
| Swift: @Test("Continents mentioned in
| videos", arguments: [ "A Beach", "By the
| Lake", "Camping in the Woods" ]) func
| mentionedContinents(videoName: String) async throws {
| let videoLibrary = try await VideoLibrary() let video
| = try #require(await videoLibrary.video(named: videoName))
| #expect(video.mentionedContinents.count <= 3) }
|
| Go: func TestMentionedContinents(t
| *testing.T) { tests := []struct{ Name string }{
| {"A Beach"}, {"By the Lake"}, {"Camping
| in the Woods"}, } for _, tt := range tests
| { video, err := library.FindVideoByName(tt.Name)
| if err != nil { t.Fatalf("failed to get video:
| %v", err) } if
| len(video.MentionedContinents) > 3 {
| t.Errorf("video %q mentions more than 3 continents", tt.Name)
| } } }
|
| Go with timeout handling in case the FindVideo function takes
| too long (idk Swift magic well enough to know if it'd do this
| automatically!) func
| TestMentionedContinents(t *testing.T) { tests :=
| []struct{ Name string }{ {"A Beach"},
| {"By the Lake"}, {"Camping in the Woods"},
| } for _, tt := range tests {
| t.Run(tt.Name, func(t *testing.T) { ctx, cancel
| := context.WithTimeout(context.Background(),
| 30*time.Millisecond) defer cancel()
| video, err := library.FindVideoByName(ctx, tt.Name)
| if err != nil { t.Fatalf("failed to get video:
| %v", err) } if
| len(video.MentionedContinents) > 3 {
| t.Errorf("video %q mentions more than 3 continents", tt.Name)
| } }) } }
| MBCook wrote:
| Is there a specific one you're objecting to in 6?
| akoncius wrote:
| did not find anything metioned about namespaces/packages support?
| quite disappointing :( this is the main disadvantage for my
| tastes
| hombre_fatal wrote:
| The unqualified imports are definitely a major pain point. In a
| large Swift app I find myself having to be eternally vigilant
| organizing my files so that I'm not dumping surprises into the
| import site.
|
| Makes me appreciate how even Node.js got it right so early on.
| seanw444 wrote:
| What platform has 128-bit integer support to where that was an
| important thing to add to the primitive types?
| bluepizza wrote:
| IPv6 and ZFS use 128-bit integers - I suspect this is why this
| primitive was added.
| LegionMammal978 wrote:
| Many platforms have an instruction to get the upper 64-bit word
| of a widening 64x64-bit multiplication. But it can be difficult
| to (performantly) access such instructions from anything
| higher-level than assembly, so well-optimized language support
| for 128-bit integers can open this up.
| eknkc wrote:
| As a side note, zig supports arbitrary width integers. I'd like
| more languages to support that. You can have i7, i3, i1024 or
| whatever you want (I guess up to some limit).
|
| Makes it a lot easier to handle packed binary files etc.
| jazzyjackson wrote:
| Maybe something to do with AES 128bit blocks
| Kelteseth wrote:
| I recently tried SwiftGodot, because I found Swift for game Dev
| very interesting in comparison to csharps GC stalls. Sadly it
| does not yet support sharing pre build Windows development
| libraries[1]. Compilation does take quite some time, even on my
| beefy 16 core Ryzen. The changelog did mention multi threaded
| Swift package manager improvements on Windows though.
|
| [1] https://github.com/migueldeicaza/SwiftGodot/issues/521
| dur-randir wrote:
| I've tried using it once and got compiler crash from the get go.
| Still no response on the bugtracker. Next try in 5 years.
| RivieraKid wrote:
| Swift is great but I wish it had namespaces / packages...
| rubiquity wrote:
| Swift has packages and a module system.
| w10-1 wrote:
| I think the complaint is the global runtime namespace, not
| source modules. Statics live forever, and extensions in any
| library on a type apply to all uses in the runtime (with no
| guarantees about conflicts).
|
| Mostly that's minimizable with good practice, but can be
| annoying to those used to hierarchical namespacing and static
| memory reclaimed after the class becomes unreachable.
| dtech wrote:
| I'm not familiar with Swift, anyone already know how typed throws
| hold up? Checked exceptions are pretty universally seen as a
| mistake in Java [1] while ADT a la Result are generally perceived
| better.
|
| [1] See e.g. https://literatejava.com/exceptions/checked-
| exceptions-javas..., but also Java 8+ API's moving away from
| them.
| airspeedswift wrote:
| You can read about the trade-offs in the language proposal
| here: https://github.com/swiftlang/swift-
| evolution/blob/main/propo...
|
| In particular:
|
| > Even with the introduction of typed throws into Swift, the
| existing (untyped) throws remains the better default error-
| handling mechanism for most Swift code. The section "When to
| use typed throws" describes the circumstances in which typed
| throws should be used.
| brantonb wrote:
| I think your link got cut off. Here's the direct link to the
| section on when to use typed throws. I hadn't read this
| before, and it changes how I'll approach them. Thanks for
| pointing it out!
|
| https://github.com/swiftlang/swift-
| evolution/blob/main/propo...
| nielsbot wrote:
| Throws in Swift are not traditional exceptions. A throwing
| function in Swift is actually a function that can return an
| error instead of a result. This is hidden by the language.
|
| So something like
|
| `func foo() throws -> Result`
|
| Is actually
|
| `func foo() -> Result | Error`
|
| The compiler also forces you to handle any returned errors
| using `try`. So to call our example `foo`, you'd do:
|
| `let result = try foo()`
|
| You must either handle any throws error or include this call in
| an enclosing throwing function.
| meindnoch wrote:
| >Throws in Swift are not traditional exceptions. A throwing
| function in Swift is actually a function that can return an
| error instead of a result. This is hidden by the language.
|
| Implementation detail.
|
| The two features are equivalent.
| iainmerrick wrote:
| Pretty universally seen as a mistake by those people who see
| them as a mistake. :)
| dep_b wrote:
| Used typed throws for a bit and I like them. I remember from
| long ago the Java implementation forcing me to catch them but
| in Swift it's just a bit of extra compiler-enforced
| documentation about what and what not to expect in terms of
| errors.
| wiseowise wrote:
| > I remember from long ago the Java implementation forcing me
| to catch themm
|
| "throws Exception" on your method.
| w10-1 wrote:
| Swift throws are results, but now with specific and generic and
| specializable types.
|
| To illustrate, Swift has a nice `rethrows` feature that helps
| with function composition.
|
| If your function takes a function parameter that can throw, it
| can use 'rethrows' to say "I only throw if this parameter
| does". Then when passed a function that doesn't throw, your
| function need not be invoked with `try`.
|
| This plays nicely with generics over throwing type, since the
| bounds propagate back to the function type. If the function
| parameter only throws a given type, that's what the function
| will throw.
|
| Also helpful for reducing error boilerplate, `try` has the
| convenience form `try?` which means "just swallow the exception
| and return nil", and applies to a whole chain: `let f = try?
| this() ?? that() ?? "skip"` means f will be the result of
| either (throwing) function or a literal otherwise.
| wiseowise wrote:
| Checked exceptions are universally seen as a mistake in Java*
|
| * - according to a couple of loudmouths on the internet
| bigstrat2003 wrote:
| Checked exceptions are in no way universally seen as a mistake.
| I thought, and still think, that they are a great feature of
| Java.
| serial_dev wrote:
| I never understood why checked exceptions "are bad", but Result
| types "are good". To me they feel like conceptually the same
| idea.
| MBCook wrote:
| It's often just the boilerplate. As a Java dev people often
| end up ignoring it and changing everything to "throws
| Exception" to avoid having to list 4 exception types all over
| a call stack.
|
| Or they catch and wrap everything in some CustomSysException
| type so they only have to list one type and it's not
| Exception, but then that's really the same thing isn't it?
|
| I think it's kind of a combination of not dealing with things
| and throwing them up the stack combined with too many
| exception types and maybe using exceptions when a result type
| would just be easier.
| ChrisMarshallNY wrote:
| I'm interested in seeing where Swift Testing goes.
| meindnoch wrote:
| I'm gonna to say it: the Swift language had become a monstrosity.
| strongpigeon wrote:
| I'm still fairly new at Swift and like it "OK" so far. One thing
| that I find particularly annoying however is how you very often
| run into "Compiling failed: the compiler is unable to type-check
| this expression in reasonable time; try breaking up the
| expression into distinct sub-expressions" when using SwiftUI...
|
| It's just shocking to me that the compiler is asking me to help
| it out.
| charliebwrites wrote:
| SwiftUI errors in general are mostly unhelpful.
|
| It will go so far as to suggest a change in a thing only for
| the developer to find out the cause was completely unrelated or
| even in a model in a different file.
|
| Helpful error messages for SwiftUI would go a long way
| jakey_bakey wrote:
| You just gave me flashbacks to 1.0 in 2019
| ben_w wrote:
| In my case, Metrowerks CodeWarrior student edition in the
| late 90s, when I was going though "C for Dummies" in
| highschool.
|
| Miss a semicolon, every line _after but not including_ the
| one with the error.
|
| ResEdit was better in the 90s than SwiftUI was in Xcode
| last year. Hoping to find _that_ standard will be re-
| achieved when I install the update...
| jwells89 wrote:
| I think SwiftUI is actually causing Swift a lot of reputation
| damage. I rarely see the issues common to moderately complex
| SwiftUI views when writing Swift with code-only AppKit/UIKit,
| for a CLI program, etc.
| hombre_fatal wrote:
| I jumped directly into SwiftUI for a few macOS apps I
| published, and the weird performance issues / UI lag /
| Compose complexity for even simplistic apps were hard to
| navigate, even after a year.
|
| Yet rewriting components in AppKit/UIKit feels regressive
| since even Apple's docs migrated to SwiftUI, but sometimes
| that was the right answer to regain some control over what
| was going on.
|
| Though some of that was limited to macOS which seems to get a
| lot less attention from Apple than iOS, or because you're
| naturally building more complex layouts on macOS. But it
| always makes me appreciate how much better the kit is for
| building web frontends.
| jwells89 wrote:
| Most of the layouts I've built on macOS are actually
| simpler than their iOS counterparts because the mode of
| interaction is so different. Getting data onto the screen
| in a somewhat natural way is usually less of a contorted
| process because one doesn't need to deal with a software
| keyboard, a narrow viewport, lots of scrolling, etc.
|
| The problem with SwiftUI on macOS in my opinion is that
| it's just not well-suited to the types of layouts common on
| desktop and especially macOS. It's best at uniform grids
| and lists which is more of a mobile thing. On macOS you
| want things like visually balanced whitespace, optical
| centering of labels+controls in forms, etc which are often
| rather arbitrary and exactly the thing that SwiftUI is
| worst at.
| w10-1 wrote:
| > the compiler is asking me to help it out
|
| Yeah, this sucks, but it's also mind-boggling. The SwiftUI body
| result builder returns "some View" which means the compiler has
| to infer the specific type that the function produces, as a
| complex combination of whatever different if/then and while
| loops, along with their transitive function applications and
| closure contexts (where the type inference can be outside-in
| instead of inside-out).
|
| Then layer in in the @Observation macro magic for observing
| data types and re-building views when data changes, Swift Data
| pulling with fully typed predicates from a data store
| automatically replicated across devices....
|
| It's like rocket thrusters from every angle, and pretty easy to
| start tumbling off the happy path.
| amimetic wrote:
| There is an article about this based on a Chris Lattner
| talk/links to previous HN discussions:
| https://danielchasehooper.com/posts/why-swift-is-slow/
| w10-1 wrote:
| It's super nice that they support moving up incrementally.
|
| Moving to Swift-6 mode with full data-race safety checks can be
| daunting. They wrote a separate post on that, and Holly
| telegraphed that they're still actively reducing noise, i.e.,
| warnings where the compiler could use a bit more analysis to
| prove there's no race.
|
| The really nice thing is you can use the new tooling, but stay
| with the 5.10 version of the language that works for your code,
| and feature-by-feature add Swift 6 checking. You can build the
| same package under both language modes, so libraries can move
| ahead in their versioning while still supporting clients who are
| not ready.
| keyle wrote:
| I'm incredibly excited for this. I thought swift was basically
| going to be stuck on macOS.
|
| Last time I converted the swift compiler from the Ubuntu package
| to work on Debian, stuff was looking really awry. Most things
| work but not simple things like sigterm signals.
|
| Swift is a fantastic language. I think the most advanced and
| smart language today. And I say this having used over 20
| professionally over 25 years.
|
| Just look at how swiftUI is implemented. It's not even a DSL,
| it's Swift naturally! Compare it to flutter and you'll see how
| incredible it is. (I do like dart too though)
|
| As for the language it's full of clever features and advanced
| ideas that don't suck to use and consider the developer real
| world use of the language.
|
| Two things really suck in swift though; compiler error messages
| are straight out of the university of assholery and documentation
| was crafted in Mordor probably.
|
| Of course most libraries probably won't work well on Linux yet
| but there is a future with the right balance between safety and
| speed and joy of developing.
| neillyons wrote:
| I recently started learning Swift and Swift UI and was surprised
| at how complicated the language is. Especially regarding reactive
| instance variables. eg. @observableObject. Didn't understand it.
| There are like five different ways to do it. Ended up playing
| whack a mole until it worked.
| jakey_bakey wrote:
| Swift would be perfect if it wasn't dying a death by 1000 cuts
| thanks to the inherent conflict in its governance.
|
| Swift is caught between two clans: the Swift Working Group(tm)
| open-source community, and the Apple corporate entity who pays
| most of their salaries. Both have their own incentives and their
| own imperfections, but you guess who has the majority influence.
|
| Ridiculous, permanent, tech debt such as hardcoded compiler
| exceptions are permanently living in the compiler codebase. Even
| worse, half-baked concepts such as result builders are pushed
| through without any real discussion because Apple wants the
| SwiftUI syntax to look pretty.
|
| It's an amazing language still, but I can't see it surviving as
| nicely in the next 10 years if Apple doesn't learn to let go.
| riscy wrote:
| Can you explain how result builders are half-baked?
|
| They've been used for more than SwiftUI by now. The Regex
| support since 5.7 uses them:
| https://www.hackingwithswift.com/swift/5.7/regexes
| monkmartinez wrote:
| That is a fascinating take and approach to contemplating a
| language.
|
| Can you think of any other languages that share a duality like
| Swift? I mainly play in the python ecosystem, but I am looking
| to branch out and really learn a compiled language. What you
| wrote about Swift makes sense and would be concerning if I had
| recently picked it up.
|
| "Yadda, yadda..." regarding picking the right tool for the job
| aside, I don't want to waste time on a language that can be
| usurped by a giant corporate borg anytime they see fit.
___________________________________________________________________
(page generated 2024-09-17 23:00 UTC)