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

201–210 of 239 posts

Re: Swift 6.3

#201

Post by jshier »

w10-1 wrote: post #188

Beyond the marketing view... here are the (incomplete) changes: https://github.com/swiftlang/swift/blob/main/CHANGELOG.md Here are the evolution proposals that landed in 6.3: https://www.swift.org/swift-evolution/#?search=6.3 Overall 6.3 ended up mostly about integration: stdlib, c/c++ (often driven by swift-java interop needs), and builds. SPM (swift package manager) is slowly reaching out to take over xcode build f…

Looks like swift-build will be the default in Swift 6.4: https://forums.swift.org/t/swiftpm-development-update-defaul...

Unfortunately, swift-build is what Xcode has been using for years now, and has major performance issues: https://forums.swift.org/t/target-dependency-graph-computati...

Perhaps using it in both SPM and Xcode will lead to improvements, but I'm not especially optimistic.

Re: Swift 6.3

#202

Post by jshier »

wwalexander wrote: post #23

Re: module name selectors, wasn't this already possible, e.g. ModuleA.getValue()? Though I suppose this disambiguates if you also have a type called ModuleA.

Yes, exactly. It also allows you to disambiguate overloaded function. e.g. thing.ModuleA::doThing() vs. thing.ModuleB::doThing(), which wasn't possible with the previous syntax.

Re: Swift 6.3

#203

Post by iLemming »

pjmlp wrote: post #134
embedding-shape wrote: post #132

Earlier quoted context omitted.

> Even if the languages started tiny, complexity eventually grows on them. And then of course the case that proves the opposite, Clojure. Sure, new ideas appear, but core language is more or less unchanged since introduced, rock solid and decades old projects still run just fine, although usually a bit faster.

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.

> That is because Clojure is done

First of all: Clojure is not "done". Latest commits were 3 months ago - https://github.com/clojure/clojure. Secondly, the language intentionally not 'all batteries-included' PL. The core is meant to be a stable, minimal substrate. Most action happens in libraries and tools - core.async, spec & malli, babashka, nbb, etc. Check the activity in Clojurians Slack. It's a small but unusually vibrant community, every single day there are news and announcements - updates, etc. It is done-ness in the good sense - like a well-designed tool that doesn't need to keep changing its handle.

> market share adoption kind of shows it

NuBank being the world's largest digital bank and running Clojure at scale is not "adoption"? Besides, there's Apple, Cisco, and tons of smaller companies running on it.

> there is hardly anything being done

They are making a documentary https://www.youtube.com/watch?v=JJEyffSdBsk Please don't say: "well, there are documentaries about dinosaurs" or something. I've been using Clojure for over ten years - in different teams, companies, industries. For my own projects and professionally. I've heard about it "dying" back then. I keep hearing about it dying every year and I promise you - nothing like that (even remotely) happening. Yes, the hype is gone (was it ever real?), but the language, community, library ecosystem, tooling - all of that only getting better.

There's no "killing" of Lisp. As long as programming languages remain relevant, there will always be some Lisp-dialect around. It probably never will become mainstream, yet it never completely disappears. There's no killing of Lisp, because it would be like killing "graph theory" or something. Graph theory doesn't need a Fortune 500 company funding it to remain true. Similarly, a small community keeping a Lisp dialect alive is all it takes - and there will always be people drawn to the clarity you get when you strip a language down to its lambda-calculus bones and see the whole thing fit in your head at once.

Rich Hickey has made this point himself - Clojure isn't trying to be the most popular language, it's trying to be correct about certain things. And correctness doesn't go out of fashion.

Re: Swift 6.3

#204

Post by iLemming »

pjmlp wrote: post #144
embedding-shape wrote: post #135

Earlier quoted context omitted.

> That is because Clojure is done Yes, that's one approach to avoiding ever growing complexity, maybe the other languages should try it sometime ;) With that said, everything around Clojure keeps improving and getting better. While the language doesn't have static types, clojure.spec offers something that is even better than static typing (imo), and doesn't even require any changes to the core language. Something els…

Is Typed.Clojure finally stable and sound? In theory we only need parentheses, prefix operators and a REPL, but mainstream never went down that route. Anyway the complexity then ends up being custom DSLs and macros.

> Is Typed.Clojure finally stable and sound?

It feels like as if you're operating with a few keywords you picked up without fully understanding the meaning of them. Typed Clojure was a PhD research project. Experimental. CircleCI experimented with it at one point but the friction was high enough that it never became a standard practice - the annotation burden was significant. You'd be writing a lot of type scaffolding for a language whose entire value proposition includes getting things done with less ceremony. Clojure's power comes heavily from its data orientation. Maps, sequences, heterogeneous data flowing through pipelines. Traditional type systems are deeply uncomfortable with that style. You end up either constraining how you write Clojure, or writing very complicated types to describe simple data flows. Types are there, Clojure does have types, and OMG, non-clojure coders have no idea how expressive they can be. There's just no static checking and that's for good reasons.

Does Typed Clojure solve complexity? - No, not really. Complexity is about incidental complexity from complecting things - and a type system doesn't untangle that (according to Rich Hickey). You can have beautifully typed spaghetti.

I'm not against static typing, and I have used languages with really nice type systems. But honestly, whenever this point pops on forums and people be like "meh, Clojure is not typed" - I immediately know - they probably have only shallow experience working with Clojure code.

Re: Swift 6.3

#205

Post by iLemming »

pjmlp wrote: post #143
zdragnar wrote: post #136

Earlier quoted context omitted.

That's a pretty far cry from "complexity is unavoidable". Reading that to me implies that the complexity is inherent in programming language design, whereas this follow-up argument seems to say that complexity is the result of tacking on new features. The latter is a bit tautological, since the size of the language grammar is itself a measure of complexity.

I think they even haven't adopted newer JVM features, it is a hosted language designed to depend on its host, plus it is a Lisp. The complexity would be to grow like Common Lisp, instead it is up to Clojure folks to write Java, C#, JavaScript code, therein lies the complexity.

> I think they even haven't adopted newer JVM features

You don't know what you're talking about. Not only Clojure steadily adopting newer JVM features (for when that makes sense) - java streams, functional interfaces, qualified method values, interactive lib loading, JDK21 virtual threads, etc., Clojure constantly explores beyond the JVM - e.g., Jank targets LLVM and has C++ interop.

Pick some hardcore JVM topics and try searching what Clojurists think about them - GC, profiling, concurrency, etc. There's tons of interesting, deeply involved things constantly being hacked together by incredibly knowledgeable folks. You're casually name-dropping "complexity" maybe without even realizing that it's a community that includes people who have written production experience reports on Shenandoah GC, built profiling tools that work around safepoint bias, and given conference talks on tri-color marking algorithms. Dealing with complexity is their bread-n-butter. Challenging Clojurists to debate about "complexity" is like dropping "the brain has neurons" around a group of neurosurgeons. They'd quietly say nothing, so you can "win your argumentation", but they'll just... know.

Re: Swift 6.3

#206

Post by willtemperley »

marcprux wrote: post #161
willtemperley wrote: post #18

Earlier quoted context omitted.

There are still challenges with basics like compression, which tends to involve trawling Github for the least dubious toy project. Even Apple's Compression framework is missing important algorithms like ZSTD. Another problem is the Apache Software Foundation don't seem to have any Swift maintainers, which means there really aren't any good pure Swift libraries for Arrow or Parquet. There are some really good open-sou…

> There are still challenges with basics like compression FWIW, there is an active discussion on this very topic: https://forums.swift.org/t/proposal-compression-library/8541...

That’s really useful information, thanks.

Re: Swift 6.3

#207

Post by cosmic_cheese »

iamcalledrob wrote: post #139
cosmic_cheese wrote: post #109

Earlier quoted context omitted.

The absence of guard in Kotlin is one of those things that regularly trips me up when bouncing between it and Swift. Rather than Swift losing guard I’d prefer if Kotlin gained it.

I think the ?: operator ends up being a decent alternative, e.g. // Swift guard let foo = maybeFoo else { print("missing foo") return false } // Kotlin val foo = maybeFoo ?: run { print("missing foo") return false } Unless there's a use case for guard I'm not thinking of

It’s a decent alternative, but to someone not familiar with the language what’s going on isn’t as clear.

Re: Swift 6.3

#208

Post by rudedogg »

willtemperley wrote: post #22
iamcalledrob wrote: post #19

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!

> You don't have to use all of them!

You sure pay for the language complexity in high compile times though. Swift is slow, like really slow. I’ve been with it since like v1.2, and its been getting progressively worse for a while IMO. Complex language features (Lets do a borrow checker! Lets do embedded!) and half of the shit isn’t being used internally as far as I can tell

Re: Swift 6.3

#209

Post by jshier »

qn9n wrote: post #169
lijunle wrote: post #140

How is the toolchain? Does Swift Lint and Swift Format support the newest version. Honestly, the modern program language should have the built-in formatter and recommend lint rules. It is not just shipping a program language, it is a while ecosystem.

Both are apart of the toolchain now, no external dependencies required: `swift format` and `swift format lint` to access them

SwiftLint and SwiftFormat are different tools than swift-format, which is what is included with Swift itself. swift-format is less capable than either, or similar tools from other ecosystems. Personally I use the other two. And they don't usually require updates for new language versions, and when they do, they update quickly, as they aren't part of the Swift toolchain and subject to its glacial release process.

Re: Swift 6.3

#210

Post by hirvi74 »

hu3 wrote: post #52
frizlab wrote: post #34

Earlier quoted context omitted.

That was true for Swift 2, maybe a little for Swift 3, but it has not been true since a long time now…

If cross platform support took so long, it's a major red flag. Plus Swift is arguably too unnecessarily complex now. And there's Rust/Zig so why use Swift for low level?

> Plus Swift is arguably too unnecessarily complex now.

I would argue the allegations of complexity against Swift are greatly exaggerated. I find the language to be very elegant and expressive in syntax, high in readability, and fairly terse. Other than that, Swift feels near identical to every other OoP language I have used.

Post reply on HN