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

281–290 of 332 posts

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

#281

Post by [deleted] »

lenkite wrote: post #252
pbohun wrote: post #77

Earlier quoted context omitted.

People are correct I didn't explain my position. LLVM: Pretty much everyone who has created a programming language with it has complained about its design. gingerbill, Jon Blow, and Andrew Kelley have all complained about it. LLVM is a good idea, but it that idea was executed better by Ken Thompson with his C compiler for Plan 9, and then again with his Go compiler design. Ken decided to create his own "architecture…

Chris Lattner is definitely a genius engineer at innovation, implementation and delivery but long-term, robust, maintenable software-design doesn't appear to be in his capability set. The latter is definitely a defining capability of Anders Hejlsberg. (C#/Typescript designer)

[deleted]

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

#282

Post by roughly »

ulyssys wrote: post #169
roughly wrote: post #149

Earlier quoted context omitted.

> they probably want to cater to the average person, and not just security conscious tech savvy people Why? The average person is well served by large existing players, whereas security conscious tech people are extremely underserved and often actually willing to pay.

Specific numbers aside, one possible reason is they want to increase adoption to gain user volume, in order to have an effect on the larger ecosystem. Once you have non-trivial network effects, you could continue to influence the ecosystem (see: MSIE, Firefox in its early days, and Google Chrome). There are probably multiple paths to this. This is one.

Influence isn’t all about the raw numbers - if yours is the browser of choice for developers, that’s going to give you a stronger voice than just being the fourth best browser. Think about Twitter - by all accounts, Twitter’s user numbers were dwarfed by the other networks, but they punched way above their weight because the entire political policy making and reporting apparatus was on there.

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

#283

Post by bahmboo »

satvikpendem wrote: post #254
bahmboo wrote: post #233

Earlier quoted context omitted.

You can answer that question yourself.

You're right, looks like they don't, in fact, have millions of users.

Sick burn my man. Hope you check out Mojo lang vs arguing about rounding errors. I’m still unclear why I’m supposed to steer clear of Lattner which was what we were discussing.

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

#284

Post by jaen »

zephen wrote: post #268
librasteve wrote: post #257

Earlier quoted context omitted.

Well sure - being in a rut is good. But the language is the medium in which you cast your idiom, right? Here's a Python rut: n = 20 # how many numbers to generate a, b = 0, 1 for _ in range(n): print(a, end=" ") a, b = b, a + b print() Here's that rut in Raku: (0,1,*+*...*)[^20] I am claiming that this is a nicer rut.

seq = [0,1] while len(seq) > I am claiming that (0,1, + ...*)[^20] is a nicer rut. If it's so fantastic, then why on earth do you go out of your way to add extra lines and complexity to the Python?

Complexity-wise, this version is more complicated (mixing different styles and paradigms) and it's barely less tokens. Lines of code don't matter anyway, cognitive load does.

Even though I barely know Raku (but I do have experience with FP), it took way less time to intuitively grasp what the Raku was doing, vs. both the Python versions. If you're only used to imperative code, then yeah, maybe the Python looks more familiar, though then... how about riding some new bicycles for the mind.

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

#285

Post by fingerlocks »

mvdtnz wrote: post #216
fingerlocks wrote: post #206

Earlier quoted context omitted.

Nowhere does it say structs provide “one source of truth”. It says the opposite actually- that classes are to be used when unique instances are required. All classes have a unique ID, which is simply it’s virtual memory address. Structs by contrast get memcpy’d left and right and have no uniqueness. You can also look at the source code for the language if any it’s confusing. It’s very readable.

You're re-stating his exact problem while trying to refute him.

No, I’m not. OP is conflating multiple guidelines for different purposes and attempting to use them all simultaneously.

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

#286

Post by miffy900 »

fud101 wrote: post #202
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…

So did you go back to and keep using C#/NET?

well for backend development, yes - I technically never stopped as I had existing projects to maintain. But after trying out Swift a couple times, I've dropped it entirely for backend. For new backend work it's C#/.NET all the way.

I wanted to try using a native language other than C++ and Swift ostensibly seemed easier to pick up. I continue to use Swift for iOS app development though where it is much easier to use; but that has its own share of compromises and trade-offs - but not centred around Swift, around SwiftUI vs UIKit.

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

#287

Post by dismalaf »

levodelellis wrote: post #264
dismalaf wrote: post #197

Earlier quoted context omitted.

Avoiding interacting with LLVM as a user doesn't mean you've created something equivalent to LLVM. And if the C compiler you use is clang then you're still literally making use of LLVM.

I don't know what point you're trying to make but your question was what's an alternative to llvm. People writing compilers always used C89 or a version of it (C11 allows an easier atomic implementation). There's a lot more C89 compilers than backends that llvm supports. When I was writing arduino code clang/llvm couldn't generate the AVR code for the board. The default toolchain was gcc with an AVR backend. IIRC it…

> There's nothing wrong using C as your backend

I didn't say there was. Saying use C instead of LLVM is fine for a language designer.

But that doesn't make it a replacement for LLVM as a piece of infrastructure. C compilers still need an optimizing backend like LLVM.

The conversation is about whether or not LLVM is a shit piece of engineering, not whether you should target C or IR as a language designer. Avoiding using LLVM directly isn't a replacement lol.

You could say "GCC" is a replacement which at least isn't completely false, but GCC's backend is far more annoying to use for different languages.

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

#288

Post by three_burgers »

9rx wrote: post #170
zozbot234 wrote: post #61

Earlier quoted context omitted.

Rust has straightforward support for every part of OOP other than implementation inheritance, and even implementation inheritance can be rephrased elegantly as the generic typestate pattern. (The two are effectively one and the same; if anything, generic typestate is likely more general.)

> Rust has straightforward support for every part of OOP other than implementation inheritance Except the only thing that makes OOP OOP: Message passing. Granted, Swift only just barely supports it, and only for the sake of interop with Objective-C. Still, Swift has better OO support because of it. Rust doesn't even try. Not that OOP is much of a goal. There is likely good reason why Smalltalk, Objective-C, and Ruby…

I’m pretty sure when the Ladybird team said “Swift has strictly better OOP support”, they were not referring to ObjC style message passing, so it’s not even relevant.

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

#289

Post by 9rx »

three_burgers wrote: post #288
9rx wrote: post #170

Earlier quoted context omitted.

> Rust has straightforward support for every part of OOP other than implementation inheritance Except the only thing that makes OOP OOP: Message passing. Granted, Swift only just barely supports it, and only for the sake of interop with Objective-C. Still, Swift has better OO support because of it. Rust doesn't even try. Not that OOP is much of a goal. There is likely good reason why Smalltalk, Objective-C, and Ruby…

I’m pretty sure when the Ladybird team said “Swift has strictly better OOP support”, they were not referring to ObjC style message passing, so it’s not even relevant.

I'm pretty sure your guessing is silly. I assume you are trying to be here in good faith, so make your case. Since it is not support for message passing, what else makes Swift have "strictly better OOP support"?

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

#290

Post by archargelod »

mlinksva wrote: post #49
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.

https://x.com/awesomekling/status/1822236888188498031 https://x.com/awesomekling/status/1822239138038382684 "In the end it came down to Swift vs Rust, and Swift is strictly better in OO support and C++ interop."

Did they consider using Nim? It has great C++ interop, OO and same ARC memory management as in Swift.
Post reply on HN