Hacker News Reader

Comment by keyle | Hacker News Reader

At some point I might have somewhat agreed with you but not so much lately.

I've been using a lot of swift lately and it's one of the most expressive (and impressive) language of late.

I've been blown away by its terseness which leads to incredible functionality (SwiftUI is basically a DSL[1]) and robustness of the type system.

When it compiles, it will most likely not crash, unless I specifically said "doing!yolo-dumb!stuff!here".

I'll come out and say it, Swift might be the most advanced high-level language in terms of power vs. UX.

I'll also say that its compile messages, half the time, are like academia vomit thrown at the face of the developer -> that needs to improve.

[1] (which agreeably leaks a bit)

View on HN

The big problem with Swift for DSLs is that SwiftUI is essentially a special case in the language. Yes, you can build other DSLs with the facilities, but result builders are designed for SwiftUI’s needs specifically, where a more general hygenic-macro-based solution would be of more value generally. (Swift does not have macros of any sort).

The main issue with Swift as a general language is that the standard library is not broadly enough designed, and the language is very tied to the standard library. It’s hard to see Swift being used to write an OS kernel, or even a Linux kernel module, for example. Swift is an application language for Apple platforms, and it will remain so until someone puts effort into making it otherwise.

That said, the new regex facilities in Swift 6 make it a real contender for scripting tasks where you might otherwise consider using Ruby / Perl / Python. So there is progress.

FWIW, https://forums.swift.org/t/a-possible-vision-for-macros-in-s...

I'm surprised to hear you call it "terse," in trying to learn Swift I've found it painfully verbose for the most part (function calls with required keyword arguments by default, function definitions with external and internal names, overriding final fileprivate etc), and only the odd syntax around (esp trailing) closures weirdly terse and, for me, difficult to get used to.

Hopefully I'll get used to it. It does seem like all this serves a purpose, perhaps more readable as a result, but it seems to take more writing than I'm used to in python / go / rust.

It doesn't matter how good the language itself already is.

It's a niche language because the marketing of it to non-Apple-platform developers over the years has totally bombed, and it has close to zero mindshare amongst them.

(People who were already Apple-platform developers playing around with hosting a webapp on a Linux box don't count)

I agree, it's a beautifully expressive and safe language. Being tied so closely to iOS, thus limiting its impact for eg backend work, really is a pity. I know you technically can use it for backend work but the ecosystem just isn't there, I think people just consider it ios-only unfortunately. To workaround the small ecosystem, you can bridge to existing C libraries but the impedance mismatch makes it very difficult (eg UnsafeMutableBufferPointer<T>).

I do worry about its future however: dual-native mobile apps are less and less popular with product owners with every passing year, the market seems to be moving to flutter. Which is a pity! It's such a great language.

Just wait, Google will abandon flutter and everyone who built their apps on top of it will be hosed.

Honestly that's a very real concern. From what I hear, the Android team does not speak glowingly of the Flutter team at IO. Also there appears to be a power struggle between the Flutter and Jetpack Compose teams to become the next 'official' way of developing Android apps, in parallel to Apple bringing out SwiftUI. Time will tell.

Given what we've all been reading lately about Google's LPA cycle (launch, get promoted, abandon) it seems likely that flutter will end up like React Native: kinda usable, but never really polished enough, it seems they just stopped most work on it before the finish line.

I am worried about its terseness and readability.

Also agree. That's what I meant about the leaky abstraction. The fact that some chainable things are a one way street... e.g. need a specific order... yikes.

But considering the DSL is fully statically typed, wow.

So it's a bit of give and take on that one.

Out of many sources, it was only the Stanford iphone course that demystified the terseness of the Swiftui dsl. The lecturer pointed out all the optional parentheses and optional arguments that could be omitted to make the declarations clean. Up until then i thought i was looking at weird structs. This is one problem i have with swift’s terseness.

I think one gets used to this as a convention / style over time. It does necessitate good contextual autocomplete, though.

Completely agree. And it still hurts my brain.

Amusingly, using other languages now, I'm finding I'm missing the implied nature of Swift at times.

Reply on news.ycombinator.com