Comment by danpalmer | Hacker News Reader

Comment by danpalmer | Hacker News Reader

Parent Full thread

That's not really my impression at all. I see it as a fairly opinionated language that has taken a lot of inspiration from Ruby and Haskell. Things like strings are strongly opinionated and have gone through multiple revisions to get them to where they are.

One of the opinions is that it values expressiveness, and having multiple ways to do things that means you can choose a nice way to express each line, rather than always being forced to write it the same way.

This is a trade-off. To use `guard` as an example, sometimes it may be clearer to use a guard, and sometimes it may not. Swift has chosen to provide both options, at the cost of users needing to learn both.

I think it developed a negative reputation for the fact that the first few iterations did have a lot of breaking changes and added a lot of features. This made sense to me, the first version was somewhat of an MVP and it needed plenty of work still, but the language is relatively mature now and has stabilised significantly in recent years.

The compiler isn't generally that slow overall, but there are performance edge cases where complex type-checking can take far longer than other things. If you're having problems with speed, I'd recommend profiling your build, it's possible there are a handful of functions that are taking most of the build time.

> [Swift] values expressiveness, and having multiple ways to do things that means you can choose a nice way to express each line, rather than always being forced to write it the same way.

There are at least two major problems with this kind of PL design approach: 1.) when you work on a large codebase from multiple contributors, all the possible combinations of the available syntax and standard library calls will eventually get used, making your brain frustrate quickly when reading code written by others, and 2.) when you interview for a new job, all the possible combinations of the available syntax and standard library calls will eventually be asked about by interviewers, making you look and feel like an incompetent programmer.

I have to agree with the OP - Swift seems to be an unreasonably bloated PL. Unless one plans to work only with Swift all the time, learning all there is to learn about Swift on the way, it might be easier to just use Rust or Go.

Rust and Swift have about the same amount of syntax imho, and often share a lot of it. Go is simpler as a language but you end up writing more code to accommodate that.

> Rust and Swift have about the same amount of syntax

I wouldn't agree, I feel Swift has significantly more surface area than Rust.

But even syntax and standard libraries aside, I think that Rust is significantly more "explicit", "consistent" and "predictable" than Swift. I consider those to be very important qualities in a PL. Maybe that's why Rust was easier to learn and memorize than Swift (with the exception of the Rust borrow checker and lifetime annotations that indeed have to be well understood to be even usable).

But it might be just me.

Hmm can’t say I agree about the significantly more surface area. I switch between rust/C++/Swift fairly regularly for work, and I think they’re roughly similar in complexity with the exception of Rust having lifetime annotations and Swift having computer properties.

Where I do think Swift has a lot of noise though is @attributes. There’s just so many attributes to learn, especially if you happen to do SwiftUI or ObjC interop. Though rust has the same issue , it’s just there’s no ubiquitous UI lib like SwiftUI. I imagine it would have the same if it did.

> If you're having problems with speed, I'd recommend profiling your build, it's possible there are a handful of functions that are taking most of the build time.

How does one do that? I hit this problem a lot. (I’ve since learned to use lots of explicit casts to make it less bad.)

I can't remember exactly, it's been a year since I last did this. I believe there's a setting for the threshold at which this should be logged, so you could set it to log any expression that takes more than 100ms to type-check. By default I think it just times out at 10 seconds or something.

I looked into it, and found that you can add these "OTHER_SWIFT_FLAGS" to your project:

OTHER_SWIFT_FLAGS = -Xfrontend -debug-time-expression-type-checking -Xfrontend -debug-time-function-bodies

There's also this great WWDC session on build parallelization:

https://developer.apple.com/wwdc22/110364

Reply on news.ycombinator.com