[zapnuk]

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.

[turnsout]

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.

[square_usual]

> it is an ideal language for server-side code

Maybe, but in my most recent attempt to use vapor (~a year ago?), the project it created with `vapor new` had inscrutable compilation errors off the bat, and so I immediately gave up.

[frizlab]

When was your most recent attempt? I think the `vapor` tool has been updated a few weeks ago[1]. Basically it was an old tool that worked around some limitations around SPM and Xcode, but it is mostly unneeded nowadays. It is basically a simple template resolver now, and I think the templates in question have been updated too.

[1] <https://blog.vapor.codes/posts/toolbox-rewrite/>

[turnsout]

On ubuntu or macOS? I've found Vapor to be pretty solid—and the Vapor team is super responsive via Github and Discord.

[bsaul]

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]

ObjC interoperability is a solved problem now for Swift. They are even adding C++ and Java interop too!

[bsaul]

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]

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