5 ms·

Swift as a language/ecosystem does seem to check all the boxes in contrast to other modern, mainstream languages; it looks, to me at least, like a much more erg

Swift as a language/ecosystem does seem to check all the boxes in contrast to other modern, mainstream languages; it looks, to me at least, like a much more ergonomic alternative for building applications compared to Rust and Go. It's considerably faster and more type-safe than Python and Ruby. And it has a drama- and shenanigans-free licensing model that I personally am much more comfortable with as opposed to the shitshow that is Java (and, to a lesser extent, .Net). I've been reading lots of Swift docs/articles, and made quite a few book purchases from raywenderlich.com and hackingwithswift.com. My "gut feeling" tells me making the investments to become proficient in Swift, and eventually mastering it, will pay off big time. As a web-focused developer, I must admit I found Objective-C and UIKit intimidating, but with SwiftUI, Apple seems to be lowering barriers to entry; if you know something like Ember, Vue, React, or Angular, you won't struggle too much trying to grok SwiftUI. With Vapor becoming a mature framework, and Apple giving its official blessing for the development of server-side Swift libraries and tools, it does seem like we may soon reach critical mass on the server, and there is a lot of appeal in being able to consolidate and develop with one language across the stack. If we can get a Swift-to-Kotlin compiler and a Swift-to-JS compiler (there are already Swift-to-HTML DSLs, and I have been experimenting with a Swift-to-CSS DSL - with my limited proficiency in the language - and it does not seem totally impractical), it's not unreasonable to imagine Swift becoming a "rule them all" language (I remember reading somewhere that Chris Lattner said his goal with Swift was "Total World Domination" and didn't think it was that far off, but can't find the source now).

abjKT26nO8 6y ago
On the other hand, Swift changes so frequently that book authors teaching the language can't keep up with Apple to write up-to-date books. By the time a book comes out covering version N, we're a couple months away from version N+1. In this situation I can't trust I will be able to buy a book, learn the language and become comfortable with it before there is a new version with major changes. It's a very moving ground. As for performance, it would be cool if every single thing wasn't behind an atomic reference counter, making it slower than even garbage-collected Go: https://media.ccc.de/v/35c3-9670-safe_and_secure_drivers_in_high-level_languages https://media.ccc.de/v/35c3-9670-safe_and_secure_drivers_in_... (the relevant part starts at 33:06).
- ralmidani 6y ago
  Regarding language changes, I think this has improved quite a bit. I forget if stability was introduced in 4.x or 5.x, but code written today should be fine even when run through a new major version of the compiler. You can simply ignore new language features you aren't ready for until your codebase is due for a refactor. Regarding ARC, you don't have to use reference types in Swift, and the community seems to agree that structs are more suitable than classes for most use cases (a SwiftUI app is made of structs that conform to certain protocols, and those structs can be initialized, copied, and "modified" with little overhead). The cool thing about Swift is that structs can still have methods, computed properties, and custom initializers. So if you're coming from Python or Ruby or Java, or think OOP can help you organize your code, you don't have to throw away everything you've learned in order to be productive and write elegant code (and Swift brings a few new OOP tricks of its own).
  - wool_gather 6y ago
    > I forget if stability was introduced in 4.x or 5.x, but code written today should be fine... They've always provided source compatibility modes in new releases of the compiler so you can delay making syntax changes to an existing codebase if you need to. You're thinking of ABI stability, which is in place as of Swift 5, and doesn't have anything to do with what parent is talking about.
    - saagarjha 6y ago
      For some time; at some point newer compilers will drop support for older versions.
- raydev 6y ago
  > Swift changes so frequently that book authors teaching the language can't keep up This hasn't been true for a couple years.
ksec 6y ago
>I remember reading somewhere that Chris Lattner said his goal with Swift was "Total World Domination" I think it was ATP Podcast https://atp.fm/205 https://atp.fm/205 But if you are listening to ATP most of the guest and host aren't really liking swift at all. And prefer to stick to Objective-C for as long as they could. In someway I could understand that, Swift all of a sudden has 10x increase in complexity compared to Objective-C.
- zionic 6y ago
  >And prefer to stick to Objective-C for as long as they could. I know these types, and they're extremely frustrating. Swift is superior to Objective-C in just about every way a modern programmer could want.
  - saagarjha 6y ago
    > Swift is superior to Objective-C in just about every way a modern programmer could want. Reflection and dynamism are fairly big areas where Swift falls short. A couple more: interoperatibility with C++, any form of macro support, ability to shed the runtime where convenient…
  - lenkite 6y ago
    Not in interop. Objective-C++ is how I write macOS apps. So does facebook AFAIK.
- saagarjha 6y ago
  Some of the members of that podcast write a fair amount of Swift. Actually, I think the majority of the hosts do, and the holdout is seriously considering doing so as well.
fauigerzigerk 6y ago
Swift started out as a pretty nice language, but in my opinion there are some major problems: The combination of ubiquitous closures and reference counting is dangerous. Avoiding circular references is not nearly as easy as you might think and reference counting is slow (low memory usage is an upside though). And lately, the language has become rather convoluted. They have added features that make Swift code hard to read. Function builders in particular are a terrible idea. I know many people like internal DSLs. I don't. I think it's a big mistake to overload the syntax of a language to such a degree that reading a piece of code in isolation tells you very little about what it does, because somewhere far away there may be a mode switch that completely changes the semantics of that piece of code. Consistency is more important than "looking clean" at all cost.
- ralmidani 6y ago
  I agree function builders have a lot of potential for abuse. But I prefer to take a "with great power comes great responsibility" approach over saying a feature should _never_ be allowed in a language. If I'm promoting a DSL that makes heavy use of something like function builders, I should provide robust documentation so other developers know what to expect. And those developers should, on the other hand, at least skim the docs in order to get a basic understanding of how the DSL works. If someone goes through the trouble of providing docs to accompany a DSL, and a downstream developer doesn't bother to read them, is that really the original developer's fault?
  - fauigerzigerk 6y ago
    Consistency is a good thing, because it allows you to infer how something works based on what you already know. If you can't infer it then you have to go read the docs. That's more work you have to do. There's clearly a trade-off between expressing a specific task as succinctly as possible and for our knowledge to be transferable between different tasks. It is the job of a programming language to guarantee a minimum level of transferability while allowing maximum expressivity. To do that, it has to put restrictions on how the semantics of syntax can be redefined. It's clearly an art to get that balance right. In my view, Swift hasn't got it right and is moving in the wrong direction.
drampelt 6y ago
I've been exploring Kotlin as a "rule them all" language. With Kotlin native/multiplatform you can already cover all platforms today since it can compile to JVM, JS, and native code for iOS/macOS. You still need to write the iOS/macOS UI in Swift but you can very easily have your data layer and business logic shared across platforms. I actually like that approach better than other cross-platform solutions since you keep the native platform UI.
- ralmidani 6y ago
  Very interesting, I will check it out! Is there a Kotlin-first server-side framework that you can recommend? (I use Java/Spring at work and it's OK, but would prefer to try something else for my side projects) Edit: if someone doesn't want JVM drama on their servers, how far can they get with Kotlin via LLVM?
  - drampelt 6y ago
    I've been using https://ktor.io https://ktor.io (by Jetbrains, same company behind Kotlin) but there are others like Micronaut and Quarkus. A few more options at: https://kotlinlang.org/lp/server-side/ https://kotlinlang.org/lp/server-side/ As far as I'm aware there's no native server side framework available at the moment, but ktor could potentially support it in the future given the ktor client libraries work on native. You could also use GraalVM native image to build a JVM-free binary of your server, Quarkus has built-in support for it.
dzonga 6y ago
I developed one or two server side apps using both Vapor & Kitura in late 2016 | 2017. the ecosystem though helpful isn't as vibrant as in other languages. if you care about shipping product i.e time to delivery vs language performance that matters a lot. machines are cheap, human labour and effort is not. with SwiftUI they're just bringing sanity around. otherwise screw apple for their closed ecosystem.
- ralmidani 6y ago
  I'm fairly new to Vapor, and not sure what the ecosystem was like 3-4 years ago, but it's possible it has matured a lot if the last time you checked it out was that long ago. I know Vapor's Fluent ORM has improved quite a bit recently, especially as it can take advantage of property wrappers introduced in Swift 5.1. It's not hard to imagine Fluent approaching feature parity with Rails' ActiveRecord and Django's ORM, but with much better performance and type-safety. FWIW, Kitura is probably dead in the water as IBM has stopped supporting it.
sedatk 6y ago
> and, to a lesser extent, .Net What's the problem with .NET, as it belongs to .NET Foundation now?
- ralmidani 6y ago
  https://en.wikipedia.org/wiki/.NET_Framework#Licensing https://en.wikipedia.org/wiki/.NET_Framework#Licensing The ecosystem looks like a hodgepodge of proprietary, MIT (accompanied by a potentially non-enforceable "patent promise"), and Apache. It's better than what Oracle is doing with Java, but Apple did the right thing and released Swift under Apache.
  - pjmlp 6y ago
    Like getting out every single new Java version since Java 6, adding AOT support (which Sun was completly against it was JIT or the highway), integrating GCs able to handle TB sized heaps in ms, adding value types and improving the generics story without doing Python 3 with 25 years old JARs, fibers, replacing JNI, bringing the metacircular JVM MaximeVM into production, long term roadmap to make Hotstop a mostly Java implementation, adding vector instructions in collaboration with Linaro and Intel,... Yeah, considering that only IBM did an acquisition offer that was quickly withdrawn, Oracle is being really nasty for Java, even Microsoft now contributes to OpenJDK.
    - ralmidani 6y ago
      None of my criticism is regarding how Oracle has been managing Java at a technical level. I thought that would be clear from the context, but I am strictly concerned with the increasingly dark patterns in the licensing model; I had Oracle's Java 8 on one of my computers, and it worked fine, but then a few months ago I got a notification that I needed to update to a newer version. After it was done updating, I was presented with an ultimatum: accept the new licensing terms (no commercial use without paying) or uninstall the software. I chose to uninstall, and vowed to never touch Java again when I personally have the discretion. Yes, I know I can install OpenJDK, but given Oracle's past and present behavior, how can anyone be assured they won't attempt to extinguish OpenJDK, even in the near future? Oracle seems to be boiling the frog slowly, and it probably won't be long before it becomes impractical to use non-proprietary Java anywhere. Edit: There was no warning that installing the latest "update" to Java would trigger an ultimatum screen, and no way to revert the installation. And as far as I know, there is now no way to download Java from Oracle without accepting the new license terms. It's pretty obvious what Oracle's endgame strategy is.
mmis1000 6y ago
I thought kotlin's aporoach about in language dsl shines here. You still need to read code from somewhere else to know whether it is a variable/field/extension or something. But at least you know it is a 'value', so you can access prop on it or something. You probably don't know the context of a lamba. But you will always at least know it is a lambda, and you can/need return value from it. Important basic information didn't lose under the sugar syntax. Compares to the groovy. That is literally a nightmare that I never find out what it is doing, am I calling a method or assign something to variable? I really don't know. And I end up gave up and copy build.gradle from someone else.

abjKT26nO8 6y ago

On the other hand, Swift changes so frequently that book authors teaching the language can't keep up with Apple to write up-to-date books. By the time a book comes out covering version N, we're a couple months away from version N+1. In this situation I can't trust I will be able to buy a book, learn the language and become comfortable with it before there is a new version with major changes. It's a very moving ground. As for performance, it would be cool if every single thing wasn't behind an atomic reference counter, making it slower than even garbage-collected Go: https://media.ccc.de/v/35c3-9670-safe_and_secure_drivers_in_high-level_languages https://media.ccc.de/v/35c3-9670-safe_and_secure_drivers_in_... (the relevant part starts at 33:06).

ralmidani 6y ago
Regarding language changes, I think this has improved quite a bit. I forget if stability was introduced in 4.x or 5.x, but code written today should be fine even when run through a new major version of the compiler. You can simply ignore new language features you aren't ready for until your codebase is due for a refactor. Regarding ARC, you don't have to use reference types in Swift, and the community seems to agree that structs are more suitable than classes for most use cases (a SwiftUI app is made of structs that conform to certain protocols, and those structs can be initialized, copied, and "modified" with little overhead). The cool thing about Swift is that structs can still have methods, computed properties, and custom initializers. So if you're coming from Python or Ruby or Java, or think OOP can help you organize your code, you don't have to throw away everything you've learned in order to be productive and write elegant code (and Swift brings a few new OOP tricks of its own).
- wool_gather 6y ago
  > I forget if stability was introduced in 4.x or 5.x, but code written today should be fine... They've always provided source compatibility modes in new releases of the compiler so you can delay making syntax changes to an existing codebase if you need to. You're thinking of ABI stability, which is in place as of Swift 5, and doesn't have anything to do with what parent is talking about.
  - saagarjha 6y ago
    For some time; at some point newer compilers will drop support for older versions.
raydev 6y ago
> Swift changes so frequently that book authors teaching the language can't keep up This hasn't been true for a couple years.

ksec 6y ago

>I remember reading somewhere that Chris Lattner said his goal with Swift was "Total World Domination" I think it was ATP Podcast https://atp.fm/205 https://atp.fm/205 But if you are listening to ATP most of the guest and host aren't really liking swift at all. And prefer to stick to Objective-C for as long as they could. In someway I could understand that, Swift all of a sudden has 10x increase in complexity compared to Objective-C.

zionic 6y ago
>And prefer to stick to Objective-C for as long as they could. I know these types, and they're extremely frustrating. Swift is superior to Objective-C in just about every way a modern programmer could want.
- saagarjha 6y ago
  > Swift is superior to Objective-C in just about every way a modern programmer could want. Reflection and dynamism are fairly big areas where Swift falls short. A couple more: interoperatibility with C++, any form of macro support, ability to shed the runtime where convenient…
- lenkite 6y ago
  Not in interop. Objective-C++ is how I write macOS apps. So does facebook AFAIK.
saagarjha 6y ago
Some of the members of that podcast write a fair amount of Swift. Actually, I think the majority of the hosts do, and the holdout is seriously considering doing so as well.

fauigerzigerk 6y ago

Swift started out as a pretty nice language, but in my opinion there are some major problems: The combination of ubiquitous closures and reference counting is dangerous. Avoiding circular references is not nearly as easy as you might think and reference counting is slow (low memory usage is an upside though). And lately, the language has become rather convoluted. They have added features that make Swift code hard to read. Function builders in particular are a terrible idea. I know many people like internal DSLs. I don't. I think it's a big mistake to overload the syntax of a language to such a degree that reading a piece of code in isolation tells you very little about what it does, because somewhere far away there may be a mode switch that completely changes the semantics of that piece of code. Consistency is more important than "looking clean" at all cost.

ralmidani 6y ago
I agree function builders have a lot of potential for abuse. But I prefer to take a "with great power comes great responsibility" approach over saying a feature should _never_ be allowed in a language. If I'm promoting a DSL that makes heavy use of something like function builders, I should provide robust documentation so other developers know what to expect. And those developers should, on the other hand, at least skim the docs in order to get a basic understanding of how the DSL works. If someone goes through the trouble of providing docs to accompany a DSL, and a downstream developer doesn't bother to read them, is that really the original developer's fault?
- fauigerzigerk 6y ago
  Consistency is a good thing, because it allows you to infer how something works based on what you already know. If you can't infer it then you have to go read the docs. That's more work you have to do. There's clearly a trade-off between expressing a specific task as succinctly as possible and for our knowledge to be transferable between different tasks. It is the job of a programming language to guarantee a minimum level of transferability while allowing maximum expressivity. To do that, it has to put restrictions on how the semantics of syntax can be redefined. It's clearly an art to get that balance right. In my view, Swift hasn't got it right and is moving in the wrong direction.

drampelt 6y ago

I've been exploring Kotlin as a "rule them all" language. With Kotlin native/multiplatform you can already cover all platforms today since it can compile to JVM, JS, and native code for iOS/macOS. You still need to write the iOS/macOS UI in Swift but you can very easily have your data layer and business logic shared across platforms. I actually like that approach better than other cross-platform solutions since you keep the native platform UI.

ralmidani 6y ago
Very interesting, I will check it out! Is there a Kotlin-first server-side framework that you can recommend? (I use Java/Spring at work and it's OK, but would prefer to try something else for my side projects) Edit: if someone doesn't want JVM drama on their servers, how far can they get with Kotlin via LLVM?
- drampelt 6y ago
  I've been using https://ktor.io https://ktor.io (by Jetbrains, same company behind Kotlin) but there are others like Micronaut and Quarkus. A few more options at: https://kotlinlang.org/lp/server-side/ https://kotlinlang.org/lp/server-side/ As far as I'm aware there's no native server side framework available at the moment, but ktor could potentially support it in the future given the ktor client libraries work on native. You could also use GraalVM native image to build a JVM-free binary of your server, Quarkus has built-in support for it.

dzonga 6y ago

I developed one or two server side apps using both Vapor & Kitura in late 2016 | 2017. the ecosystem though helpful isn't as vibrant as in other languages. if you care about shipping product i.e time to delivery vs language performance that matters a lot. machines are cheap, human labour and effort is not. with SwiftUI they're just bringing sanity around. otherwise screw apple for their closed ecosystem.

ralmidani 6y ago
I'm fairly new to Vapor, and not sure what the ecosystem was like 3-4 years ago, but it's possible it has matured a lot if the last time you checked it out was that long ago. I know Vapor's Fluent ORM has improved quite a bit recently, especially as it can take advantage of property wrappers introduced in Swift 5.1. It's not hard to imagine Fluent approaching feature parity with Rails' ActiveRecord and Django's ORM, but with much better performance and type-safety. FWIW, Kitura is probably dead in the water as IBM has stopped supporting it.

sedatk 6y ago

> and, to a lesser extent, .Net What's the problem with .NET, as it belongs to .NET Foundation now?

ralmidani 6y ago
https://en.wikipedia.org/wiki/.NET_Framework#Licensing https://en.wikipedia.org/wiki/.NET_Framework#Licensing The ecosystem looks like a hodgepodge of proprietary, MIT (accompanied by a potentially non-enforceable "patent promise"), and Apache. It's better than what Oracle is doing with Java, but Apple did the right thing and released Swift under Apache.
- pjmlp 6y ago
  Like getting out every single new Java version since Java 6, adding AOT support (which Sun was completly against it was JIT or the highway), integrating GCs able to handle TB sized heaps in ms, adding value types and improving the generics story without doing Python 3 with 25 years old JARs, fibers, replacing JNI, bringing the metacircular JVM MaximeVM into production, long term roadmap to make Hotstop a mostly Java implementation, adding vector instructions in collaboration with Linaro and Intel,... Yeah, considering that only IBM did an acquisition offer that was quickly withdrawn, Oracle is being really nasty for Java, even Microsoft now contributes to OpenJDK.
  - ralmidani 6y ago
    None of my criticism is regarding how Oracle has been managing Java at a technical level. I thought that would be clear from the context, but I am strictly concerned with the increasingly dark patterns in the licensing model; I had Oracle's Java 8 on one of my computers, and it worked fine, but then a few months ago I got a notification that I needed to update to a newer version. After it was done updating, I was presented with an ultimatum: accept the new licensing terms (no commercial use without paying) or uninstall the software. I chose to uninstall, and vowed to never touch Java again when I personally have the discretion. Yes, I know I can install OpenJDK, but given Oracle's past and present behavior, how can anyone be assured they won't attempt to extinguish OpenJDK, even in the near future? Oracle seems to be boiling the frog slowly, and it probably won't be long before it becomes impractical to use non-proprietary Java anywhere. Edit: There was no warning that installing the latest "update" to Java would trigger an ultimatum screen, and no way to revert the installation. And as far as I know, there is now no way to download Java from Oracle without accepting the new license terms. It's pretty obvious what Oracle's endgame strategy is.

mmis1000 6y ago

I thought kotlin's aporoach about in language dsl shines here. You still need to read code from somewhere else to know whether it is a variable/field/extension or something. But at least you know it is a 'value', so you can access prop on it or something. You probably don't know the context of a lamba. But you will always at least know it is a lambda, and you can/need return value from it. Important basic information didn't lose under the sugar syntax. Compares to the groovy. That is literally a nightmare that I never find out what it is doing, am I calling a method or assign something to variable? I really don't know. And I end up gave up and copy build.gradle from someone else.