Live data from Hacker News

Swift 6.3

swift.org

231–239 of 239 posts

Re: Swift 6.3

#231
post #137

Earlier quoted context omitted.

> 3. get rid of roughly 150 of the 200 keywords there are I don't understand this point. Could you explain? The new keywords enable new language features (ex: async/await, any, actor), and these features are opt-in. If you don't want to use them, you don't have to. What are they keywords you think should be removed?

besides it being almost impossible to understand what "the right way of doing stuff" is with Swift (or any bloated language), i absolutely _do_ have to use the keywords. reading someone else's code is part of working with the language (as is understanding LLM output nowadays). i can't just make others not use the keywords i don't know/beed/like. especially if working within teams, or using OSS.

Fair point, I had not considered needing to read and understand code you didn't write yourself.

Especially in a corporate setting, not understanding a keyword you see in a PR could lead to bad code being checked in.

Re: Swift 6.3

#232

Earlier quoted context omitted.

Not just uber slow to compile, because as a Rust dev I could take that. But it rejects correct programs without telling you why! The compiler will just time out and ask you to refactor so it has a better shot. I understand that kind of pathological behavior is present in many compilers but I hit it way too often in Swift on seemingly benign code.

Did that happen recently (the compiler just bailing out)? Because they got much better at that, and it’s been a long while since that happened to me. Like “I don’t even remember when was the last time it happened” long.

The last time I used Swift was 4 months ago. It was recent enough that I'm still salty about it! :P

Re: Swift 6.3

#233
post #29

Earlier quoted context omitted.

Lattner probably left because Apple didn't give the team any breathing room to properly implement the language. It was "we must have this feature yesterday". A lot of Swift is the equivalent of Javascrip's "we have 10 days to implement and ship it": https://youtu.be/ovYbgbrQ-v8?si=tAko6n88PmpWrzvO&t=1400 --- start quote --- Swift has turned into a gigantic super complicated bag of special cases, special syntax, speci…

> Swift has turned into a gigantic super complicated bag of special cases, special syntax, special stuff... That's true, but only partly true. It already was a gigantic super complicated bag of special cases right from the start. Rob Rix noted the following 10 years ago: Swift is a crescendo of special cases stopping just short of the general; the result is complexity in the semantics, complexity in the behaviour (i.…

That is why I wish Apple to abandon Swift and continue to use Objective-C instead.

Also a reason why Craig needs to go.

Re: Swift 6.3

#234
post #233

Earlier quoted context omitted.

> Swift has turned into a gigantic super complicated bag of special cases, special syntax, special stuff... That's true, but only partly true. It already was a gigantic super complicated bag of special cases right from the start. Rob Rix noted the following 10 years ago: Swift is a crescendo of special cases stopping just short of the general; the result is complexity in the semantics, complexity in the behaviour (i.…

That is why I wish Apple to abandon Swift and continue to use Objective-C instead. Also a reason why Craig needs to go.

Apple cannot admit they did wrong. That's like hardcoded in their DNA.

Re: Swift 6.3

#235
post #233

Earlier quoted context omitted.

That is why I wish Apple to abandon Swift and continue to use Objective-C instead. Also a reason why Craig needs to go.

Apple cannot admit they did wrong. That's like hardcoded in their DNA.

But they can silently drop their mistakes without ever mentioning them again, for example Garbage Collection, Modern Objective-C Syntax, Cocoa-Java.

While they will do this and just start treating the old thing as if it were brand new and shiny, it helps if they actually do have some new shiny thing.

Happy to rebrand Objective-Smalltalk into AppleTalk. The network protocol was dropped 15 years ago, so that could work.

Re: Swift 6.3

#236

Earlier quoted context omitted.

Apple cannot admit they did wrong. That's like hardcoded in their DNA.

But they can silently drop their mistakes without ever mentioning them again, for example Garbage Collection, Modern Objective-C Syntax, Cocoa-Java. While they will do this and just start treating the old thing as if it were brand new and shiny, it helps if they actually do have some new shiny thing. Happy to rebrand Objective-Smalltalk into AppleTalk. The network protocol was dropped 15 years ago, so that could work…

AppleTalk Ultra

Re: Swift 6.3

#237
post #126
post #73

Earlier quoted context omitted.

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

Would be helpful if you elaborate which part is not simple. Coming from C++ and JavaScript, there aren't many languages that can claim to have "simpler" tooling than Go.

Things that are not simple about go tooling

- Comments as directives[0]. Nobody finds this intuitive. I've never met anyone that saw what directives were doing and thought to change a comment. - Comments as commands for the compiler[1] - The state of go linting[2]. There are 30 different formatting tools that all frequently conflict with each other. It got so complicated that one project exists to manage installations of all the other ones (golangci-lint). Only difficulty is that most IDEs use gofmt and if your golangci-lint uses a different gofmt version than your IDE, you end up getting different formatting when you save vs. when you commit. This is only a problem because golangci-lint can't be installed using the go toolchain[3], so you can't just have dependency resolution solve this for you.

I can go on

[0] - https://groups.google.com/g/golang-dev/c/r4rdPdsH1Fg/m/yjOOz... [1] - https://essentials-of-go-programming.readthedocs.io/tooling.... [2] - https://go.dev/wiki/CodeTools [3] - https://github.com/golangci/golangci-lint/issues/1657

Re: Swift 6.3

#238
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's interactive interpreter makes it pretty useful as a shell, for iterative development, and crucially useful in a Jupyter notebook. I've also found CircuitPython's interpreter to be bonkers useful in prototyping embedded projects. (This, on top of the nice datascience, ML, and NN libraries). Swift just wasn't doing the same things. And even if it did, Swift would compete with other languages that were understo…

> Swift just wasn't doing the same things.

Swift has had an interactive interpreter from v1. Even scripting in Swift was supported from the start.

What it really needed back then was ergonomic APIs for this kind of programming.

Why would anyone in 2014 adopt Swift as a quick prototyping/scripting language when you can just do os.path.join() in Python (Swift's path APIs have always defaulted to the NextStep–era stuff), or subprocess.run() (Swift still defaults to NSProcess).

Today, the picture is different; swift-subprocess and swift-system have improved things greatly.

Re: Swift 6.3

#239

Earlier quoted context omitted.

But they can silently drop their mistakes without ever mentioning them again, for example Garbage Collection, Modern Objective-C Syntax, Cocoa-Java. While they will do this and just start treating the old thing as if it were brand new and shiny, it helps if they actually do have some new shiny thing. Happy to rebrand Objective-Smalltalk into AppleTalk. The network protocol was dropped 15 years ago, so that could work…

AppleTalk Ultra

SwiftTalk
Post reply on HN