4 ms·

I love Swift, but it has the only compiler that ever told me to rewrite my code because it cannot analyze it in a reasonable length of time.

bsaul 1y ago
anecdotally, it was also the first production compiler that i saw crash, and it was on regular code.
- cvwright 1y ago
  And Swift compiler crashes aren’t even rare. You get used to it and learn how to track down the code that caused it. I think I’ve seen a C compiler crash once or maybe twice, ever.
  - bsaul 1y ago
    The fact that a compiler is crashing really makes me shiver. If the compiler is crashing because of unexpected combinations, then what about the generated code ?
    - frizlab 1y ago
      There were also issues in the generated code, yeah. But to be fair that front has been hugely enhanced; it’s been a very long while since I’ve since the Swift compiler crash (and I do weird stuff too).
zapnuk 1y ago
It's a contender for a "best idea and worst execution" award for programming languages in the last 20 years. I'd like to think that if things went just a little bit better it would have beed the ideal programming language for anything cloud / backend related.
- bsaul 1y ago
  The swift language is absolutely fantastic. But the constraints (such as objective-c compatibility) made it a juggernaut. It's actually very surprising they managed to get that language work at all given the size of it. In that regard, i wouldn't say execution was bad. It was just unrealistic, and too much was asked from it.
  - frizlab 1y ago
    ObjC interoperability is a solved problem now for Swift. They are even adding C++ and Java interop too!
    - bsaul 1y ago
      it is, but it definitely added some weight to the language. At least i think so, i'm not a PL expert. My recent point of comparison is rust, which feels like a much much smaller language, despite sharing a lot of the philosophy (struct + trait, which is very similar to what swift recommends to use nowadays, and limit the use of class).
- Someone 1y ago
  > It’s a contender for a "best idea and worst execution" award for programming languages in the last 20 years. I’m not sure of the “worst execution” part. Is it even possible to make a Swift compiler that doesn’t occasionally hit those “humans immediately see what this code does, but it takes ages to compile this” moments? I think there’s something about Swift’s type system that makes those moments unavoidable. If so, Swift is more “good idea, but too flexible to build a compiler for”, and they should have killed some of their darlings to get a better language.
- turnsout 1y ago
  Give it another shot—it is an ideal language for server-side code. The team has been working on error messages and compile times a lot over the past few years. At this point, it's extremely productive. If you run into trouble, you can usually improve the dev experience by declaring types. This is usually only an issue if you're using a lot of generics or overloaded methods. let x = y.fruit(ripeness: 0.9) // <- instead of this let x: Banana = y.fruit(ripeness: 0.9) // <- do this If Swift is giving you grief, it's probably type inference being slow or producing strange errors. Related to the above, generics are powerful, but I strongly feel they should only be used if they clarify the code. Often they obfuscate and complicate what's going on, especially if you have the interaction of two generic types.
deze333 1y ago
Don't fight compiler. Just give it an extra definition here and there and it will give you back with blazing compilation speed. Cryptic but "sexy" statements bring suffering in long term, it's a bit like raping your own laptop. No one wins.
- antfarm 1y ago
  I especially ran into it when doing last year's Advent of Code. I restricted myself to not using mutable state or custom data types, i.e. structs or classes, writing in a functional style. That style involved a lot of method chaining (i.e. x.map(...).reduce(...)...) and, of course, of closures. I had to introduce a lot of helper variables to break up my longer transformation pipelines to make the compiler happy. I hope Swift is not going the way of Scala any further, which I enjoyed a lot when I adopted it early on, but eventually turned into a monster of a language. Btw., for recreational coding, I moved on to Elixir in the meanwhile.
  - deze333 1y ago
    Yeah, Swift is for creating end-user products, fast iteration, fast delivery. This is where it shines. For recreational coding definitely pick something that reflects your deeper aesthetic affinity, I totally get what you mean.
ChrisMarshallNY 1y ago
That’s the “I found this on the web” Siri reply for Swift compilation. It happens most frequently, when writing SwiftUI code. It means absolutely nothing, and infuriates me, whenever I get it. It’s usually some kind of simple syntax error, but it could be absolutely anywhere in the indicated block of code. When I get one of those, the way I debug, is to comment out the entire block, then uncomment, in steps, until I encounter the issue. At that point, I usually just have to spend a bunch of time, staring at the offending section, until I figure it out.
- jayd16 1y ago
  Sounds like something the compiler could do.
  - ChrisMarshallNY 1y ago
    Yup.

bsaul 1y ago

anecdotally, it was also the first production compiler that i saw crash, and it was on regular code.

cvwright 1y ago
And Swift compiler crashes aren’t even rare. You get used to it and learn how to track down the code that caused it. I think I’ve seen a C compiler crash once or maybe twice, ever.
- bsaul 1y ago
  The fact that a compiler is crashing really makes me shiver. If the compiler is crashing because of unexpected combinations, then what about the generated code ?
  - frizlab 1y ago
    There were also issues in the generated code, yeah. But to be fair that front has been hugely enhanced; it’s been a very long while since I’ve since the Swift compiler crash (and I do weird stuff too).

zapnuk 1y ago

It's a contender for a "best idea and worst execution" award for programming languages in the last 20 years. I'd like to think that if things went just a little bit better it would have beed the ideal programming language for anything cloud / backend related.

bsaul 1y ago
The swift language is absolutely fantastic. But the constraints (such as objective-c compatibility) made it a juggernaut. It's actually very surprising they managed to get that language work at all given the size of it. In that regard, i wouldn't say execution was bad. It was just unrealistic, and too much was asked from it.
- frizlab 1y ago
  ObjC interoperability is a solved problem now for Swift. They are even adding C++ and Java interop too!
  - bsaul 1y ago
    it is, but it definitely added some weight to the language. At least i think so, i'm not a PL expert. My recent point of comparison is rust, which feels like a much much smaller language, despite sharing a lot of the philosophy (struct + trait, which is very similar to what swift recommends to use nowadays, and limit the use of class).
Someone 1y ago
> It’s a contender for a "best idea and worst execution" award for programming languages in the last 20 years. I’m not sure of the “worst execution” part. Is it even possible to make a Swift compiler that doesn’t occasionally hit those “humans immediately see what this code does, but it takes ages to compile this” moments? I think there’s something about Swift’s type system that makes those moments unavoidable. If so, Swift is more “good idea, but too flexible to build a compiler for”, and they should have killed some of their darlings to get a better language.
turnsout 1y ago
Give it another shot—it is an ideal language for server-side code. The team has been working on error messages and compile times a lot over the past few years. At this point, it's extremely productive. If you run into trouble, you can usually improve the dev experience by declaring types. This is usually only an issue if you're using a lot of generics or overloaded methods. let x = y.fruit(ripeness: 0.9) // <- instead of this let x: Banana = y.fruit(ripeness: 0.9) // <- do this If Swift is giving you grief, it's probably type inference being slow or producing strange errors. Related to the above, generics are powerful, but I strongly feel they should only be used if they clarify the code. Often they obfuscate and complicate what's going on, especially if you have the interaction of two generic types.

deze333 1y ago

Don't fight compiler. Just give it an extra definition here and there and it will give you back with blazing compilation speed. Cryptic but "sexy" statements bring suffering in long term, it's a bit like raping your own laptop. No one wins.

antfarm 1y ago
I especially ran into it when doing last year's Advent of Code. I restricted myself to not using mutable state or custom data types, i.e. structs or classes, writing in a functional style. That style involved a lot of method chaining (i.e. x.map(...).reduce(...)...) and, of course, of closures. I had to introduce a lot of helper variables to break up my longer transformation pipelines to make the compiler happy. I hope Swift is not going the way of Scala any further, which I enjoyed a lot when I adopted it early on, but eventually turned into a monster of a language. Btw., for recreational coding, I moved on to Elixir in the meanwhile.
- deze333 1y ago
  Yeah, Swift is for creating end-user products, fast iteration, fast delivery. This is where it shines. For recreational coding definitely pick something that reflects your deeper aesthetic affinity, I totally get what you mean.

ChrisMarshallNY 1y ago

That’s the “I found this on the web” Siri reply for Swift compilation. It happens most frequently, when writing SwiftUI code. It means absolutely nothing, and infuriates me, whenever I get it. It’s usually some kind of simple syntax error, but it could be absolutely anywhere in the indicated block of code. When I get one of those, the way I debug, is to comment out the entire block, then uncomment, in steps, until I encounter the issue. At that point, I usually just have to spend a bunch of time, staring at the offending section, until I figure it out.

jayd16 1y ago
Sounds like something the compiler could do.
- ChrisMarshallNY 1y ago
  Yup.