Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift 6.3

swift.org

Post reply on HN
Print view View original

171–180 of 239 posts

Re: Swift 6.3

#171

Post by qn9n »

slopinthebag wrote: post #151

Swift truly is one of the languages of all time. I started a mobile app with the UI built in Swift and the core in Rust. The amount of implicit and hidden behaviour, magical fields being generated on objects because of certain annotations, the massive amount of @decorators...it's too much. I'm going to have an LLM generate the SwiftUI and touch as little of it as possible. It's also strange because before I learned S…

I find rust much noisier, especially at its basics where you write “for item in items” instead of using iter()

Re: Swift 6.3

#172

Post by rTX5CMRXIfFG »

mathverse wrote: post #119
isodev wrote: post #111

Earlier quoted context omitted.

> Swift has remained largely an Apple ecosystem Even today, with the fancy Swift 6.3, the experience of using Swift for anything other than apps for Apple platforms is very painful. There is also the question of trust - I don't think anyone would voluntarily introduce Apple "The Gatekeeper" in parts of their stack unless they're forced to do it.

You can use swift on the server but what for? You have a gigantic ecosystems in languages X,Y,Z. Even Apple does not use Swift on the server (AFAIK) so why would you?

That's outright false:

https://www.swift.org/blog/swift-at-apple-migrating-the-pass...

You could have easily fact-checked before forming an opinion, but at least the buffoon down there agreeing with you is worse

Re: Swift 6.3

#173

Post by vladde »

i worked with SwiftUI for about two years, and i think it's a really nice language. the compiler is very slow though.

but i think it's too coupled to Apple still. when i tried getting anything running on non-Apple, i had so much trouble i decided then to not even bother.

Re: Swift 6.3

#174

Post by pjmlp »

honr wrote: post #155
pjmlp wrote: post #134

Earlier quoted context omitted.

That is because Clojure is done, there is hardly anything being done other than probably what matters to NuBank and Datomic mostly. Also its market share adoption kind of shows it.

The current market share shows how far you can go with just being a better Java. If (or when? I haven't checked recently) a decent and well-thought-out LLVM backend emerges for it, ideally with some new underlying complexity seeping through, the market share might expand overnight. And as for C++, while some complexity is certainly unavoidable, a rigorous complexity control is desperately needed. Ideally, the same wa…

All good, except that going forward the new languages to be designed are going to be specifications and formal verification for agents.

I think the way of classical programming languages is behind us, unless AI implodes and we are back to programming without it.

Re: Swift 6.3

#175

Post by hbn »

zffr wrote: post #137
merlindru wrote: post #74

Earlier quoted context omitted.

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 h…

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

> these features are opt-in. If you don't want to use them, you don't have to.

Using a language is more than just writing it with a pre-established knowledge of what subset of features you think is worth the tradeoffs. More keywords/features means when you try to figure out how to do something new, there may be 15 different ways and you need to analyze and figure out which is the best one for this scenario, which ones are nonstarters, etc.

That's was more or less the whole design goal of Go. It was made by C++ programmers who were fed up with how many features were in the language, so they kept the feature set limited. Even the formatting is decided by the language. You may not agree with every decision, but what matters is decisions were made and they're standardized, so everyone is on the same page. You can read anyone else's code, and you know exactly what's going on.

Re: Swift 6.3

#177

Post by coldtea »

commandersaki wrote: post #153
coldtea wrote: post #142

Earlier quoted context omitted.

The same thing you'd do yoursef if you wanted to assign it to a namesake local variable even if it was in a dict to begin with: you'd make the dash an underscore.

It would be extremely unlikely that you would replicate the name as a local variable if it was in a dict, but regardless a dict doesn't have that limitation. The namespace thing is atrocious and bad design -- no straightforward way to iterate over them, merging/updating them is awful, collides with keyword methods (keys, items, etc.), and so on; thankfully more modern argument parsing libraries didn't repeat this mis…

>It would be extremely unlikely that you would replicate the name as a local variable if it was in a dict

If you had some feature flag args, you'd keep accessing them via the dict? Highly unlikely...

Re: Swift 6.3

#178

Post by slopinthebag »

qn9n wrote: post #171
slopinthebag wrote: post #151

Swift truly is one of the languages of all time. I started a mobile app with the UI built in Swift and the core in Rust. The amount of implicit and hidden behaviour, magical fields being generated on objects because of certain annotations, the massive amount of @decorators...it's too much. I'm going to have an LLM generate the SwiftUI and touch as little of it as possible. It's also strange because before I learned S…

I find rust much noisier, especially at its basics where you write “for item in items” instead of using iter()

Idk, I don't swift is objectively noisy but there is something about reading it that just hurts my brain. Stuff like

   ForEach(vm.sorted(by: \.name)) { user in
     row(for: user)
   }
\. looks like a syntax error to me, wtf. Also, "in" instead of -> ???

   .padding(.vertical, 4)
I also really dislike how you can leave off the type name, meaning you never actually know what that Type is unless you literally inspect the signature of the caller.

   func sorted(by keyPath: KeyPath) -> [User] {
      users.sorted { $0[keyPath: keyPath]
???

Yeah I fully accept it's just a me problem. But I hate it haha.

Re: Swift 6.3

#179

Post by nesarkvechnep »

cdcarter wrote: post #160

I spent last week (with Opus, of course) porting the xv6-riscv teaching operating system to a bunch of different languages. Zig, Nim, LISP, and Swift. The improvements in embedded Swift have definitely made it one of the most enjoyable/productive languages to work on the OS. I feel like I can build useful abstractions that wrap raw memory access and make the userland code feel very neat. On the other hand, the compil…

LISP like McCarthy LISP?

Re: Swift 6.3

#180

Post by vips7L »

rTX5CMRXIfFG wrote: post #172
mathverse wrote: post #119

Earlier quoted context omitted.

You can use swift on the server but what for? You have a gigantic ecosystems in languages X,Y,Z. Even Apple does not use Swift on the server (AFAIK) so why would you?

That's outright false: https://www.swift.org/blog/swift-at-apple-migrating-the-pass... You could have easily fact-checked before forming an opinion, but at least the buffoon down there agreeing with you is worse

Man you gotta touch some grass instead of just insulting people.
Post reply on HN