Hacker News

Apple is open sourcing Swift Build

2025-02-0116:44612283swift.org

Swift continues to grow in popularity as a cross-platform language supporting a wide variety of use cases, with support on a variety of embedded devices, form factors that encompass wearables to…

Swift continues to grow in popularity as a cross-platform language supporting a wide variety of use cases, with support on a variety of embedded devices, form factors that encompass wearables to server, and a wide variety of operating systems. As Swift expands, there’s value in investing in matching cross-platform build tools that provide a powerful, consistent, and flexible experience across the ecosystem.

As a foundational step in this new chapter of Swift build technologies, today Apple is open sourcing Swift Build, a powerful and extensible build engine that provides a set of build rules for building Swift projects. Swift Build is the engine used by Xcode, which supports millions of apps in the App Store as well as the internal build process for Apple’s own operating systems. The open source repository also includes support for targeting Linux and Windows.

The primary responsibility of the build system is to transform user-authored inputs (such as a project description and source code) into output artifacts like command line tools, libraries, and applications. Build systems play an important role in providing a great developer experience, enabling higher level features which determine how users architect and work with their projects. Furthermore, the performance and reliability of a build system has a direct impact on developer productivity.

Swift Build is an infrastructural component designed to plan and execute builds requested by a higher-level client like Swift Package Manager or Xcode. It builds on top of the existing llbuild project to add capabilities including:

  • Robust integration with the Swift compiler to reliably and efficiently coordinate the build of Swift projects
  • Support for a wide variety of product types including libraries, command line tools, and GUI applications with advanced build configuration options
  • Build graph optimizations that maximize parallelism when building Swift and C code

Compared to the build engine in Xcode, the build engine in Swift Package Manager is fairly simple. On Apple platforms, having two different ways to build packages has also led to user confusion when the two implementations’ behavior didn’t match. Contributing Xcode’s build engine to the Swift project and developing it in open source alongside the Swift compiler provides the tools necessary to address these problems and deliver a great builds experience to all Swift users. With this release, SwiftPM now has the opportunity to offer a unified build execution engine across all platforms. This change should be transparent to users and maintain full compatibility with all existing packages while delivering a consistent cross-platform experience. At the same time, it lays the foundation to enable new features and improvements across all platforms and tools, and unlocks new performance optimizations and developer-facing features. As a small first step towards this vision, today the team is submitting a pull request to begin the process of integrating support for Swift Build in SwiftPM as an alternate build engine. In the coming months, we’d like to collaborate with the community to complete the work of unifying build system integrations so users can benefit from future tooling improvements across all platforms and project models.

We believe this is an important step in continuing to enable a healthy package ecosystem where developers can rely on a consistent, polished development experience — no matter what IDE they’re using or platform they’re targeting. We’ll be sharing more details about this work on the Swift forums, and we’re looking forward to hearing others’ feedback!

We look forward to working with the community to continue evolving how we build Swift code. You can find the swift-build repository in the Swift organization on GitHub, including a README and documentation describing how to build and contribute. Contributions via pull requests and issues are welcome, and we’d also love to solicit feedback and ideas for improvements on the Swift forum.

This is an exciting new chapter for Swift’s build system, and we’re looking forward to all the potential it opens for Swift!


Read the original article

dayanruben

Karma: 602
...
 @Hacker__News
@hacker._news

Comments

  • By uhura 2025-02-0119:0710 reply

    I believe that this long game of Swift being "good for everything" but "better for Apple platforms" will be detrimental to the language. This does not help the language nor seems to bring more people to the ecosystem.

    Competitors seems to have a combination of: - Being more open-source - Have more contributors - Have a narrower scope

    Maybe they should consider open sourcing all the tooling (like Xcode) otherwise the gap will only grow over time when compared to other languages.

    • By jitl 2025-02-0123:445 reply

      I don't get this reaction.

      Apple: here, we're open-sourcing this previously closed-source Apple-specific thing that made Swift better on Apple platforms. We're moving the Apple stuff into a plugin so Windows and Linux can be equal peers to Apple in the new system. We've implemented preliminary support for Windows & Linux and plan to continue work to bring them up to parity.

      Hacker News: I believe that this long game of Swift being "good for everything" but "better for Apple platforms" will be detrimental to the language. This does not help the language nor seems to bring more people to the ecosystem.

      Like, what more do you want from them? For them to only open-source Swift Build once they've fully implemented complete parity for Windows and Linux? In the years you'd be waiting for full parity, we'd still see this same kind of comment on every story about swift, asking when they're going to open source a production-level build system.

      • By bluepizza 2025-02-021:411 reply

        I don't get this reaction.

        Almost every language in the world: here's the spec, the tooling, and everything you need to use, master, and expand this language. Please use it.

        Apple: sorry, Mac only.

        Like, I want Apple to do the bare minimum that everyone else is doing.

        • By easeout 2025-02-022:332 reply

          Swift announced Linux support in 2015 when it went open source. Aspects of parity have taken years, and the Objective-C interop that isn't relevant outside Apple platforms but made adoption take off at all occupied a lot of early effort, but every Swift talk at FOSDEM today was about embedded or Linux server applications, or platform-agnostic C++ and Java interop. What can you possibly mean by "Mac only" or "bare minimum"?

          • By bluepizza 2025-02-022:571 reply

            Core libs and foundation for starters?

            https://www.swift.org/blog/future-of-foundation/

            • By easeout 2025-02-023:122 reply

              • By TheNightman 2025-02-023:351 reply

                Yeah I jumped into swift on Linux a while back having mostly used it on apple platforms and I couldn’t even tell anything was different. A few years ago I would’ve had to struggle with SwiftNIO but not nowadays. URLSession, Codable, etc. all there on Linux (not sure about Combine but Combine is stupid in the Swift 6 world IMO. Swift concurrency is better in almost every way).

                Swift on Linux (except NixOS) is actually very good nowadays. There’s even a libadwaita library that feels a LOT like writing SwiftUI.

                Feels like a lot of folks were turned off early on, found something else, and never bothered to try again (which is fair).

                • By DidYaWipe 2025-02-028:041 reply

                  I also have a dim view of Combine and Swift's shitty observation regime, but what does its concurrency have to do with it?

                  • By easeout 2025-02-0217:311 reply

                    Swift Concurrency as a feature set includes async/await and async for, which solve a large part of Combine's same problem with better safety and less setup/teardown. These days Combine is still useful, specifically for multiple observers and several cases of adapting to older event publishing sources.

                    • By DidYaWipe 2025-02-047:41

                      Combine is for setting up observers to changes, whereas Concurrency is for async operations. I don't see the relationship.

              • By bluepizza 2025-02-023:571 reply

                Which was not open source from the start?

                • By easeout 2025-02-027:14

                  Foundation wasn't made to be part of the Swift project until recently. 25 years ago it was the "foundation" of Cocoa, the Mac OS X API derived from NEXTSTEP. It was an Apple platform thing explicitly—now it is remade in Swift and is part of the Swift project.

          • By isodev 2025-02-023:433 reply

            Side note, I think it was hilarious that Swift was allowed on FOSDEM. Even “free” (as in you probably don’t have to pay for a developer account to use it, *unless you want to ship some binary), Swift remains an Apple product.

            • By DeusExMachina 2025-02-028:271 reply

              You don't need an Apple developer account for Swift on server, Windows and Linux.

              You need one only to ship apps on Apple platforms, but that's unrelated to Swift. It applies also to apps written in Objective-C, C/C++, and multi-platform language/frameworks like Dart/Flutter.

              • By talldayo 2025-02-0216:40

                I think the bigger insult towards the Open Source community is their refusal to publish Free Software on the App Store.

            • By Longhanks 2025-02-0213:30

              The Swift compiler, LLVM, Swift Standard Library, CoreDispatch, the Swift Package Manager and the Swift LLDB debugger are all FOSS and allow you to compile, debug, deploy, sell, buy and ship any binary you want under the terms of the Apache License 2.0.

              Deployment of any software (unrelated to Swift) on Apple's platforms is entirely unrelated (and even then, at least on macOS you and any other user can install, sell, buy (...) any binary as desired).

            • By briandear 2025-02-028:59

              Is swift not open source?

      • By gruuuk 2025-02-020:098 reply

        They should have been fully open source with full linux support and parity since day one.

        That would actually help the language get traction. At this point it's a dying language.

        • By ChrisMarshallNY 2025-02-021:04

          > At this point it's a dying language.

          I disagree.

          Source: Someone who has been programming Apple since 1986, and has heard last rites being administered to Apple, many times.

        • By tombert 2025-02-020:381 reply

          Is it dying? I think it's still pretty popular for app development isn't it?

          I was pretty excited to hear that Ladybird is doing a lot of stuff in Swift, because I think it's a pretty decent and fast language and I think it'd be pretty neat to see a browser written in it.

          • By flohofwoe 2025-02-0211:201 reply

            It's essentially "Big in Japan" (eg on Apple platforms but nowhere else). Even on Apple platforms I winder if ObjC is actually still more popular ;)

            • By Longhanks 2025-02-0213:33

              Well if you wonder you should conduct some simple research, but be prepared to have your opinion challenged. Swift ist doing very fine and much more popular than ObjC (again, if you don't believe it, invest 5 minutes into research).

        • By paulddraper 2025-02-023:03

          Lol, as long as it’s the preferred programming language for the most lucrative consumer devices ever, it cannot die.

          Impossible to argue otherwise.

        • By fastball 2025-02-022:561 reply

          What language are you using to develop native apps for macOS and iOS and visionOS and watchOS, since Swift is dying?

          • By jayd16 2025-02-023:572 reply

            C#, Unity.

            • By pjmlp 2025-02-026:531 reply

              Which rely on a mix of Objective-C and Swift APIs to actually interact with the platform.

              • By jayd16 2025-02-028:391 reply

                What's your point? That's what Apple makes available. I'd use the C# API if that's how they provided it.

                If not dominating the games on those plarforms, Unity and C# have a strong footing to say the least. Swift doesn't seem to be making very much headway on platforms where APIs are available in anything else.

                Maybe that can chance. It seems like a neat language but "it's popular because apple forces you to use it" is more damning than reassuring.

                • By pjmlp 2025-02-0210:391 reply

                  The point is that they are guest languages on Apple ecosystem and need Apple tooling and languages as means being available.

                  I may also add that I dislike Microsoft doesn't give to the .NET ecosystem the same care for games developers as Apple does for Swift and existing OS SDKs.

                  As far as DirectX team is concerned, only C++ exists, and .NET team lets third party folks do the needful.

                  Had it not been for MonoGame, Unity would never picked C# in first place, gone were the days of Managed DirectX and XNA, when the decision came to be as Unity did their cross-platform rewrite out of OS X.

                  • By jayd16 2025-02-0218:051 reply

                    The specifics of C# are fairly irrelevant. Point is that even if swift is forced, middleware can and will just plaster over that. Even if Metal is forced, tools can plaster over that.

                    Apple forcing an API is not enough to sustain a language's popularity.

                    • By pjmlp 2025-02-0218:45

                      When the language is required for one of two mobile ecosystems, and second major desktop ecosystem, popularity is relative.

                      For decades C# was only relevant on Windows, outside Unity never got wide adoption among AAA studios after Unreal became free, and after their license debacle less so, Godot favors C++ and GDScript even with C# support it isn't what most folks reach for, and Microsoft keeps having an adoption (popularity) problem on UNIX culture oriented startups.

                      While just like Swift on Apple's ecosystem, C# is doing just fine on Microsoft culture environments.

                      Popularity is relative.

            • By atkailash 2025-02-025:52

              [dead]

        • By sgt 2025-02-027:162 reply

          There's a lot more buzz and activity around Swift than many other languages. It's literally up there with Rust, in terms of excitement (perhaps not quite as high). But I think if they get excitement outside of the Apple ecosystem, things should start to get super interesting.

          Some are already adopting it like Ladybird browser.

          • By homebrewer 2025-02-0211:13

            If we're trading anecdotes, I'll share mine as someone's who's completely outside of Apple ecosystem and is not interested in it in the slightest: I only ever hear about Swift on HN, nowhere else. Most of my colleagues, friends and acquaintances (who is in IT, but none of whom are Apple users) don't even know it exist, while everyone has at least heard about Rust. We all live in bubbles, admit it.

          • By dzikimarian 2025-02-029:27

            Sorry to be mood killer, but I think that might be your bubble. That's a first news about Swift I've seen in a long time and I don't see a reason to try it, given alternatives. Nowhere near Rust level of presence in discussion.

        • By technol0gic 2025-02-023:42

          trolling for reactions is trite and predictable

        • By lawgimenez 2025-02-021:25

          Come on now, iOS development is my livelihood.

        • By napierzaza 2025-02-021:27

          No one uses Apple platforms - sent from my iPhone

      • By DidYaWipe 2025-02-027:59

        Amen. Just knee-jerk negativity with no specific objections.

      • By talldayo 2025-02-022:281 reply

        > Like, what more do you want from them?

        You know what we want from them. If Apple wants to be accepted by the Open Source community, they can't reprise the Microsoft playbook with a smug "Think Different" twist. This is basically a beat-for-beat rerun of the C#/Dotnet situation with a different font and Corinthian leather.

        The internet at-large is sick and tired of tending to Apple's scraps at their obscure whims. If you are a developer that isn't already implicated to use Swift for iOS development, you'd be wasting your time doing Cupertino's work bringing up their language for them. They do not care, and only want to exploit your time and productivity like they do with the App Store. Much like C#, this is a scenario where everyone but the main benefactor will be thrown under the bus.

        • By MBCook 2025-02-022:541 reply

          Damned if you do, damned if you don’t. The perfect way to draw companies to embrace open source.

          • By talldayo 2025-02-023:281 reply

            They don't embrace Open Source, that's the problem. I don't even have to invoke the Halloween Documents to erode faith in FAANG as an Open Source steward, half this thread retched at the idea of using Swift out of principle.

            Apple is welcome to head down the same road they're going if they think it's working out for Swift. Developers aren't going to magically warm to it any more than they trusted C# unless Apple makes some unprecedented change in their attitude towards Open Source. The world doesn't owe them shit.

            • By pjmlp 2025-02-026:541 reply

              Just like any other big corps, for every big corp you might think of, I can provide an anti-Open Source example from one of their business units.

              Lets play this game?

              • By talldayo 2025-02-0316:03

                Go ahead. Free Software has no obligation to satisfy the criteria of FAANG's business units, I'd actually find it quite funny to hear the litany of complaints you've compiled for a group of people that barely knows you exist.

      • By vi4m 2025-02-0315:251 reply

        I'm a bit confused about the "don't trust Apple" sentiment here.

        Swift has been working seamlessly with Linux and Visual Studio Code for years now. You might be surprised to learn this, just like this guy was https://www.youtube.com/watch?v=LTP5c4NqA8k&t=5484s

        Swift is compatible with WASM and embedded systems. It has a well-defined concurrency standard, and as a compiler, it's been tested with massive codebases worldwide.

        The community is incredibly supportive (Ted Kremenek's team is super active, attending community conferences and supporting the Server Side Workgroup). They also have an open swift-evolution process that mostly works.

        Xcode not being open-sourced? Not a big deal. It's an older codebase optimized for different use cases. Their approach is to break Swift down into smaller, focused components (Package Manager, LSP server, a formatter, etc.)

        JetBrains didn't open-source their IDEs either, and people don't complain about it. So, it's the same story, but it's better since you don't have any historical issues like "Oracle JVM" lurking around, causing trouble for the community.

        • By talldayo 2025-02-0318:29

          > I'm a bit confused about the "don't trust Apple" sentiment here.

          Let me help you out; replace "Apple" with "Microsoft" and it will make a lot of sense suddenly.

          The Open Source community has heard all this before. We've seen Sun Microsystems "generously" publish their Java spec to the public, we've seen Microsoft "give" their community C#. In the end, it's always more trouble than it's worth to cooperate with these language stewards and someone (either the business or community) ends up getting burned. I don't think many developers look at Swift with optimism that it won't end in the same Dotnet/Mono nightmare we've seen in the past.

          You can lead a horse to water, but you can't make them drink. Apple has invested heavily in a language that, like C#, has a bunch of incredible features. Unfortunately they have yet to invest in the developer relations requisite for making such a language popular. Lord only knows that I'm not wasting my time to do Apple's work for them just to get a cross-platform app to compile with upstream LLVM and Clang. I could use any other language - nobody is going to commit to an ecosystem that treats them as a second-class citizen.

    • By JTyQZSnP3cQGa8B 2025-02-0119:517 reply

      This has been my experience for a long time. Swift is nice but why would I waste my time working on a language that is too tied to the Apple platform even if it's open-source when we have more universal scripting languages like Python, or languages like Kotlin that are compiled but have more support (because I trust JetBrains way more than Apple at the moment), or languages that are most strict like Rust but have more momentum and safety?

      They painted themselves in a corner. Apple being the best computing platform while trying to please everyone can never be a serious proposition. Either they are the best and everyone uses macOS, or we have to be so careful that any alternative is more interesting that what they propose.

      • By thih9 2025-02-0120:112 reply

        > why would I waste my time working on a language that is too tied to the Apple platform

        This might work the other way round: starting from people familiar with macos or ios development who want to write for other platforms.

        Then the question becomes: why would a developer learn a different open source language when they can use what they already know. And sure, depending on the context they might still go with Python/Kotlin/Rust/etc.

        • By hu3 2025-02-0122:272 reply

          > people familiar with macos or ios development who want to write for other platforms.

          This is a rather small userbase when it comes to enterprise.

          Especially because Swift will never be as versatile as Python or as efficient as Rust.

          And then there's also Go, C# and Kotlin with much better tooling.

          • By privacyis1mp 2025-02-0123:132 reply

            Xcode gives me such a hard time that I started considering writing in Kotlin for macOS, just to have a normal IDE. We used to have AppCode (from JetBrains) and it was great. I wonder why Apple didn't support JetBrains, after all, it would have been to Apple's benefit.

            • By ChrisMarshallNY 2025-02-022:45

              Personally, I never liked AppCode. It was too much like Eclipse (which I also never liked).

              Me not liking something, does not make it bad. It’s just not my choice. I’m glad it existed, because it probably prompted Apple to do better with Xcode. Lots of people that I respect, used it.

              These days, Xcode is Big Bug Ranch. When “Delete the DerivedData folder” is S. O. P. for developers, and Apple tweaked Xcode to reduce its impact on the project, you know that they have waved a white flag to bugs.

            • By joseda-hg 2025-02-023:08

              There's even history of it working before, with Google / Kotlin

          • By pjmlp 2025-02-026:58

            Since Apple has moved themselves out of the server market, folks need to at least be able to target BSD/Linux server workloads, and naturally using Swift as well instead of another language is a desired option.

        • By makeitdouble 2025-02-0123:532 reply

          That crowd has the disadvantage of not being primarily interested in the other platforms, so they won't be much invested in optimizing or better matching the target capabilities.

          That's the same dynamic as web devs writing React Native apps: you won't expect them to contribute extensions that manipulate local apfs metadata for instance.

          So while it's nice to have them use the tools, you still need people who primarily care for non Apple platform and embrance swift for their purpose to have it expand.

          • By qaq 2025-02-020:50

            Hmm Snowflake and Apple are rewriting FoundationDB in Swift. Swift has pretty good dev. ergonomics and good interop with C/C++ so it might find it's niche outside of Apple.

          • By pjmlp 2025-02-026:56

            That crowd needs other platforms when using servers, as Apple has moved itself out of the server market, so at very least BSD/Linux workloads.

      • By cosmic_cheese 2025-02-0120:133 reply

        Can only speak for myself, but I’d love to be able to use Swift elsewhere so I don’t need to drag around a JVM and all the things that come with it (Kotlin) or have to wrestle with Rust’s sematics and disinclination towards old style imperative desktop UI development. Swift isn't perfect of course, but it’s the closest I’ve come to a language feeling “comfy”.

        • By pjmlp 2025-02-026:59

          You mean like the huge ecosystem of libraries for almost anything one can thing of, and IDE tooling, with 30 years of experience in production?

        • By rnikander 2025-02-042:55

          I was using Swift before. Currently learning Rust. Want to use it for cross-platform UI, and I'm stuggling with exactly what you describe there.

        • By desiderantes 2025-02-0122:303 reply

          So you haven't heard of Kotlin Multiplatform.

          • By privacyis1mp 2025-02-0123:151 reply

            What are your experiences of using Kotlin for modern macOS/iOS development? How's the support looking when Apple releases new XCode?

            • By aalimov_ 2025-02-028:35

              Kotlin Multiplatform (KMP) is neat for android devs that want to be able to code for both platforms using a toolset/language they are familiar with, but for iOS development KMP is a hassle (personal opinion). I’d rather just write the code twice. Also, I actually like Xcode. As for Android Studio, up until the more recent versions the GUI felt really clunky to me (which made working in it a bit of a slog).

          • By cosmic_cheese 2025-02-0123:281 reply

            Have heard of it, haven’t investigated it deeply. Looks to still have some of the less-great points of the Java ecosystem on the build side of things (gradle) which is a detractor for me.

            Kotlin’s syntax is also weird/quirky in some ways.

          • By mdhb 2025-02-0218:02

            Or Dart

      • By GeekyBear 2025-02-0122:042 reply

        > languages that are most strict like Rust but have more momentum and safety?

        Like Rust, Swift is a compiled language that offers memory safety by default.

        The creator of Clang and LLVM also created Swift, and interoperability with C was an explicit design goal.

        So Swift offers the memory safety and data race safety of Rust, in a compiled language, without giving up tight integration with C.

        (To be fair, better C integration is something the Rust community is looking to add.)

      • By kelnos 2025-02-0120:562 reply

        > Either they are the best and everyone uses macOS

        "Best" obviously means different things to different people, but at least by market share, macOS has never been the best. Modern Apple doesn't seem to care about market share outside of the iPhone (and even then, they are still more interested in the iPhone being a premium product than winning on market share).

        I used to like macOS, 15-20 years ago, but now it's just power-user-hostile and considerably more locked down and buggy. That's not the way to be "best", by any metric I can think of.

        • By philistine 2025-02-0121:462 reply

          > but now it's just power-user-hostile and considerably more locked down and buggy.

          Sure, macOS has continued to secure more and more elements of the OS. They have taken a different approach than Windows and Linux, which both keep large swaths of the OS woefully insecure from third-party apps for legacy reasons. But for each and every new lock, there is a key. An incredibly secure OS that gives you the power to control what third-party apps access on your computer is the best power-user feature.

          • By YmiYugy 2025-02-0122:131 reply

            Mac OS does some amazing things for security. An immutable root OS, sandboxing, very user friendly disk encryption. But there are certainly decisions that hold back the platform. Their business decisions have driven most developers away from the App Store. There is a notarization process, but it imposes a burden that many small open source projects can not bear. They don't have an easy way to run untrusted software in a containerized way (compare Fedora toolbox). Installing things globally via homebrew or a random install script is still the way to go.

            • By philistine 2025-02-0123:042 reply

              > Their business decisions have driven most developers away from the App Store.

              > They don't have an easy way to run untrusted software in a containerized way (compare Fedora toolbox).

              The App Store is the way to run untrusted apps in a containerized way.

              • By chipotle_coyote 2025-02-024:05

                I think if your app is on the App Store, it's kind of trusted by definition, isn't it?

              • By fcantournet 2025-02-0123:321 reply

                It's "the way" that apple wanted it to be, but it's not the way that humans have chosen.

                Typically not a great idea to be against humans, especially the ones that give you money.

                • By ChrisMarshallNY 2025-02-022:48

                  > especially the ones that give you money

                  Last time I checked, their market cap was North of $3T, so someone is giving them money…

          • By makeitdouble 2025-02-020:05

            They're also hitting the classic "strategy tax"

            When Apple secured the OS from third party, they also purposefully closed the door on deeper third party integration to privilege their ecosystem.

            macOS only being half as useful for Android users makes it harder to be the "best" for that swath of users. iPadOS being the only tablet form in the ecosystem will also distance other users etc. They just can't please everyone while locking them in a limited ecosystem.

        • By virgil_disgr4ce 2025-02-0121:481 reply

          > now it's just power-user-hostile and considerably more locked down and buggy

          Hm, I've been using macOS (alongside others) for the past 20 years straight. In what ways is it hostile and buggy?

          • By pmarreck 2025-02-024:10

            Secure Enclave, having to use only signed apps and kernel extensions, stuff like that I imagine.

      • By wahnfrieden 2025-02-0120:55

        See https://skip.tools for a new entrant

      • By DidYaWipe 2025-02-028:10

        The Python ecosystem is a sad mess.

      • By pmarreck 2025-02-024:061 reply

        Python is not compiled, it is interpreted, and it has many warts.

        Kotlin depends on the JVM and is also not compiled.

        Rust? Now you're talking. Except that it has warts, too.

        • By zoot64 2025-02-026:461 reply

          Kotlin is compiled in the sense that it compiles down to bytecode read by the JVM. It's not machine code level but it is still compiled to a certain degree. And Kotlin can compile natively for multiple targets including macOS and iOS without need for the JVM. There's also WASM support too.

          • By pmarreck 2025-02-030:47

            Did not know about non-JVM compilation. Does it include the JVM as part of the binary then? Links?

    • By kelnos 2025-02-0121:024 reply

      This feels similar to C# and Microsoft's other CLR/.NET languages. Sure, they've broken away a bit and aren't exclusively used to run things on MS platforms, but still.

      And Swift is even more tied to Apple, at least to my inexperienced eye. I'm not really an Apple person (Linux, Android), even though I once really enjoyed their hardware... Swift is so far down on my list of languages to look at that I probably will never get to it.

      • By liontwist 2025-02-023:071 reply

        .net core is one of the best ways to write linux backend applications.

        • By pl4nty 2025-02-0223:291 reply

          this, because msft spent years and many $$$ to build an open-source ecosystem. apple hasn't done that yet, so I'm not sure why anyone would trust them

          • By stephen_g 2025-02-0312:36

            Amazing that you comment that on an announcement that is one large effort of many that Apple have been doing to build an open-source ecosystem over many years...

      • By WuxiFingerHold 2025-02-024:26

        > This feels similar to C# and Microsoft's other CLR/.NET languages. Sure, they've broken away a bit and aren't exclusively used to run things on MS platforms, but still.

        A wrong and quite outdated statement. You can develop and run C# on Linux only using open source tooling perfectly fine. I'm using Ubuntu, LazyVim with Omnisharp, dotnet CLI for scaffolding and package management. It's in the same ballpark as Go and Rust in terms of dev experience. I don't have numbers, but I guess a large fraction of new deployments is on Linux.

      • By aryonoco 2025-02-0122:372 reply

        I don't understand what "broken away a bit" means. We use C#/.Net pretty much exclusively to build the backend of our web apps).

        Most of the devs use Mac, with some Linux. Everything is run in Kubernetes (OpenShift). we use JetBrains Rider as our IDE.

        C# is a very nice, very performant (faster than Go) language, the platform is mature and robust. the tooling is excellent. It gives you good garbage collection, strong type safety, etc. All the things you need to build out the logic of business applications. And it's fully open source.

        I have looked at Swift. By comparison, the tooling is 10 years behind and the performance is not even close. I struggle to see what Swift brings to the table over C#.

        • By benbristow 2025-02-020:161 reply

          If you want to use Visual Studio Code the 'DevKit' extension which provides essential features (language server) is proprietary and requires a Visual Studio licence regardless of platform.

          Also I find since C# is an 'enterprise' language developers take the p--s in what they want to charge for, as enterprise will pay as a 'cost of doing business'. Recently FluentAssertions, a freakin test assertion library decided they wanted to charge for newer versions. You don't get that in other languages like Python/Ruby etc.

          https://youtu.be/ZFc6jcaM6Ms

          Don't get me wrong, C# is my dayjob and I love the language but for personal projects where I don't have the money I'd be hesitant to touch it.

          • By neonsunset 2025-02-020:591 reply

            DevKit is completely optional.

            The language server is part of the SDK itself. The language server integration, debugger and all the features that make VS Code a good tool to write C# in are a part of base C# extension which is MIT-licensed and has no commercial restrictions whatsoever.

            The only "wart" is that "vsdbg" - debugger it ships with is closed-source because it is essentially the same debugger as in Visual Studio but extracted into a standalone cross-platform component. There is an open alternative "NetCoreDbg" used by the extension fork for VSCodium (and various DAP bridges to Neovim, Emacs, etc.).

            • By metaltyphoon 2025-02-022:45

              Go to definition still broken on neovim for me :/. I should be seeing SourceLinked stuff but nothing happens

        • By WuxiFingerHold 2025-02-024:33

          I used C# on .NET framework (the old .NET running only on Windows) 10 years ago at work. Then I had to use it 2 years ago again, and man, did it change! ASP.NET Minimal API is absolutely awesome, as the Generic Host integrating config, logging and DI is a great too. A very mature and complete framework.

          It brings everything to the table a great modern language and ecosystem needs. Even null safety.

          Regarding error handling, I don't have a strong opinion yet. I think Rust has nailed it, but C# (with unchecked exceptions) didn't create any issues in the projects I worked on.

      • By codr7 2025-02-0121:152 reply

        Sorry to hear that, I wouldn't bet anything on Apple but the core language contains a lot of good ideas imho.

        • By nwienert 2025-02-0121:422 reply

          Seems lovely but headed in a Scala-like bloated direction. The "too complex" type issues were really bad last I tried.

          And one of my biggest gripes is the way you can extend things from anywhere else, easy to cause a mess.

          • By metaltyphoon 2025-02-022:421 reply

            Swift is getting out of hand after Chris left and Swift UI was introduced. The language has over 210 keywords… thats crazy

            • By saagarjha 2025-02-027:511 reply

              Keywords are a bad way to judge a language.

              • By metaltyphoon 2025-02-030:201 reply

                Not saying you are wrong but tell me why it would be a good idea to have hundreds of keywords for a programming language.

                • By saagarjha 2025-02-032:12

                  Because not having hundreds of keywords means that either you have some parts of the language that are "this has a special meaning please don't touch" (double underscores are good enough, right guys?) or "we reassigned 10 different things to the same keyword to keep the number low" (ahem, static).

          • By codr7 2025-02-022:47

            Hm, I have to admit I have the same feeling.

            But it is a shame, because many of the ideas are good imho.

        • By moooo99 2025-02-0121:33

          I’ve spent some time looking into swift as well and was quite pleased with the overall language, it really contained some really good ideas. This makes it a bit of a shame that it is tied so closely to Apple

    • By VWWHFSfQ 2025-02-0119:453 reply

      I doubt Apple really cares much about competing with other languages, tooling, or platforms when it comes to Swift or Xcode. They have a completely captured audience and ecosystem, and anything beyond that isn’t even a "best effort" — it's more like, "You're welcome to see if it works for you, but don’t bother us if it doesn't."

      • By st3fan 2025-02-0119:531 reply

        I don't know about Xcode, but Swift is open source with an active community so if it doesn't work for you then you can definitely bother the Swift Open-Source project with a pull request or a proposal for a language or tooling improvement. You can also have a discussion on the forums or in the bug tracker with fellow contributors.

        You can also make the change in your own fork and use that.

        This is exactly how for example the Rust or Python open source projects work. And like those projects you can look at the Swift proposals and code to see _numerous_ cases where people did bother to bother the team with change requests or directly contributed to those improvements.

        It is all open source. Check it out.

        • By dhsysusbsjsi 2025-02-0120:092 reply

          Scooby doo meme

          <Open source contributor> “let’s see who you really are”. <pulls off mask>. Apple employee.

          • By vips7L 2025-02-0123:11

            Does it matter? Most commits to OpenJdk are Oracle employees and most committees to C# or typescript are Microsoft employees.

          • By bastardoperator 2025-02-0121:051 reply

            All 1100+ contributors are Apple employees?…

            • By truncate 2025-02-0121:59

              Are 1100+ contributors active contributors and/or actually making non-trivial changes?

      • By threeseed 2025-02-0120:101 reply

        a) If Apple didn't care about competition they wouldn't have created Swift.

        b) They don't have a captured ecosystem at all. You can write iOS/macOS apps using Flutter, React Native etc. All of which are detrimental to Apple because they force apps to adopt a lowest common denominator approach and not use the latest Apple technologies.

        • By kennywinker 2025-02-0123:56

          > All of which are detrimental to Apple because they force apps to adopt a lowest common denominator approach and not use the latest Apple technologies.

          I think you might have this backwards. What you say used to be true back in the days of phonegap, where the hardware was abstracted far away, but all of the frameworks you mention provide pretty easy paths to access new APIs and hardware features. But companies that are drawn to cross-platform tooling already want a uniform experience across devices - and that's why you get the lowest common denominator being used with tools like react native.

      • By virgil_disgr4ce 2025-02-0121:511 reply

        > anything beyond that isn’t even a "best effort"

        Ehhh, I don't know, whoever's designing and implementing Swift and Xcode etc clearly genuinely care on a personal level about quality. I get that there's going to be taste involved but the amount of thought and effort that's gone into the ecosystem is very high.

        • By hu3 2025-02-0122:33

          Xcode as an example of quality? It's atrocious from my experience.

          Updates tied to OS and crashes more than it should.

    • By raincole 2025-02-026:28

      Whatever Apple's goal is being, the result is written on the wall: Swift's brand is strongly associated to Apple ecosystem for most programmers. They won't adopt it unless they're already targeting Apple's platforms.

      See C#/.Net Core. It runs on Linux for so many years. But people still treat it as "Microsoft's thing".

    • By eastbound 2025-02-0119:471 reply

      The goal is probably rather to allow CI on the cloud. Many companies are ok with open source licenses.

      • By saagarjha 2025-02-027:52

        No, because it calls out to tools which are not open source.

    • By myko 2025-02-0123:19

      Simply open sourcing major frameworks like SwiftUI would go a long way to making it usable

    • By WillAdams 2025-02-0123:07

      For folks who want opensource there is always Gnustep and Gorm/ProjectCenter.app.

    • By pmarreck 2025-02-023:59

      > I believe that this long game of Swift being "good for everything" but "better for Apple platforms" will be detrimental to the language. T

      uh, wasn't .NET open-sourced under exactly the same pro/con, except towards Windows hegemony?

    • By talldayo 2025-02-0121:222 reply

      Frankly, it makes me feel bad for Chris Lattner. This guy's been worked his ass off to create a genuinely new language with all the bells and whistles he can fit, and his employer is the one that held him back the most. It took years for Foundation framework to get serious multiplatform commitment, and unless something changes drastically I think that's going to be the sour taste that developers have in their mouths.

      Apple in general seems to only understand software development through the lens of oppressive control. Maybe that's a security imperative for consumer products, but in Open Source it is an outright suicide pact. You have to treat every major platform as a first-class target, otherwise the major platforms will all switch to something better.

      • By meindnoch 2025-02-0121:35

        Lattner hasn't been working at Apple since 2017.

      • By raminf 2025-02-0122:24

        Lattner left Apple a long while ago. He's been working on Mojo, a different (Pythonic) language and runtime: https://www.modular.com

  • By alain_gilbert 2025-02-0120:108 reply

    Swift is a really cool language.

    But one thing that blows my mind is that if you ever encounter an "index out of range" error, the (massive) error message that you get doesn't tell you anything about where this error occurred... no line number... no nothing...

        let a = [1]
    print(a[1])
    Is all you have to do to reproduce the error.

    The error looks something like that https://pastebin.com/MQV82SaR

    And gives you no useful information as to how it happened or how to fix it.

    compare that with Golang which tells you, it happened in main.go at line 4.

        panic: runtime error: index out of range [1] with length 1
    
    goroutine 1 [running]:
    main.main()
     /Users/username/main.go:4 +0x15
    exit status 2
    EDIT: with the LLVM_SYMBOLIZER_PATH set https://pastebin.com/8M9Dbrgj this doesn't provide anything useful either.

    • By mojuba 2025-02-0120:191 reply

      You have a stack dump, which means you will get all the information if you symbolicate your crash report. Xcode can do it for you automatically, but some manual methods also exist.

      • By robotresearcher 2025-02-0120:322 reply

        Indeed the error report being complained about explains this and tells you how to fix it.

        Maybe the friendly default would be to have the symbolicated reports on, but perhaps this has performance impact so it’s off.

        • By kergonath 2025-02-0120:571 reply

          > Maybe the friendly default would be to have the symbolicated reports on

          As a comment just below says, the solution is quite simple:

          > ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it

          • By alain_gilbert 2025-02-0121:352 reply

            Here is the output with the environment variable set.

            https://pastebin.com/8M9Dbrgj

            This doesn't provide anything useful either.

            • By brailsafe 2025-02-0123:061 reply

              Seems like there's an architecture error or something, the last line indicates you might have an error with the flag:

              > zsh: illegal hardware instruction LLVM_SYMBOLIZER_PATH=/usr/local/opt/llvm/bin/llvm-symbolizer swift main.swift

              • By alain_gilbert 2025-02-0123:17

                that's not related to the symbolizer thing. It seems to just be part of the "index out of range" crash. I get the same thing without using the symbolizer.

                    zsh: illegal hardware instruction  swift main.swift

            • By robotresearcher 2025-02-0123:02

              Ouch, and yuk. I stand corrected!

    • By g0ld3nrati0 2025-02-0210:08

      I am getting proper error feedback,

      ``` swift_hello_main + 322 in swift-hello at /home/fermi/Documents/temp/swift-hello/Sources/main.swift:64:8

          62│
    63│ let a = [1]
    64│ print(a[1])
      │        ▲
    65│
      ```

    • By Pesthuf 2025-02-0120:223 reply

      What if you follow the advice here

      >Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):

      ?

      • By Cyph0n 2025-02-0120:401 reply

        What if the error was more descriptive out of the box? Unless of course the goal is to just compete with C++ error reporting.

        • By catgary 2025-02-0121:08

          The goal is to probably avoid duplicating efforts when llvm-symbolize already exists.

          There’s obviously a snarky comment to make here about Go developers and duplicating efforts.

      • By alain_gilbert 2025-02-0121:21

        If I follow the advice

        https://pastebin.com/8M9Dbrgj

        Not sure how that's any better... I still have no idea that the error occurred on line 2

    • By saagarjha 2025-02-027:54

      The Swift REPL sucks for this. I would suggest you compile to a binary and use your normal debugging tools.

    • By jitl 2025-02-0123:581 reply

      Swift outside of Xcode is a bit rough around the edges, I think because more attention goes into making Xcode friendly. I opened Xcode, made a new playground, and hit run, the code crashes and highlights the line where the error occurred in red. Not to excuse Swift's jankyness, just saying that the kind of default experience is more an IDE-first design compared to Go's very good unix-first design.

      https://monosnap.com/file/qhlwD6aXUW5bcl3TV5lPmKFDgjWDtD

      • By alain_gilbert 2025-02-020:072 reply

        I'm just curious, if I was to run my application on a linux server.

        How would I ever know what caused the crash?

        when I compile using `swiftc main.swift` and run with `./main`, the error seems even more useless.

        all I get is:

            Swift/ContiguousArrayBuffer.swift:600: Fatal error: Index out of range
    zsh: illegal hardware instruction  ./main

        • By jitl 2025-02-020:21

          I don't know, I write Swift on a Mac targeting macOS or iOS. I usually have Xcode open to build/run/debug and for documentation lookup, and alternate between that and VSCode for actually writing the code; worst thing about Xcode for me is the find-replace, that's probably the biggest reason I keep VSCode open.

        • By saagarjha 2025-02-027:55

          You can load the coredump into GDB.

    • By AdrianEGraphene 2025-02-0122:461 reply

      Thanks for reminding me of why I shy away from Swift and dove into the arms of Kotlin Multiplatform.

      • By WD-42 2025-02-021:411 reply

        Yea because kotlin without a jetbrains ide is such a good experience.

        • By abenga 2025-02-022:34

          At least the jetbrains ide exists for all major platforms.

    • By compootr 2025-02-0120:28

      Verbosity. That's..... yap-ple!

  • By aristofun 2025-02-022:254 reply

    Swift itself is a great piece of tech.

    But it is doomed to fail as a general widely adopted language unless apple makes few critical moves including open sourcing everything including XCode, providing support for 3d party IDE developers (because xcode is terrible), creating decent package manager, adopting testing as first class citizen etc.

    There is just no economical sense for anyone to invest in swift until all the above (and some more) is done.

    • By easeout 2025-02-022:471 reply

      For what it's worth, they ship a solid VS Code extension and LSP. Their swift-testing package is the new open source and cross-platform successor to XCTest. The same can be said of swift-foundation as compared to Foundation.

      The path they've chosen is not to open source Xcode, but to move the things Swift needs on all platforms to the Swift language project and common implementations.

      Personally I think the main problem with the language, besides Apple's earned poor reputation in FOSS circles, is the compile times. In the source-stable era of the language I'm not sure how they can really be fixed to the degree I'd be happy with.

      • By fastball 2025-02-023:071 reply

        Are there any LLVM langs that have fast compile times? I think that just kinda comes with the territory of having that IR step + all the optimizations that happen at compile time to help runtime performance.

        • By easeout 2025-02-023:251 reply

          That's a good point. I had in mind that there's some regret about the combination of type inference with type-based overloads, due to the search expense it adds to what ought to be straightforward parsing of long expressions.

          • By fastball 2025-02-023:273 reply

            Yeah, I think there are definitely parts of the language design / language features that are going to contribute, but when you need to parse to IR and then compile that to machine code, it seems any features you add that are nice for the developer are going to doubly hurt compile times. You see the same with ARC in swift (or the borrow checker in Rust).

            • By saagarjha 2025-02-027:561 reply

              Parsing IR and lowering it is not the reason why compiling Swift is slow.

              • By fastball 2025-02-030:491 reply

                What is the reason Swift compile times are slow?

                • By saagarjha 2025-02-032:12

                  Mostly type checking and name lookup

            • By Rohansi 2025-02-024:03

              AFAIK those language features are all handled in the frontend before outputting LLVM IR. LLVM optimization, code generation, linking, etc. should all be the same regardless of the source language.

            • By easeout 2025-02-027:19

              I don't know about that example—when ARC was added to Objective-C back in the day, I don't remember clang feeling any slower as a result.

    • By fastball 2025-02-023:011 reply

      Your wishlist seems midly contradictory. Why does Apple need to open-source XCode if they also provide support for 3rd party IDEs (which they already do, btw)? Also what do you not like about cocoapods for package management?

      Plenty of people make an incredible amount of money building apps in Swift, so your last sentence is just wrong.

      • By aristofun 2025-02-0215:182 reply

        Decent support for 3d party IDE would mean open sourcing all critical xcode parts that currently leave developers no choice.

        Cocoapods is too old and bad for modern era package management. It’s not made for swift also.

        • By akmarinov 2025-02-0221:53

          Swift Package Manager exists

          Cocoapods has been end of life’d

    • By isodev 2025-02-023:582 reply

      And make it possible to run binaries on macOS/iOS etc without a mandatory subscription and US export controls. Without notarisation, anything made with Swift is practically unusable on Apple OSs

      • By easeout 2025-02-027:24

        That obstacle and the Swift language are unrelated. The same applies to a Rust app or Electron or anything.

      • By frizlab 2025-02-025:52

        Nor with any other language. What’s the point here?

    • By frizlab 2025-02-025:51

      It’s written Xcode.

HackerNews

About