3 ms·

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

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.

alain_gilbert 2y ago
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, +) } }
- frizlab 2y ago
  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.
- zffr 2y ago
  Why do you feel the stdlib needs a .sum() if using .reduce() is so simple?
  - alain_gilbert 2y ago
    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 https://doc.rust-lang.org/std/iter/trait.Sum.html
sampullman 2y ago
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.
- happytoexplain 2y ago
  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.
  - sampullman 2y ago
    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.
    - Zanfa 2y ago
      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.
      - sampullman 2y ago
        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.
emoII 2y ago
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
- happytoexplain 2y ago
  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.
  - cosmic_cheese 2y ago
    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.
    - rudedogg 2y ago
      It has nothing to do with code quality: https://danielchasehooper.com/posts/why-swift-is-slow/ https://danielchasehooper.com/posts/why-swift-is-slow/
    - mpweiher 2y ago
      Hmm...getting strong "you're holding it wrong" vibes here.
  - zffr 2y ago
    If you do a lot with combine publishers, then you might also have a hard time with the type system
  - 2y ago
dep_b 2y ago
> 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?
frizlab 2y ago
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!

alain_gilbert 2y ago

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, +) } }

frizlab 2y ago
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.
zffr 2y ago
Why do you feel the stdlib needs a .sum() if using .reduce() is so simple?
- alain_gilbert 2y ago
  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 https://doc.rust-lang.org/std/iter/trait.Sum.html

sampullman 2y ago

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.

happytoexplain 2y ago
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.
- sampullman 2y ago
  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.
  - Zanfa 2y ago
    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.
    - sampullman 2y ago
      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.

emoII 2y ago

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

happytoexplain 2y ago
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.
- cosmic_cheese 2y ago
  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.
  - rudedogg 2y ago
    It has nothing to do with code quality: https://danielchasehooper.com/posts/why-swift-is-slow/ https://danielchasehooper.com/posts/why-swift-is-slow/
  - mpweiher 2y ago
    Hmm...getting strong "you're holding it wrong" vibes here.
- zffr 2y ago
  If you do a lot with combine publishers, then you might also have a hard time with the type system
- 2y ago

dep_b 2y ago

> 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?

frizlab 2y ago

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!