Live data from Hacker News

Swift 6.3

swift.org

71–80 of 239 posts

Re: Swift 6.3

#71
post #51
post #31

Earlier quoted context omitted.

1. You don't have to use it all, but someone will. And there are over 200 keywords in the language: https://x.com/jacobtechtavern/status/1841251621004538183 2. On top of that many of the features in the language exist not because they were carefully designed, but because they were rushed: https://news.ycombinator.com/item?id=47529006

are there actually 217 keywords? Just wondering what the difference between that file and https://docs.swift.org/swift-book/documentation/the-swift-pr... (a mere 102 keywords)

That file is the compiler's list of reserved keywords, so some of them may not have been added to docs, or they're experimental/internal/...

I'm not 100% sure but I think the swift doc you linked is missing at least a dozen keywords so the truth probably lies in the middle

Re: Swift 6.3

#72

Earlier quoted context omitted.

That's my read too. Swift was feeling pretty exciting around ~v3. It was small and easy to learn, felt modern, and had solid interop with ObjC/C++. ...but then absolutely exploded in complexity. New features and syntax thrown in make it feel like C++. 10 ways of doing the same thing. I wish they'd kept the language simple and lean, and wrapped additional complexity as optional packages. It just feels like such a smal…

Which keywords would you get rid of and why? You don't have to use all of them!

i would get rid of associatedtype, borrowing, consuming, deinit, extension, fileprivate, init, inout, internal, nonisolated, open, operator, precedencegroup, protocol, rethrows, subscript, typealias, #available, #colorLiteral, #else, #elseif, #endif, #fileLiteral, #if, #imageLiteral, #keyPath, #selector, #sourceLocation, #unavailable, associativity, convenience, didSet, dynamic, indirect, infix, lazy, left, mutating, nonmutating, postfix, precedence, prefix, right, unowned, weak, and willSet

Re: Swift 6.3

#73

Earlier quoted context omitted.

It just works. One language. Many platforms. Incredible performance. With a simple tooling. No ugly script. Everything is naturally integrated.

Isn’t that Go?

Go and “simple tooling” don’t really belong in the same sentence. Powerful tooling, sure, but simple?

Re: Swift 6.3

#74
post #33
post #21

Earlier quoted context omitted.

I _can_ do the same with Rust, doesn't mean it's "the language I reach for" for making e.g. a website. Because the tooling, ergonomics, hireability factor, etc. are still very harshly against it. Same with Swift, but I'd call that more of a wasted opportunity because Apple, unlike Rust Foundation, has a mountain of money to make it happen, and yet they don't seem to care.

> They don't seem to care. I don’t believe that’s true. Things are moving constantly, and in the right direction. Then again it would help if you cited particular grievances, because being a regular (cross-platform/cross-target) Swift user I am not sure what you are talking about… I did not choose ClearSurgery’s example randomly. I was at a conference recently where the CTO was here, and he explicitly told us they we…

they seem to be adding more and more keywords

if they really want me to use this lang for everything, they'd have to 1. massively improve compilation speed, 2. get the ecosystem going (what's the correct way to spin up an http server like with express?) and 3. get rid of roughly 150 of the 200 keywords there are

especially w.r.t. the last one, of course everyone frets at huge breaking changes like this, so it won't happen, so people won't use it

Re: Swift 6.3

#75
post #12

Earlier quoted context omitted.

How so? I can indeed target every layer of the software stack using Swift, today . E.g. ClearSurgery[0] is written fully in Swift, including the real-time components running on the Linux boxes. [0] https://clearsurgery.vision

It just works. One language. Many platforms. Incredible performance. With a simple tooling. No ugly script. Everything is naturally integrated.

> No ugly script

What’s that supposed to mean?

Re: Swift 6.3

#76
post #2

> Swift 6.3 includes the first official release of the Swift SDK for Android.

Anything similar for Windows and Linux? For Windows there's a 5 year old blog post: https://www.swift.org/blog/swift-on-windows/ For Linux there's a guide for GNOME: https://www.swift.org/blog/adwaita-swift/ It would be really nice if instead we could just do one style of development and then ship a set of libraries as used to work for OpenSTEP (which was why it had "OPEN" in the name).

Swift on Windows has been part of the official distribution for a long time:

https://www.swift.org/install/windows/

Re: Swift 6.3

#77
post #2

> Swift 6.3 includes the first official release of the Swift SDK for Android.

That is going to be used... less than Swift for the servers

This is going to be used much more than Swift for servers. Swift is a primarily client-side mobile language. It makes sense that you tap into reusing the logic.

Re: Swift 6.3

#78

Earlier quoted context omitted.

That is going to be used... less than Swift for the servers

I don't know. Could be nice for those developers that prioritize iOS and now they could keep writing Swift also for Android. Is it gonna be what you primarily use if you wanna write an Android app? Probably not. Is it gonna displace react Native? Probably not. Is it gonna reach the levels of flutter? Maybe.

> Is it gonna reach the levels of flutter? Maybe.

Never. It won’t even reach Compose level, Flutter level DX is unattainable for any framework outside Flutter.

Re: Swift 6.3

#79
post #13

good to see incredible stuff being shipped in Swift. Haven't used it since v3 though. around 2015-17 - Swift could have easily dethroned Python. it was simple enough - very fast - could plug into the C/C++ ecosystem. Hence all the numeric stuff people were doing in Python powered by C++ libraries could've been done with Swift. the server ecosystem was starting to come to life, even supported by IBM. I think the letdo…

Python 3 barely managed to dethrone Python.

Re: Swift 6.3

#80
post #45

Earlier quoted context omitted.

Kotlin is practically a no-brainer when you have JVM at your finger tips, versus something like Swift which is comparatively young. I tried to use Vapor with Swift recently and struggled to get something working because the documentation looked comprehensive, but had a lot of gaps. I ended up throwing it out because I didn't have the time to dig through the source to understand how to do something, when I could use a…

Mind you, Kotlin/Native (which is what gets used when you're compiling for iOS) doesn't have access to the JVM. However, the Kotlin community is fundamentally all about open source, whereas Apple & iOS Devs have an allergy to it. The quality and quantity is already miles above the vast majority of what's in the Swift ecosystem. https://klibs.io has all the native compatible libs. And if you're targeting a platform wh…

JetBrains has monetary interest in promoting Kotlin beyond Android, there’s zero incentive to promote Swift as the language outside of iOS and Mac. They don’t need to capture minds of devs for them to develop for Apple devices.
Post reply on HN