Hacker News Reader

Comment by jakey_bakey | Hacker News Reader

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™ 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.

View on HN

If I were new to Swift and saw how complicated and version-specific the Stackoverflow answers* are for things that are super simple in other languages, I wouldn't expect things to get much easier from there. And that instinct would be right.

* https://stackoverflow.com/questions/34540185/how-to-convert-... https://stackoverflow.com/questions/32305891/index-of-a-subs... https://stackoverflow.com/questions/39677330/how-does-string... https://stackoverflow.com/questions/24250938/swift-pass-arra...

FWIW, that answer (to the second link, after edit) is really old, and you can do string.firstRange(of: substring) since Swift 5.7.

The top answer to your third question gives a pretty good explanation of why Swift string indices work the way they do (as well as showing nicer ways to spell a lot of the operations on them), which mostly addresses the first and third questions. It really seems that your last link is just asking for the `inout` modifier; I'm not sure why that one is especially confusing.

Obviously, there's always stuff that can be further improved, but none of these are especially onerous (once you get past the "string indices are not just integers" step, at least--for people who really just want to pretend the world uses ASCII or work with UTF8 bytes directly, string.utf8 may be an nicer interface to use).

The thing is, each string-related answer ended up extending it with some methods that everyone wanted it to have in the first place, and the top-voted comments are like "why do we have to do this." It also shouldn't have required multiple updates to each answer.

The time I was doing a lot of string manipulation in a team Swift project, we had to write our own wrapper that basically stored strings as arrays of printable characters because the native one was too annoying. This also protected us from all the breaking changes Apple made to strings across Swift versions.

The inout one is different. It's confusing that arrays and dicts are structs, which have different rules from regular objects, and the syntax takes some getting used to:

  func addItem(_ localArr: inout [Int]) {
    localArr.append(4)
  }

> It's confusing that arrays and dicts are structs, which have different rules from regular objects

As a long-time assembly and C programmer and now Swift programmer, I would say that structs _are_ regular objects, and things with reference semantics are weird. It all depends on your point of view!

I'm fine with either approach as long as it's consistent. Practical Swift code will have a few "inout"s sprinkled around, wherever someone happened to pass in a struct (like array) instead of an object (like NSArray). And that's without bridging and stuff like UnsafePointer involved.

Edit: Just remembered that arrays still don't act like regular structs either! https://stackoverflow.com/questions/24450284/conflicting-def...

I'm fine with either approach if it's easy to know which one I'm using at a any particular call site. C# started the tradition of moving this information to the type level, far away from the call site. Swift has adopted this terrible idea.

The philosophy of making code look "clean" at the cost of hiding critical information in some far away place is the biggest mistake in programming language design. If code happens to look clean it should be the result of being simple rather than being cleansed for effect.

Other bad ideas in the same vein are computed properties and function builders.

What do you mean by moving information to the type level?

In C and C++ (and many other languages) the distinction between value and reference/pointer is part of the variable declaration. In C# and Swift that information belongs to type definitions (except for inout parameters). Structs are value types and classes are reference types.

Type definitions are usually further away from the call site than variable declarations. Also, in C, accessing a member of a struct through a pointer requires the -> operator providing yet another clue as to whether you're using a pointer or a value.

In my opinion, this distinction is absolutely key. It should always be obvious at the call site. I don't think there is anything that has caused more bugs in my Swift code than getting this wrong.

Change a type from class to struct or vice versa and chances are your code still compiles when it really shouldn't because it's now completely broken.

If there are identity having classes (reference/pointer) that may be mutable, and value types that are always immutable, then I think it can be an “implementation detail”, part of the type, not changing semantics.

If you can’t change a struct’s field, only the whole struct, then I believe it’s fine - and the compiler may decide to copy it or change in-place depending on its available context, is it not the case?

In a language without mutability (or perhaps with something like borrow checking?), it would not be a problem. But in Swift, the option of introducing mutability always exists.

It's not impossible to impose some sort of discipline to mitigate these issues, but why is it a good idea to make values and references indistinguishable at the call site? I don't get it.

But it's not surprising. I don't get a lot of decisions that language designers have been making. The entire drive towards more and more syntactical abstraction in order to make everything look like a DSL is a mistake in my opinion.

Refs in C++ go against this, right? At the call site, it's not clear that you're passing in a ref instead of a value. I don't mind it too much cause at least the rules are the same for everything, not different for structs vs classes.

Yes. At least references are still part of the variable type and therefore likely to be closer to the call site.

Computed properties are annoying too. More importantly, they're one more inconsequential thing for SWEs to argue over in code review.

The answer you link to there is from the Swift 1 days in 2014. It was absolutely true then, but array has had true value semantics since shortly after that answer was written.

Ah, it's coming back to me now. I remember when they fixed that and I was relieved.

Three of those really are very specific to string manipulation, and doing it "right" (with all the possible representations of what a string can be) is inherently complex. I think Swift landed on the wrong side of defaults for this API, opting for "completely safe and correct" over "defaults to doing what I expect 99% of the time"

You can get a `utf8` or `utf16` "view" of a string, and index it like normal array (`myString.utf8[0]` gets the first utf8 character). But it's not going to work with complicated emoji, or different languages that may have representations into utf16, etc. Again, I think the vast majority of people don't care for complete correctness across all possible string representations, and possibly Swift has gone too far here — as noted by all the Stack Overflow posts and clunky API

On the array-pass-by-reference, I'd argue that it's valuable to learn those semantics and they aren't particularly complicated. They offer huge benefits relating to bugs caused by unintentionally shared state. Marking the parameter `inout` is a small price to pay, and really forces you to be explicit about your intentions

Swift was designed around emojis it seems. First page in the manual shows how you can use emojis as variable names. I get why Apple wants to be clear how there are different ways to index into strings (even if this is motivated 99% by emojis like "family: man woman boy boy skintone B"), but still, the API didn't have to be this confusing or have so many breaking changes after GA.

About structs and pointers, I'm familiar with them in C/C++ where the syntax is clear and consistent. It's not consistent in Swift. And arrays don't even act like regular structs, I forgot: https://stackoverflow.com/questions/24450284/conflicting-def...

Or you know, the couple of languages people speak that are not using ASCII…

The issue here isn't ASCII vs unicode, it's specifically symbols that are composed of multiple unicode codepoints.

(Which btw isn't exclusive to emojis, there's also Hangul Jamo that the Unicode standard says is used for "archaic" Korean characters, but emojis are probably the main use case.)

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

Because they rely on variadic generics they can make type inference very slow or just fail completely, leading to the infamous and singularly unhelpful compiler error, "The compiler is unable to type-check this expression in reasonable time; try breaking up the expression into distinct sub-expressions".

Swift is the only language where I've had to fight the compiler to do its job. In earlier versions like 1.x and 2.x, it would often segfault. By 3.x it was still really slow to build. I regretted moving a project off ObjC back then.

I thought maybe that was all fixed by now, but guess not?

On paper Swift has a lot going for it. In practice it's easily the worst devx out of the modern languages. And SwiftUI is still so full of bugs and performance pitfalls I'm actually quite pessimistic about the future of native apps on Apple platforms.

Yeah there's a reason people go to all that effort with React Native to avoid writing Swift code or dealing with Apple's UI frameworks, and it's actually a reasonable approach for the majority of apps.

I mean, I figure the more compelling reason to do that is so you can also ship an Android app without writing everything twice.

Sorta, but it's not as easy as they make it sound. And people will use RN even for iPhone-first stuff.

except for the thousand times you end up having to dip down into native components

I'd say most of the time it's a handful of times or less. Uniswap is a good example of a large OSS three-platform app that shares almost all the code, uses very few native dependencies, and has great UX. I maybe biased since I worked there and made the UI framework they use, though.

https://github.com/uniswap/interface

I have made a lucrative career by porting fragile, slow, bug-ridden react-naive disasters to native code bases. There is a lot of demand for this from startups that took the cross-platform shortcut and the MVP became the product.

You can make a disaster in any framework. SwiftUI is a mess, for example, and slow.

React Native took a while to mature, but with the right tooling you can ship amazing UX now.

I don’t doubt there’s a ton of crap out there.

But you’re wrong if you think you can’t make seriously great stuff with it. It’s matured quite a lot.

And the React programming model is untouched, hot reloading and dev tools far ahead, and code share is worth it with something like Tamagui that actually optimizes to each platform. If I never had to touch an ObservableObject again that would be great.

I have made a countless PRs to many of the most popular react-native dependencies because they were a buggy mess.

In fact at this very moment I’m helping a team fix a memory leak/crash in the “react-native-permissions” dependency. It’s obvious this package was not written by someone with experience. All it does is request permissions in a paragraph of code and it’s totally broken! Give me a break

I have plenty of nightmare stories to tell you about native deps.

It can get tough with the native dependencies involved.

When I was still doing contract work I rescued a bunch of native code iOS app disasters. For most apps cross platform solutions are fine.

For some apps, I can see this. Question is, did the startups regret taking the shortcut upfront, or were they fine paying later for the improved version?

Btw, sometimes I think about how much I've been paid by various people to move a backend from SQL to NoSQL then from NoSQL to SQL, despite me telling them not to.

Btw I don't think of it as a shortcut, I think it's actually the ideal end-state.

Like you dont have to know native components anyway?

In one way you centralise as much logic as you can and are encouraged to write clean code that doen't depend on platfrom quirks. In the other way you... give up and just do whatever.

I can see how some devs find it hard to not give up and just write the same logic in multiple languages, great job security!

My main app is a cross platform Flutter app. I've considered rewriting it in Swift because most of my users are on macOS or iOS but all the prototypes I've written are actually slower even after extensive performance work and the development experience makes me want to tear my hair out.

Ironic, given Flutter's infamy regarding performance (jank).

I'm actually surprised at this because while UIKit is hard to use, at least it's fast. Though I remember the concurrency model being confusing, so you could accidentally block your UI thread.

UIKit is pretty fast although a major step down in dev velocity.

AppKit on the other hand seems to be pretty intrinsically slow and the controls are looking increasingly dated.

Odd criticism.

UIKit is the iOS counterpart to MacOS’s AppKit and both are implemented as convenience wrappers around CALayers. They are also infinitely customizable. You can overload UI/NSView and draw vector-pen style on a blank canvas or render whatever you want on a GPU frame buffer. This is how MapKit, Safari, and the Camera view is implemented.

It’s a criticism from recent experience trying to build AppKit based UI. The examples you list barely use the stock widgets.

There’s decades of accumulated cruft in Cocoa that Apple discarded when implementing iOS.

Not sure what you mean by "implemented as convenience wrappers around CALayers," especially when it comes to NSView where you have to opt-in to layer-backing.

Yeah I worried about that going in too but in fact I've found it much easier to get good performance with Flutter than SwiftUI, especially for large collection views and especially on the mac.

The work the Flutter team did on Impeller seems to have paid off.

You should try to implement the iOS photos.app in flutter and see how that goes. This requires scrolling through gigabytes of photos as fast as your finger can swipe without a single hint of slowdown or a loading spinner. And it’s been that fast since.. iOS 7?

Yeah it’s not the language or the SDK that’s slow. Rather it’s inexperienced, lazy, or overworked developers that can’t/won’t write performant software.

I’ve been building iOS apps since before Swift existed. Sure like I said if you code directly to UIKit and take a little care performance is good. It’s also very fast in Flutter with even less care. Rendering images in a grid isn’t hard unless your core abstractions are all wrong.

Now try that in SwiftUI. You’ll be forced back to UICollectionView.

That’s cool. I’ve been developing on Mac before Objective-C 2.0 and iOS since the AppStore was released. Millions of downloads, featured in the store, worked on dozens of projects from video games to MFi firmware, and have been invited to Cupertino to meet with teams.

I’m not defending SwiftUI. I mostly use it as a wrapper around NS/UIKit because it’s still buggy and not as flexible.

By the way, SwiftUI is also implemented on top of CALayers just like NS/UIKit. It can be fast in theory, but you have to know exactly where the pain points are and most developers don’t know how to do that.

I'm not sure why you keep bringing up CALayers. That is not where the performance bottleneck lies in SwiftUI.

I don’t think it’s impossible with proper caches to smaller dimension versions (that supposedly Apple already generates/has access to - like they are doing a bunch of processing, like object recognition, etc).

It's only that fast is the thumbnails are not too slow, the data is all there on device, the phone isn't RAM starved, and you largely have the latest iteration of iPhone for the current software, with the most powerful chip available.

In this way, yeah, it's pretty fast. Any other way it's blank square galore.

People go to React Native to stay on their cozy Web skills, it is exactly the same if we would be talking about Microsoft and Google platforms.

I started using RN when I had 0 web skills and didn't know JS. Everything from making a simple button to hooking up the model was easier to me in RN from day 1 than the native iOS way that I'd been using for years.

As someone that unfortunately has to deal with React ecosystem, and knows reasonably well native programming across Apple, Google and Microsoft ecosystems, I have some hard time believing that, but might be a knowledge issue.

The Google ecosystem? Isn’t that also just Web-based?

Not Android

To be honest, the way they are damaging their brand/products/OS just to make a bit more money is enough to be pessimistic about Apple.

But it's very true that the state of the language can be felt in their native apps, that tend to suck pretty bad recently. I still can't get over the nightmare that is the split up of iTunes; at least we knew that it was clunky because of old age, the new stuff is just bad.

I can think of a few others where you have to do that; most of them are the kind of languages whose fans say they're impossible to write bugs in.

If Rust is one, yeah I have to fight that compiler but it's because it's doing its job and not letting me do invalid things. Not because the compiler has some feature "not yet implemented" or has bugs.

Also, is anyone familiar with the weirdness with tuples in Swift? All I remember is they never worked the way I expected, and for some reason something in our code specifically worked for tuples up to size 5.

Swift only got variadic generics fairly recently, and before that you couldn’t write code which was generic over tuple size. Instead you had to codegen versions for each size of tuple you needed to support.

I think that was it. There was also something about tuples inside of dictionaries that Swift 1 or 2's compiler segfaulted on.

Rust is hard but I've never had the compiler just throw up its hands and tell me it's up to me to figure out what's wrong.

That's not the one I was thinking of.

https://anthony.noided.media/blog/haskell/programming/2020/0...

Something like Idris or Coq would have even more complex messages, though I don't have an example on hand.

Ok but these are mainly academic research languages. Swift has the backing of the most valuable company in the world and is what they're pushing as the right way to develop for their platform.

Haskell is definitely a real industrial language!

Many of the other languages in the formally verified/dependent type space are academic, but there's government interest in things like Ada too because they don't want their planes to crash. Couldn't say how good its error messages are though.

I've seriously used Erlang for a while, and Haskell looks kinda similar. Ingenious ideas there, cool features, but in the end it's cumbersome to use. So I can see why these are niche and wouldn't consider them next to big ones like Swift or C++.

> Ridiculous, permanent, tech debt such as hardcoded compiler exceptions are permanently living in the compiler codebase.

A little search-engining didn’t surface info about this, could you point me in the right direction?

https://x.com/krzyzanowskim/status/1818881302394814717

Thank you - yeah, that smells pretty bad. But, although it says "can't be changed", could it not be changed if SwiftUI were changed? An up-to-date compiler would no longer be able to compile projects using older versions of SwiftUI, but is there not a path to get there by updating SwiftUI to not require this exception, then some time later, deprecating the older versions of SwiftUI, either throwing a warning on compilation or putting it behind a compiler flag, and then finally removing it altogether?

It would certainly take a while, but could be done if Swift is aiming to be a mainstream, long-term, cross-platform language - unless this kind of thing is just not done, or there is some technical aspect I am missing?

I get what you’re saying and largely agree, but without result builders SwiftUI wouldn’t exist, let alone “look pretty”. You seem to be devaluing the syntactic sugar it brings, which in this case makes a massive difference.

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.

C# for Microsoft and for a long time people were afraid of Amazons influence on Rust

But the reality is that many major languages already have very outsized corporate influence. Either at the language level or the compiler level.

Swift is open source and has been separating from Apple ownership as of this year.

I can certainly think of a web browser that has that same conflict of interest... in fact we are actually right in the midst of a "leopards ate our face" moment with ad blocking becomes undesirable to Google in Chrome.

> I am looking to branch out and really learn a compiled language

Tip from a friend - just learn C++. It's not sexy, it's not new-fangled, but it's rock solid, runs half the world, and you will never struggle to find a job.

You'll also understand what it is that all of the new-langs are trying to improve upon, and will be able to made an educated judgment about whether they succeed or not.

A good resource for modern C++ (albeit it seems to be down rn?) is https://www.learncpp.com/. I'm not affiliated, it's just good.

I’ve been meaning to do this for years, and just played around with rust a bit (liked it, but the wrappers around some c++ stuff i wanted to use were half baked). Learning rust, there was this “rustlings” thing [0] that was a set of guided exercises to go alongside the rust book. Fastest I’ve ever picked up a language, thanks to that. Do you or anyone know anything similar for c++?

[0] https://rustlings.cool/

https://exercism.org/tracks/cpp

C++ has a lot of things I would call new-fangled, in addition to many old ways of doing things, with no good ways to settle on which iteration to use so devs can avoid learning all of them. And some things simply require templating nightmares to work at all.

I would also not use "rock solid" in comparison to how easy it is to hit undefined behavior.

Used all over and easy to find jobs, yes.

C++ gives you a garage full of tools and lets you decide what to do with them. Ultimately, it does this because the years have shown that different people need different tools for different use cases. Few people need or use them all at once. But when you do need a specific tool, C++ has it ready for you. Some consider that a con, I consider that a pro.

I find that a lot of the newlangs take the view that since most programming only uses 20% of the toolkit, they can just dispense with the remaining 80%. Which is great, until you discover that virtually every sophisticated project needed one of those things from that remaining 80%, and they all needed a different one. A nice language for writing 'Hello world's isn't going to cut it. And so either the language insists on its simplicity and stagnates, or it just reinvents all the complexity of C++.

At which point, you were better off just taking the garage full of tools that you already had, rather than going all in on some newlang, getting blocked, and stalking a github ticket for years waiting for the lang to get that feature you need. (If you spent the time in C++ instead, its full garage wouldn't look so imposing over time!)

What's the famous quote? 'There are only two kinds of languages: the ones people complain about and the ones nobody uses.' :P

Re generics, aren't C++'s virtually the same as Rust's? Especially now that C++ has 'concepts'?

There's a lot of redundancy and things you probably should never use in C++, though. It's not complexity that needs to exist other than for backwards compatibility.

> Re generics, aren't C++'s virtually the same as Rust's? Especially now that C++ has 'concepts'?

I'm not worried about generics when I talk about template nightmares, that's more about rvalue and const overloads and vararg templates and careful manipulation of SFINAE, all coming together.

> There's a lot of redundancy and things you probably should never use in C++, though

This is just a symptom of its age. C# has this same problem, too, and it's only getting worse.

C# does have C++-esque issues but the scale at which they affect the language is not comparable. There are really no popular patterns that have become "no, never do that", poorly written code is sort of version agnostic, and even old code, particularly one like in Mono applications from back in the day, plays really nicely with modern runtimes. And the difference in ways to achieve something is almost always of type "remember this required to take 4 steps? now it's one shorthand thing that makes sense in retrospect".

You don't have any template nightmares after C++ 20 concepts. The error messages improved so much that I thought I was using a different programming language.

Something I’ve been curious about recently, is how did Linux get away with straight C for so long, considering how complex of a project it is. Did they end up reimplementing a bunch of C++ features?

Actually, regarding sophisticated projects, there’s quite some complicated projects that succeed without C++ power, like Postgres and Python.

I didn't mean to imply, if I have, that C++ is always and in all circumstances the best choice for any given software project.

The question was about the first compiled language someone should learn, and for that, C++ is great. It's going to cover most of the use cases for compiled languages, while providing relatively familiar abstractions and semantics.

C is fantastic when you need to eke out every single cycle of performance, which is why it's a great choice for Python and Postgres. But you do this by effectively writing assembly instructions, which is why it's a terrible choice for someone coming to compiled languages for the first time.

C++ gives you equivalent performance to C, for a fraction of the effort, in about 90% of the use cases. For the remaining use cases, C is a better (and often only) choice, but no one who is only learning compiled languages for the first time is anywhere near being able to write that kind of C code. (After a few years of C++ they'll be in a much better place to do so!)

I use C++ at work but am glad I didn't learn it before. Yes it's a good language for what it's made for, but there are so many features that anywhere you work, you will use it differently from how you used it before. Better to learn it on the job imo.

Just getting good and greasy with Python and JS with all the typical libs has been more rewarding for me. Nobody taught me, but it was useful.

> Tip from a friend - just learn C++.

Is that good advice for certain domains only? For example, you likely wouldn't want to use C++ for web server backend? You could, but may not want to.

Definitely. Use the right tool for the job.

But if you're looking to learn a compiled language - presumably because you want to write applications, games, or systems - then C++ is a great one to learn.

Java has problems now that Oracle is in charge. upgrading Spring/Hibernate versions is really painful when you have to switch to Jakarta imports all over

Without Oracle in charge Java would have died in version 6.

You can apply the same complaint to Java and .NET ecosystems, both doing quite well, despite not everything being open source, or being managed by entities that FOSS folks rather not deal with.

"Oracle, IBM, Azul, AWS, Google..... this and that."

"Microsoft this and that."

I was always puzzled by the swiftUI syntax. Thanks for pointer me to result builders, I understand better now. I can't help but thinking the whole thing could be re-implemented with macros now? (result builders appeared in 5.4, macros in 5.7)

Was Swift really necessary? Would it really not have been possible to build iOS apps on something like JavaScript?

A low level language that's ergonomically interoperable with objective-c was probably the best choice.

Apple never set out to create Swift. Chris partner worked on it for fun in his spare time, and when he realized it could go somewhere he went through the channels to get it turned into an official project. With that being said it was tailor made to address important issues for Apple developed. For example, it has great interop with Objective-C which was a requirement to get it adopted, first at Apple, and then with the wider community. It is also built with safety and security in mind removing lots of undefined behavior and adding null safety. It is also statically typed while JavaScript isn’t. There are a whole host of other goodies that it has that make it better for Apple developers than just adopting JavaScript. Chris partner has lots of talks where he goes over the reasonings

>Chris partner

Chris Lattner

It wouldn't be performant enough. Resist the urge to go as abstract as possible on a battery-powered device someone else is paying for.

Reply on news.ycombinator.com