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

Closing this as we are no longer pursuing Swift adoption

github.com

Post reply on HN
Print view View original

221–230 of 332 posts

Re: Closing this as we are no longer pursuing Swift adoption

#221

Post by sumuyuda »

VerifiedReports wrote: post #180
miffy900 wrote: post #161

As someone who first began using Swift in 2021, after almost 10 years in C#/.NET land, I was already a bit grumpy at how complex C# was, (C# was 21 years at that point), but then coming to Swift, I couldn't believe how complex Swift was compared to C# - Swift was released in 2014, so would've been 8 years old in 2022. How is a language less than half the age of C# MORE complex than C#? And this was me trying to use S…

I started using it around 2018. After being reasonably conversant in Objective-C, I fully adopted Swift for a new iOS app and thought it was a big improvement. But there's a lot of hokey, amateurish stuff in there... with more added all the time. Let's start with the arbitrary "structs are passed by value, classes by reference." And along with that: "Prefer structs over classes." But then: "Have one source of truth."…

> when every data structure is COPIED on every function call

Swift structs use copy on write, so they aren’t actually copied on every function call.

Re: Closing this as we are no longer pursuing Swift adoption

#223

Post by ifwinterco »

saagarjha wrote: post #219
gethly wrote: post #213

[flagged]

Bringing up Rust as an obvious alternative is not toxic.

There's already a stereotype that Rust people will just carpet bomb any discussion with aggressively promoting Rust, people expect it to happen at this point and it just annoys people.

So I think it probably meets the threshold of "toxic", but more importantly - it's not effective. Everyone and their dog has already heard of Rust, aggressive proselytising is not going to help drive Rust adoption, it's just pissing people off

Re: Closing this as we are no longer pursuing Swift adoption

#224

Post by librasteve »

miffy900 wrote: post #161

As someone who first began using Swift in 2021, after almost 10 years in C#/.NET land, I was already a bit grumpy at how complex C# was, (C# was 21 years at that point), but then coming to Swift, I couldn't believe how complex Swift was compared to C# - Swift was released in 2014, so would've been 8 years old in 2022. How is a language less than half the age of C# MORE complex than C#? And this was me trying to use S…

In the last years, simplistic languages such as Python and Go have “made the case” that complexity is bad, period. But when humans communicate expertly in English (Shakespeare, JK Rowling, etc) they use its vast wealth of nuance, shading and subtlety to create a better product. Sure you have to learn all the corners to have full command of the language, to wield all that expressive power (and newcomers to English are limited to the shallow end of the pool). But writing and reading are asymmetrical and a more expressive language used well can expose the code patterns and algorithms in a way that is easier for multiple maintainers to read and comprehend. We need to match the impedance of the tool to the problem. [I paraphrase Larry Wall, inventor of the gloriously expressive https://raku.org]

Re: Closing this as we are no longer pursuing Swift adoption

#225

Post by palata »

gmueckl wrote: post #151
palata wrote: post #60

Earlier quoted context omitted.

I actually looked into that recently (calling C++ from Swift), and I was surprised by the amount of limitations. Said differently: the C++ interop did not support calling the C++ library I wanted to use, so I wrote a C wrapper.

Binding to C++ is an extremely difficult and complex problem for any language that is similarly rich and has lots of (seemingly) equivalent features. The number of subtle incompatibilities and edge cases becomes nearly endless. It's not surprising that some C++ code can't be bound properly.

Yeah, that's what I realised. But I just wanted to mention that this is not what I was expecting from "excellent" interop. I would say that C has excellent interop, in general.

Re: Closing this as we are no longer pursuing Swift adoption

#226

Post by palata »

zadikian wrote: post #157
palata wrote: post #60

Earlier quoted context omitted.

I actually looked into that recently (calling C++ from Swift), and I was surprised by the amount of limitations. Said differently: the C++ interop did not support calling the C++ library I wanted to use, so I wrote a C wrapper.

I did this a long time ago as Swift calling Objective-C++ which can call C++ libs, in that case OpenCV. So it wasn't awful but did require making an ObjC++ wrapper, unless I did something wrong which is also possible.

Yes that makes sense. I would just rather make a C wrapper than an ObjC++ one, because then that C wrapper can be used with many other languages.

Re: Closing this as we are no longer pursuing Swift adoption

#227

Post by Epskampie »

sumuyuda wrote: post #221
VerifiedReports wrote: post #180

Earlier quoted context omitted.

I started using it around 2018. After being reasonably conversant in Objective-C, I fully adopted Swift for a new iOS app and thought it was a big improvement. But there's a lot of hokey, amateurish stuff in there... with more added all the time. Let's start with the arbitrary "structs are passed by value, classes by reference." And along with that: "Prefer structs over classes." But then: "Have one source of truth."…

> when every data structure is COPIED on every function call Swift structs use copy on write, so they aren’t actually copied on every function call.

They are, as far as "Have one source of truth" is concerned. That is what parent is talking about.

Re: Closing this as we are no longer pursuing Swift adoption

#229

Post by alper »

ChrisMarshallNY wrote: post #211
VerifiedReports wrote: post #180

Earlier quoted context omitted.

I started using it around 2018. After being reasonably conversant in Objective-C, I fully adopted Swift for a new iOS app and thought it was a big improvement. But there's a lot of hokey, amateurish stuff in there... with more added all the time. Let's start with the arbitrary "structs are passed by value, classes by reference." And along with that: "Prefer structs over classes." But then: "Have one source of truth."…

I think Swift was developed to keep a number of constituencies happy. You can do classic OOP, FP, Protocol-Oriented Programming, etc., or mix them all (like I do). A lot of purists get salty that it doesn’t force implementation of their choice, but I’m actually fine with it. I tend to have a “chimeric” approach, so it suits me. Been using it since 2014 (the day it was announced). I enjoy it.

No Swift was developed as a strategic moat around Apple's devices. They cannot be dependent on any other party for the main language that runs on their hardware. Controlling your own destiny full stack means having your own language.

Re: Closing this as we are no longer pursuing Swift adoption

#230

Post by alper »

gardaani wrote: post #209
meisel wrote: post #46

Why did Ladybird even attempt this with Swift, but (I presume) not with Rust? If they're going to go to the trouble of adding another language, does Rust not have a better history of C++ interop? Not to mention, Swift's GC doesn't seem great for the browser's performance.

Here's Andreas Kling's general thoughts on Rust: - Excellent for short-lived programs that transform input A to output B - Clunky for long-lived programs that maintain large complex object graphs - Really impressive ecosystem - Toxic community https://x.com/awesomekling/status/1822241531501162806

I think that's fair. Funny to have a language that makes it prohibitively difficult to use most of the core computer science constructs (lists, graphs etc.).
Post reply on HN