181–190 of 263 posts
Earlier quoted context omitted.
This is not the same thing as swift-corelibs-foundation, which is the old project that stalled out. The officially announced plan here is for it to fully replace the old implementation of Foundation.
Shame really. Apple's platform has so many good ideas I wanted Swift to bring to the world as a cross-platform open-source effort. :(
I really like the verbosity of Objective-C - this makes the code more readable and easier to understand, even (or especially) when reading a program the first time.
Being a superset of C (and C++ with Objective-C++) means that, when necessary, one can easily write a C (or C++) method (or class) but also include existing C/C++ libraries.
I also find some of the improvements Swift brings to actually make developers more reckless and dependent on the language/compiler (yes, I liked to manually manage memory).
And a bit of a personal frustration: I find a swift package/project that I want to use, download it and ...start fixing/updating the code, so that it compiles with the latest Swift version. I still have Objective-C code I wrote more than 10 years ago that compiles and runs with minimal or no change.
Earlier quoted context omitted.
While it’s true that the language is really only useful on just Apple platforms, it is still quite an amazing language. I have professionally used about half a dozen languages over the last many years, written hundreds of thousands of lines each in all those languages, and swift is a true breath of fresh air. It checks all the boxes for me, very concise and elegant to write, yet very strictly statically typed. A nice…
> upgrade to OO programming with use of protocols How exactly are protocols a Swift "upgrade" to OO programming? They were in Objective-C since the mid 90s, adopted by Java as interfaces, copied by C# etc. Also, protocols in Swift have a huge performance downside, because they decided to have them work across structs and classes: if you use a protocol in a function argument, the compiler doesn't even know the size of…
Typically you would write more protocol-oriented code - rather than using inheritance (which is mostly there for Objective-C compatibility) you define protocols and implement them for types.
This is a lot closer to traits in Rust than interfaces in Java. Among other things, a developer can define how a third party type implements a protocol they control, without subclassing or wrapping, as long as it does not require additional data.
Hot-take from someone who is currently helping to port GNUStep's implementation of the Foundation framework to the Sega Dreamcast: Gross. The whole appeal of Foundation was having this incredibly convenient, beautiful, high-level object-oriented API ontop of low-level, statically compiled performant C... The true path forward for computing is clearly an alliance among the holy trinity of god's C languages: C, C++, an…
I just... completely don't understand the appeal of Swift beyond it being Apple's in-house language. I was excited for Foundation to become open-source. Using a language you'll really only find in 1 environment is a negative. I'm going to go feel ashamed for not getting excited about a language now. I should be celebrating "more languages", but Swift is just Apple. No one outside Apple chooses Shift unless they want…
If they had waited a little bit Rust would have been a great option. That's a shame.
Swift for example defaults to copyable value types and reference types that are refcounted because that is what is most often needed for evented application code, while Rust defaults to non-copyable objects (with wrappers for things like reference counting) because of its systems development focus.
Swift also had a hard requirement of a decade of co-existance with Objective-C. A significant number of Swift types toll-free bridge with objc (and corefoundation) alternatives, and that had a considerable impact on the standard library. Their base library would be different from Rust's "std" due to needing different implementations of strings, vectors, dicts and so on.
The two do take quite a bit of inspiration from one another, and will gradually grow to support an ever-larger overlapping set of use cases, but the design constraints of the existing language will still mean that one or the other is better for a specific task.
I just... completely don't understand the appeal of Swift beyond it being Apple's in-house language. I was excited for Foundation to become open-source. Using a language you'll really only find in 1 environment is a negative. I'm going to go feel ashamed for not getting excited about a language now. I should be celebrating "more languages", but Swift is just Apple. No one outside Apple chooses Shift unless they want…
There was a lot of excitement when it first came out. I tried Swift for Linux, and soon realized it was a meh experience (NS this, NS that... NextStep is still there) and switched back to Rust. It could have been a strong Rust alternative.
It's sad Apple didn't jump on the Rust train, it would give them a major boost in security and maintaining ease.
This makes a lot of sense considering swift's primary target: app developers that build end-user facing software, as opposed to core system developers for rust.
The Swift feature I miss in other languages is `enum` cases with parameters and `switch` blocks having to cover all cases, it's so convenient.
Earlier quoted context omitted.
The package manager has been open source, cross platform and available since pretty much from the start. The standard library is becoming cross-platform as we discuss it here.
> The standard library is becoming cross-platform as we discuss it here. I'd argue that it's too late already, the ship has sailed, Swift is heading the same way as C#.