[flagged]
Apple is open sourcing Swift Build
71–80 of 300 posts
Re: Apple is open sourcing Swift Build
#72Earlier quoted context omitted.
Of course! Tons of examples here: https://github.com/apple/swift-embedded-examples At WWDC24, we shared a session on embedded Swift, which is available on YouTube: https://www.youtube.com/watch?v=LqxbsADqDI4 More documentation on embedded Swift tooling here: https://github.com/swiftlang/swift/blob/main/docs/EmbeddedSw... (Disclosure: I work at Apple.)
Encountering an Apple employee in the wild is like spotting a unicorn.
Tim is a unicorn.
Re: Apple is open sourcing Swift Build
#73The discussion here reminds me so much of early C# days. It was being touted as open source and cross platform back then, and Microsoft even hired a top GNOME developer to port it to Linux and GNOME was going to be rewritten in C#. It was going to be amazing. Never quite panned out.
do you remember who was the 'top GNOME developer'?
miguel de icaza
Re: Apple is open sourcing Swift Build
#74The discussion here reminds me so much of early C# days. It was being touted as open source and cross platform back then, and Microsoft even hired a top GNOME developer to port it to Linux and GNOME was going to be rewritten in C#. It was going to be amazing. Never quite panned out.
do you remember who was the 'top GNOME developer'?
Probably talking about Miguel de Icaza. I think his history is wrong though. I don't recall any talk of rewriting GNOME in C# - they were all about their pet language Vala.
And Miguel started Mono way before Microsoft made C# cross-platform. At that point they were antagonists.
Re: Apple is open sourcing Swift Build
#75The goal for Swift should (and seems) to be to gradually separate itself from XCode, which is holding it back from its ambitions. XCode has been compared to many things, but at 3.1 stars on the App store, one must find that it is still slightly overrated.
I feel like Swift is being held hostage by Apple. I can't get get the next version of Swift, because it's being distributed with a higher version of Xcode that only runs on an OS version I don't want to install (yet), and even if I did, I'd first have to buy a new Mac for that. That trick seems to work with enough developers to make Apple ever more rich and powerful and even more arrogant (if that's possible at all),…
[deleted]
Re: Apple is open sourcing Swift Build
#76Swift 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…
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): ?
What if the error was more descriptive out of the box? Unless of course the goal is to just compete with C++ error reporting.
Re: Apple is open sourcing Swift Build
#77Earlier quoted context omitted.
You are wrong about "some parts" - you can browse github.com/swiftlang to find out. About control - serious question: how is this different from for example Rust, Go, Zig or Python? For each of those you can submit a change proposal through an official process and you can submit code changes through a pull request. But also for each of those there is a non-zero chance that a smaller group of people who do governance…
You’re only focusing on access to source code, the comment is about leadership and decision making. Remember the OmniSharp story around VSCode from just two years ago? It’s a very high profile example of what can (and eventually will) happen with corporate-controlled projects. Swift can’t evolve or even exist without Apple and so unless you’re Apple, then Swift is too great of a risk.
> Swift can’t evolve or even exist without Apple and so unless you’re Apple, then Swift is too great of a risk.
I'm not sure what you're saying here. It's Apache licensed so you can just fork it. It's got pretty active development and a whole lot of software developers that use it-- if Apple decides to somehow lock down the repo and stop accepting PRs, what's stopping a group of developers from just making their own branch? It's got non-Apple cross-platform GUI frameworks, good support in editors... Sure it's 100% not as good off of Apple systems but I'm not sure what they'd be expected to do MORE than open it up with an Apache license?
And OmniSharp works just fine in VSCode from what I see. What am I missing?
Re: Apple is open sourcing Swift Build
#78[deleted]
Re: Apple is open sourcing Swift Build
#79The discussion here reminds me so much of early C# days. It was being touted as open source and cross platform back then, and Microsoft even hired a top GNOME developer to port it to Linux and GNOME was going to be rewritten in C#. It was going to be amazing. Never quite panned out.
Wow never knew that. So glad it didn't happen
Re: Apple is open sourcing Swift Build
#80Earlier quoted context omitted.
Swift is unbelievably cool but I wonder about using Swift for an embedded project as opposed to just C or with FreeRTOS for a more capable system. Is interoperability possible - as in FreeRTOS+swift?
Why should it not, one of the design goals of Swift as C, Objective-C and C++ replacement was painless interop with those languages. Thus it is more an issue of Swift embedded toolchain being able to be used alongside FreeRTOS on the specific hardware target.
> Why should it not, one of the design goals of Swift as C, Objective-C and C++ replacement was painless interop with those languages.
This is actually a very good quality. I'm exploiting that for all it's worth in a job project where I'm gradually (file by file) converting a legacy codebase from Objective-C to Swift.
Providing an exit-strategy for Objective-C is good enough reason for me to at least have a basic working knowledge of the language.