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

101–110 of 239 posts

Re: Swift 6.3

#101

Post by afavour »

fainpul wrote: post #100
afavour wrote: post #98

Earlier quoted context omitted.

Eh, I don't think Swift would ever have dethroned Python. What pain point would it practically solve? I don't use Python often but I don't hear folks complaining about it much. I do, though, think Swift had/has(?) a chance to dethrone Rust in the non-garbage collected space. Rust is incredibly powerful but sometimes you don't really need that complexity, you just need something that can compile cross-platform and mai…

> just need something that can compile cross-platform and maintain great performance. I think Go has already taken that part of the cake.

Go is garbage collected, though. Rust and Swift still occupy a niche Go doesn't.

Re: Swift 6.3

#102

Post by commandersaki »

coldtea wrote: post #89
commandersaki wrote: post #42

Earlier quoted context omitted.

Plus Swift goes directly against the Zen of Python The Zen of Python is how we got crap like argparse where arguments are placed in the namespace instead of a dict.

I wouldn't change that in any way. I'd might make it an Arguments class, but I wound't make what parser returns merely a dict.

Yeah, so what happens when you have an option with a '-' in it that isn't valid as a variable name (I know what happens). It's just stupid.

Re: Swift 6.3

#103

Post by willtemperley »

cloogshicer wrote: post #32
willtemperley wrote: post #22

Earlier quoted context omitted.

Which keywords would you get rid of and why? You don't have to use all of them!

But you have to know all of them to read other people's code. To answer your question: I would immediately get rid of guard . Also, I think the complexity and interplay of structs, classes, enums, protocols and now actors is staggering.

I'm surprised, guard is really useful, especially when unwrapping optionals. It's terse, explicit and encourages defensive programming.

internal should definitely go though.

Re: Swift 6.3

#104

Post by WillAdams »

migueldeicaza wrote: post #76
WillAdams wrote: post #24

Earlier quoted context omitted.

Anything similar for Windows and Linux? For Windows there's a 5 year old blog post: https://www.swift.org/blog/swift-on-windows/ For Linux there's a guide for GNOME: https://www.swift.org/blog/adwaita-swift/ It would be really nice if instead we could just do one style of development and then ship a set of libraries as used to work for OpenSTEP (which was why it had "OPEN" in the name).

Swift on Windows has been part of the official distribution for a long time: https://www.swift.org/install/windows/

The blog posts seems to place higher on search results --- maybe arrange to have it edited?

Which GUI toolkit(s) does that install support?

Re: Swift 6.3

#105

Post by dagmx »

sirwhinesalot wrote: post #8

> Swift 6.3 introduces the @c attribute, which lets you expose Swift functions and enums to C code in your project. Annotating a function or enum with @c prompts Swift to include a corresponding declaration in the generated C header that you can include in your C/C++ files Why did this take so long to be added? Such strange priorities. Adding an entire C++ compiler for C++ interoperability before adding... C exports.…

You already had ObjC export so it was arguably low priority given the crossover

Re: Swift 6.3

#106

Post by ramesh31 »

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…

>"around 2015-17 - Swift could have easily dethroned Python."

NumPy, SciPy, Pandas, and Pytorch are what drove the mass adoption of Python over the last few years. No language feature could touch those libraries. I now know how the C++/Java people felt when JS started taking over. It's a nightmare to watch a joke language (literally; Python being named for Monty Python) become the default simply because of platform limitations.

Re: Swift 6.3

#107

Post by fingerlocks »

fauigerzigerk wrote: post #53
willtemperley wrote: post #22

Earlier quoted context omitted.

Which keywords would you get rid of and why? You don't have to use all of them!

I would remove result builders and all other uses of @attributes that change the semantics of the code (e.g property wrappers). I would remove the distinction between value types and reference types at the type level. This has caused so many bugs in my code. This distinction should be made where the types are used not where they are defined. I would remove everything related to concurrency from the language itself. T…

I agree with you about result builders, silly feature that only exists for SwiftUI.

But a lot of what you said, except for the concurrency and property wrapper stuff, largely exists for Obj-C interop. The generated interface is more readable, and swift structs act like const C structs. It’s nice.

Re: Swift 6.3

#108

Post by fassssst »

WillAdams wrote: post #104
migueldeicaza wrote: post #76

Earlier quoted context omitted.

Swift on Windows has been part of the official distribution for a long time: https://www.swift.org/install/windows/

The blog posts seems to place higher on search results --- maybe arrange to have it edited? Which GUI toolkit(s) does that install support?

None, you’re on your own. The Browser Company made bindings for WinRT so you can use WinUI imperatively but it’s non trivial to set up.

Re: Swift 6.3

#109

Post by cosmic_cheese »

willtemperley wrote: post #103
cloogshicer wrote: post #32

Earlier quoted context omitted.

But you have to know all of them to read other people's code. To answer your question: I would immediately get rid of guard . Also, I think the complexity and interplay of structs, classes, enums, protocols and now actors is staggering.

I'm surprised, guard is really useful, especially when unwrapping optionals. It's terse, explicit and encourages defensive programming. internal should definitely go though.

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.

Re: Swift 6.3

#110

Post by hirvi74 »

troupo wrote: post #29
rasmus1610 wrote: post #16

Earlier quoted context omitted.

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

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…

To be fair, I think such a fate in inevitable for most languages after many years of changes and development.
Post reply on HN