Comment by happytoexplain | Hacker News Reader

Comment by happytoexplain | Hacker News Reader

Parent Full thread

IMHO it's the best language I've used a significant amount, without a close second (where my sample size of extant languages is Swift, ObjC, Python, JS, TS, PHP, Java, Kotlin, C#, Haskell).

It's the only language I've used where I have never asked "but why?". Every language feature and stdlib API just does what it says and acts in the way that makes the most sense. You're basically forced to handle every case (null, any type of error, switch cases, etc). It's highly dynamic, yet code tends to stay understandable. Apple is thoughtful about naming things and designing APIs. It's the only language I almost never need to write utility functions for - generally the type you're operating on has a method to do what you want, which you can easily discover with auto completion. Strings are sequences of graphemes, not code units or code points, and their API reflects this.

It's not perfect, but nothing else comes as close. One of the most prominent complaints - compile time explosion - really only happens in contrived examples where you're using a bunch of literals in one expression, which isn't realistic.

However, it's stuck in a single ecosystem. And let's not talk about some of the newer frameworks. Oh, and Xcode is a joke.

And the typesystem is built in a way that it does not really help you due to typechecking being so slow. Make an error/begin refactoring in ocaml: just follow the typechecker until you’re done. Make an error/begin refactoring in swift: you plan ahead because the typechecker will crash with a timeout or give you non-root-cause errors.

Yesterday I changed the signature of a method, and instead of complaining at the callsites I got a ”ambiguous method” error for a built in SwiftUI view modifier. Kinda hard to track down if you’re not completely aware of the changes you’ve made

This falls under the "new frameworks" category I glossed over. SwiftUI, SwiftData, etc, are failures in my opinion. SwiftUI in particular abuses the type system. In your own code the type system is very helpful.

Yep. If you’re writing good code that avoids common smells things are perfectly speedy. Usually if you’re making the compiler grumpy you should be sitting back and reconsidering your design anyway.

It has nothing to do with code quality: https://danielchasehooper.com/posts/why-swift-is-slow/

Hmm...getting strong "you're holding it wrong" vibes here.

If you do a lot with combine publishers, then you might also have a hard time with the type system

If just about every big new framework in a language is a failure, what does that say about the language?

XCode (and other tooling) being a joke and compile issues make it tough for me to think of it as my favorite, but the language itself is definitely nice to work with.

The compile time issues I have mainly come from TCA, but I still see them from time to time in normal code.

I have a few other syntax gripes, but largely see it as competitive with Typescript and Rust in terms of how nice it is to use. TS and Rust blow it out of the water with tooling, though.

I'm optimistic about Rust and look forward to trying it.

TS to me is just an awkward patch on top of JS. It's really great! But only compared to JS. The mental model of its type system is difficult to form completely.

But yes, Swift's tooling doesn't compare.

It might be due to the convenience of familiarity, but I disagree about TS. If you forbid any/unknown it doesn't feel at all like an awkward patch, and as far as I can tell the type system is much more powerful than Swift's.

The main problem with TS is that your types are compile-time. You can have 0 uses of any/unknown, but you can still stuff a number into a string at runtime without any issues until it blows up.

I know you should have defined validators for every single external API, library and database, but at some level it feels silly to do all of this extra work.

Of course, but that comes with the territory. I just think it's really impressive how far TS has come, and doesn't feel like an "awkward patch over javascript" at all these days.

In new projects, I've found that it's now very rare to come across a library that doesn't provide typings, or violates the interface.

Not my experience at all. I develop daily in Xcode and compile times are excellent. One can't really compare between TS/JS interpreted languages and machine code generation. Apples and oranges. Swift compiler is fast, faster than C++. In my experience the Golang compiler is the fastest but the language is much simpler. Rust compiler is slower than C++.

As a side note, for some reason people like to bitch Xcode just out of habit perhaps. It's a kind of base line statement. Not my experience either. It's an excellent IDE for the current year of 2025. Helps me a lot and I build end-user facing apps, the proof is the love that users give to my apps. In other words, I have skin in the game.

The compile times are ok, but slower than Rust and C++ in my personal experience. What I was referring to with "compile time issues" is the occasional type resolution issue that hangs the compiler for seconds/minutes, and requires some refactoring to mitigate. This does happen a lot less with Swift 6 than it did with 1-4 though.

I've used a lot of IDEs, and spend plenty of time using XCode. It's the worst I've used by far, and the only one where I feel it necessary to edit the majority of code in a separate editor.

Writing apps that people love makes you a good developer, but says little about the tools you use.

Sometimes people mistake Swift for Xcode and vice versa. If compiler can't figure out type in reasonable time, give it some room to breathe by adding a clarifying type definition. I don't like to fight the compiler trying to bend it to my will. I am happy to offer extra help by clarifying types – magic costs performance. Compiler gives back by blazingly fast builds.

By the way, I am impressed by speed of Swift 6 project builds on Apple Silicon Macs. My non-trivial apps using a mix of Swift/C++/C files (hundreds and hundreds) get compiled in nearly real time. Feels good.

Mistaking Swift for XCode isn't the issue here. Swift is great, I'm just pointing out the issues I've had with it in large projects.

> ...give it some room to breathe by adding a clarifying type definition

Right, but that's the problem - it's the only language I've used where this is something you have to worry about, and it's not like the type system is more powerful. And often, the issues stem from external libraries outside my control. Better compiler errors would help mitigate the issue.

There's a lot to like about Swift, but I also think it's productive to identify the parts that compare unfavorably to other languages.

Xcode regularly crashes and/or ends up leaving garbage in its garbage xml files. The un-reviewable xml stuff is also a garbage of its own making. The build system is intractable. Xcode does not lend itself to segregating builds from dependency fetching, i.e. do all the internet things on one machine and donthe building on a different one. The debugger cocks out at least weekly. Sure, you can make goods app with it. We’ve been making good apps with less for decades too. Other platforms/editors are not as painful, it is as simple as that.

How interesting! Xcode very rarely crashes on me. I don't know why but it seems to work 99.9% of time the way I expect it to work. Its build system makes sense to me. Of course, it differs from other build systems but that's life, I am flexible and can learn things. Just saying.

The only thing XML Xcode generates are storyboards and xibs (and schemes also). All of those XMLs are readable. Xcode’s build system is very reasonable (though different than on other IDEs, but that does not mean bad!).

> It's the only language I've used where I have never asked "but why?"

* But why I cannot use @Published and other decorators in protocol declarations?

* But why must generics always be a pain in the ass, compared to .net, even in the most recent versions? 5 ways to do things, never the one you need

* But why is the person that designed the if case let value = .variable syntax not flagellated in a public square?

* But why is modern concurrency and SPM so undocumented?

My two mains "why tf is this not built-in" are:

"Why are tuple not Hashable ?!"

Which means that you cannot have a tuple of Int `(1, 1)` as a key in a dict, and you have to make a struct that implement Hashable instead.

And

"Why do they not have a `.sum()` and I have to do `.reduce(0, +)` every time instead."

Or implement it yourself

    extension Sequence where Element: AdditiveArithmetic {
        func sum() -> Element { reduce(.zero, +) }
    }

I think tuples will be (soon-ish) Hashable but cannot as of now because they want to do it right and need something before they can do it.

Why do you feel the stdlib needs a .sum() if using .reduce() is so simple?

Because it's annoying to have to implement it every time you make a one off script (or small projects) among other things.

And it is usually a pretty basic iterator standard to have it so that someone maybe not as familiar with concepts like reduce can just sum the sequence.

Or if someone not familiar with reduce read your code, and is like "what is that `.reduce(0, +)` thing everywhere!?" while instead it should be a no brainer `.sum()` <-- "yup make sense"

https://doc.rust-lang.org/std/iter/trait.Sum.html

It is not stuck on a single ecosystem and VSCode has an extension to use Swift in it. The Linux ecosystem is actually getting quite interesting tbh, and they even support embedded targets!

Reply on news.ycombinator.com