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

181–190 of 239 posts

Re: Swift 6.3

#181

Post by PKop »

cdcarter wrote: post #166
sspiff wrote: post #163

Earlier quoted context omitted.

It's been a long time since I came across Nim. I thought it was really interesting about 12 years ago. What made you land on Nim instead of any of the more obvious alternatives?

I was looking for something that allows easy access to direct memory, with a syntax thats a little easier to explain than C. Frankly, zig was not actually a real viable option based on that syntax requirement but I still wanted to explore it. Nim really is clean and simple.

How about Odin?

Re: Swift 6.3

#183

Post by myHNAccount123 »

groundzeros2015 wrote: post #99
myHNAccount123 wrote: post #91

Earlier quoted context omitted.

> Apple barely maintains compatibility for their own platforms... You're commenting on a post about an update... that they apparently don't do? What?

Why are you interpreting this comment as "never receives updates"? It takes great effort to maintain API compatibility, some things aren't improved or are implicitly deprecated.

2/10

Re: Swift 6.3

#184

Post by pjmlp »

rasmus1610 wrote: post #16
dzonga wrote: 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…

Maybe Chris Lattner leaving and creating Mojo also didn’t help in that regard. Swift for TensorFlow was a cool idea in that time …

It remains to be seen how much Mojo has learnt from that effort.

NVidia, AMD and Intel now have doubled now into giving Python GPU JITs, and Julia, the same capabilities as their CUDA, ROCm, and SYSCL offerings with C++.

With Julia and Python having their 1.0 long behind them.

Re: Swift 6.3

#185

Post by pjmlp »

CharlieDigital wrote: post #128
hirvi74 wrote: post #115

Earlier quoted context omitted.

> Next big language addition will be discriminated unions and even that is really "opt-in" if you want to use it. I was excited for DU until I saw the most recent implementation reveal. https://github.com/dotnet/csharplang/blob/main/proposals/uni... Compared to the beauty of Swift: https://docs.swift.org/swift-book/documentation/the-swift-pr...

The C# impl is still early and I think what will end up happening is that a lot of the boilerplate will end up being owned by source generators in the long term. C# team has a habit of "make it work, make it better". Whatever v1 gets released is some base capability that v2+ will end up making more terse. I'm happy and OK with that; I'd rather have ugly unions than no unions (yes, I already use OneOf)

Ah Source Generators, after all these years still badly documented, when searching you most likely will find the original implemenation meanwhile deprecated, have poor tooling with string concatenation, and only have a few great blog posts from .NET MVPs to rely on.

Re: Swift 6.3

#186

Post by functional_dev »

cdcarter wrote: post #166
sspiff wrote: post #163

Earlier quoted context omitted.

It's been a long time since I came across Nim. I thought it was really interesting about 12 years ago. What made you land on Nim instead of any of the more obvious alternatives?

I was looking for something that allows easy access to direct memory, with a syntax thats a little easier to explain than C. Frankly, zig was not actually a real viable option based on that syntax requirement but I still wanted to explore it. Nim really is clean and simple.

yeah, Nim is great for that... much easier to explain to others than C or Zig especially for math code

Re: Swift 6.3

#187

Post by flykespice »

cdcarter wrote: post #166
sspiff wrote: post #163

Earlier quoted context omitted.

It's been a long time since I came across Nim. I thought it was really interesting about 12 years ago. What made you land on Nim instead of any of the more obvious alternatives?

I was looking for something that allows easy access to direct memory, with a syntax thats a little easier to explain than C. Frankly, zig was not actually a real viable option based on that syntax requirement but I still wanted to explore it. Nim really is clean and simple.

Yeah, for a language that claims to be a better modern alternative to C, zig verbose syntax is really an eyesore to look at compared the very same codebase written in C...

I lost immediately any interest on it

Re: Swift 6.3

#188

Post by w10-1 »

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 features (e.g., resources most recently), and they have been inching and hacking their way to a new swift-build engine (now experimental) and "prebuilt" modules for the compiler/IDE macro support. Things Go Wrong all the time when trying to replace parts while driving, and there's very little visibility or control over the interactions between SPM and Xcode.

Conversely to integrations, endogenous language progress seems relatively quiet because there's a lot of behind-the-scenes work extending the initial blush of lifetime controls to iterators, stdlib types, etc. (never mind parameter packs). They're in year 4+ of building out the function-coloring of concurrency and isolation domains (6.2 had an "easy" mode that caused lots of problems), so adding year 2+ dataflow coloring of lifetimes is doubly complicating.

Naturally, diverse support for exciting new features results in quite a spread in the third-party library ecosystem of support for various language features. And now with AI entrepreneurs rewriting and porting any project that can score hits and kudos, the usual open-source authorities are losing their steam.

Finally, there's the baseline platform complexity of multiple OS and devices, physical and simulator debugging support, cloud CI...

So: that makes four dimensions of complexity. As a Swift developer you'd have to be very careful to stay on a working path as things shift underneath you.

All for the love of it?

Re: Swift 6.3

#189

Post by seanw444 »

cdcarter wrote: post #166
sspiff wrote: post #163

Earlier quoted context omitted.

It's been a long time since I came across Nim. I thought it was really interesting about 12 years ago. What made you land on Nim instead of any of the more obvious alternatives?

I was looking for something that allows easy access to direct memory, with a syntax thats a little easier to explain than C. Frankly, zig was not actually a real viable option based on that syntax requirement but I still wanted to explore it. Nim really is clean and simple.

Nim is really incredible. The only things I cannot get over is the fact that it goes the inheritance route in a way I find to be hacky and fragile (no more than one level, really?) and traits are not a core feature. If Nim's primary approach was composition + Rust-style traits (that work at compiletime and runtime), I'd have a hard time wanting to use anything else.

Re: Swift 6.3

#190

Post by CharlieDigital »

pjmlp wrote: post #185
CharlieDigital wrote: post #128

Earlier quoted context omitted.

The C# impl is still early and I think what will end up happening is that a lot of the boilerplate will end up being owned by source generators in the long term. C# team has a habit of "make it work, make it better". Whatever v1 gets released is some base capability that v2+ will end up making more terse. I'm happy and OK with that; I'd rather have ugly unions than no unions (yes, I already use OneOf)

Ah Source Generators, after all these years still badly documented, when searching you most likely will find the original implemenation meanwhile deprecated, have poor tooling with string concatenation, and only have a few great blog posts from .NET MVPs to rely on.

:shrug: we're using them very effectively and there are plenty of resources at this point.

Very useful for reducing boilerplate and we can do some interesting things with it. One use case: we generate strongly typed "LLM command" classes from prompt strings.

Post reply on HN