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

291–300 of 332 posts

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

#291

Post by satvikpendem »

bahmboo wrote: post #283
satvikpendem wrote: post #254

Earlier quoted context omitted.

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.

Not sure what you're even talking about. You said something I was curious about since I thought you knew something about it I didn't but then you told me to look it up myself, for some reason, and I did. I don't know how you construed that as a "sick burn" or that you're "supposed to steer clear of Lattner," both of which I never said or implied.

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

#292

Post by zadikian »

antonvs wrote: post #269
zadikian wrote: post #265

Earlier quoted context omitted.

You can do OO this way if you really want in Rust, kinda like how you can do it in C, but it gets cumbersome. Especially because there's no GC.

But it's not "kinda how you can do it in C". Traits are a core feature of Rust, any non-trivial Rust program uses them. Traits alone give you polymorphism across disparate types, exactly as in OO - actually better than standard OO (without interfaces), because trait polymorphism works without requiring inheritance from a common ancestor. > Especially because there's no GC. This is the only real issue I can think of.…

I know the Rust trait system has an answer to every OO concept. Another is that data field inheritance is replaced by composition. But these are more workarounds for the rarer cases you want to do OO in Rust, not the intended usual path, and doing OOP this way will get tedious. Otherwise, there'd be no difference and everyone would call Rust an OO language.

Not so sure about not needing GC. Many times a problem seems easy without GC until you get into the weeds. Like why did ObjC feel the need to add ARC (not GC but similar goal)?

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

#293

Post by f33d5173 »

refulgentis wrote: post #55
mlinksva wrote: post #49

Earlier quoted context omitted.

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."

> Swift is strictly better in OO support and C++ interop Fascinating. They've shown the idea it is better on C++ interop is wrong. I don't know enough to say Rust has same OO support as Swift, but I'm pretty sure it does. (my guess as a former Swift dev: "protocol oriented programming" was a buzzy thing that would have sounded novel, but amounted to "use traits" in rust parlance) EDIT: Happy to hear a reply re: why d…

They demonstrated that swift's c++ interop isn't good enough, but does it follow that rust's is better? Genuinely asking, as I don't have experience with that. I would imagine that if they rejected it for that reason originally they forsaw even more severe issues.

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

#294

Post by levodelellis »

dismalaf wrote: post #287
levodelellis wrote: post #264

Earlier quoted context omitted.

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 usi…

You don't really need to deal with gcc backend. Most languages are expressible in C89. It'll obviously be less readable since generated lines look nothing like source lines but C89 beats llvm in most cases, especially if the C compiler supports assembly. I stuck to using intrinsics only because I heard of compilers producing worse code when it hits asm blocks since it can't understand it as well as intrinsics. I took out llvm last time it broke my compiler because it didn't add any value

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

#295

Post by refulgentis »

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

Earlier quoted context omitted.

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"?

That's the thing man, there isn't anything. It was an odd thing in the tweet to say that it has better OOP.

(source: iOS dev from jailbreak days, so like 8 years before Swift, till 2019. He did not mean dynamic dispatch and Swift has dynamic dispatch by way of "you can annotate a Swift method with @objc and we'll emit it as an ObjC method instead of Swift", not Smalltalk-ish, like, at all. if you're the poster who originally said "because of dynamic dispatch", I understand why you're frustrated but I have 0 idea why you think dynamic dispatch in Swift would matter, much less say it makes Swift much better at OOP than Rust. It's impolite to say "utterly baffling engineering decision" in public, so there's subtext in the conversation. Namely that both claims made 0 sense if you had practical familiarity with either)

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

#296

Post by 9rx »

refulgentis wrote: post #295
9rx wrote: post #289

Earlier quoted context omitted.

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"?

That's the thing man, there isn't anything. It was an odd thing in the tweet to say that it has better OOP. (source: iOS dev from jailbreak days, so like 8 years before Swift, till 2019. He did not mean dynamic dispatch and Swift has dynamic dispatch by way of "you can annotate a Swift method with @objc and we'll emit it as an ObjC method instead of Swift", not Smalltalk-ish, like, at all. if you're the poster who or…

> That's the thing man, there isn't anything.

But that's the thing, there is: It supports message passing.

Like we already discussed long ago, it supports it poorly, and only for the sake of compatibility with Objective-C, but still that makes its OOP support better than Rust's. Rust has no OOP support at all. It is not an OOP language and never would want to be. OOP goes completely against its core principles (statically-typed, performance-minded).

Realistically, nobody would consider Swift an OOP language either. However, on the spectrum, it is unquestionably closer to being an OOP language. It at least gets an honourable mention in the short list of OOP languages. It is undeniable that Swift has "better" OOP support; not to be confused with good OOP support.

> He did not mean dynamic dispatch

Of course not. Dynamic dispatch is for function calling. OOP doesn't use dynamic dispatch. That's literally why we call it object-oriented rather than function-oriented (or functional, as the kids say). This is also why Objective-C, quite brilliantly, uses [foo bar] syntax (hint: it kind of looks like an ASCII-art envelope for a reason): To make it clear that conceptually you are not calling a function.

> I understand why you're frustrated

I don't. Fill us in.

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

#297

Post by antonvs »

zadikian wrote: post #292
antonvs wrote: post #269

Earlier quoted context omitted.

But it's not "kinda how you can do it in C". Traits are a core feature of Rust, any non-trivial Rust program uses them. Traits alone give you polymorphism across disparate types, exactly as in OO - actually better than standard OO (without interfaces), because trait polymorphism works without requiring inheritance from a common ancestor. > Especially because there's no GC. This is the only real issue I can think of.…

I know the Rust trait system has an answer to every OO concept. Another is that data field inheritance is replaced by composition. But these are more workarounds for the rarer cases you want to do OO in Rust, not the intended usual path, and doing OOP this way will get tedious. Otherwise, there'd be no difference and everyone would call Rust an OO language. Not so sure about not needing GC. Many times a problem seems…

> But these are more workarounds for the rarer cases you want to do OO in Rust, not the intended usual path, and doing OOP this way will get tedious.

It sounds like you're speculating. But this doesn't match the reality of actual Rust code. For example, here's the complete, actual code for the `Widget` trait implementation for the `Button` struct in the egui framework:

    impl Widget for Button {
        fn ui(self, ui: &mut Ui) -> Response {
            self.atom_ui(ui).response
        }
    }
(From: https://github.com/emilk/egui/blob/main/crates/egui/src/widg... , bottom of page.)

This is OO code. It's just that it's trait-oriented, not class-oriented. But that's a good thing, not a drawback. Traits are more precise, more flexible, more type-safe, and don't conflate multiple unrelated concerns in a single feature the way class inheritance does. OO languages like Java support a very similar approach, via interfaces.

You can find similar code in any Rust GUI library, and indeed in almost any non-trivial Rust program.

> Otherwise, there'd be no difference and everyone would call Rust an OO language.

Rust is not a class-based OO language. But the fact that one of its core features, traits, have "methods", and those methods have a first argument traditionally named `self` should be a clue. Trait-based OO is very much OO. Whether "Rust is an OO language" depends on how strictly you want to define "OO" to match the rather obsolete 1970s conception of it.

This is why the first question I asked you was "What OO features are you thinking of that Rust doesn't have?" Because "OO" is a broad label that covers a wide range of different features.

Rust doesn't have "classes", but classes are a 1970s-era mish-mash of a whole bunch of different concerns munged together into a single poorly-factored construct. Now, half a century later, that's well understood, and better solutions exist in the form of traits and interfaces, and related capabilities.

> Like why did ObjC feel the need to add ARC (not GC but similar goal)?

Same reason Rust includes `Rc` and `Arc`. A general-purpose language has to provide some solution to memory management based on reachability. Reference counting and tracing GC are common solutions to that. Rust's static memory management plus RC is plenty good enough for GUI applications.

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

#298

Post by refulgentis »

9rx wrote: post #296
refulgentis wrote: post #295

Earlier quoted context omitted.

That's the thing man, there isn't anything. It was an odd thing in the tweet to say that it has better OOP. (source: iOS dev from jailbreak days, so like 8 years before Swift, till 2019. He did not mean dynamic dispatch and Swift has dynamic dispatch by way of "you can annotate a Swift method with @objc and we'll emit it as an ObjC method instead of Swift", not Smalltalk-ish, like, at all. if you're the poster who or…

> That's the thing man, there isn't anything. But that's the thing, there is: It supports message passing. Like we already discussed long ago, it supports it poorly, and only for the sake of compatibility with Objective-C, but still that makes its OOP support better than Rust's. Rust has no OOP support at all. It is not an OOP language and never would want to be. OOP goes completely against its core principles (stati…

Ok, I've now read through the rest of this thread and I think I understand where you're coming from, but I also think you're making my point for me.

You're using a definition of OOP where only Smalltalk-style message passing counts. By that definition, you're right: Swift is closer, because `@objc` exists. But by that definition, neither Swift nor Rust is an OOP language in any meaningful sense, and the delta between them is mass-of-the-electron tiny. Swift's message passing support is an annotation that is a compatibility shim for a 40-year-old runtime, not a design philosophy.

So when you say Swift has "better OO support"... sure, in the same way that my car has better submarine support than yours because I left the windows cracked and water could theoretically get in. Technically true! Not useful!

The Ladybird team are C++ developers evaluating languages for a browser engine. When C++ developers say "OOP" they mean classes, inheritance hierarchies, virtual methods. The DOM is a giant inheritance tree. That's the context. You can tell them they're using the word wrong, but that doesn't change what they meant, and what they meant is the only thing that matters for understanding whether the claim made sense.

And under their definition-which is also the definition used by mass, essentially every working programmer and every university curriculum for the last 30 years-Swift and Rust are actually pretty close, which was my original point. Swift has `class` with inheritance, Rust has traits and composition. Neither is Smalltalk. The claim that Swift is "strictly better" was weird no matter which definition you pick.

(Also, and I say this respectfully: characterizing C++/Java/Rust as "functional programming" because they encapsulate data with functions is... a take. I get the logic chain you're following but that is not a definition that will help anyone communicate with anyone else, which is presumably the point of definitions.)

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

#299

Post by 9rx »

refulgentis wrote: post #298
9rx wrote: post #296

Earlier quoted context omitted.

> That's the thing man, there isn't anything. But that's the thing, there is: It supports message passing. Like we already discussed long ago, it supports it poorly, and only for the sake of compatibility with Objective-C, but still that makes its OOP support better than Rust's. Rust has no OOP support at all. It is not an OOP language and never would want to be. OOP goes completely against its core principles (stati…

Ok, I've now read through the rest of this thread and I think I understand where you're coming from, but I also think you're making my point for me. You're using a definition of OOP where only Smalltalk-style message passing counts. By that definition, you're right: Swift is closer, because `@objc` exists. But by that definition, neither Swift nor Rust is an OOP language in any meaningful sense, and the delta between…

> When C++ developers say "OOP" they mean classes, inheritance hierarchies, virtual methods.

Okay, but for that to be true in this case then you must explain how Swift has "better OOP support". If there is no rational explanation for now Swift has "better OOP support" by the metrics you are imagining, as you, me, and everyone else has alluded to earlier, then clearly that isn't what they meant.

> I get the logic chain you're following but that is not a definition that will help anyone communicate with anyone else

Won't help communicate with anyone else meaning that you are the only one capable of understanding the logic chain? I'm sure you are a talented guy, but the world isn't exactly lacking in talented people. I'm sorry to say, but most everyone on HN will have absolutely no trouble understanding this.

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

#300

Post by zephen »

jaen wrote: post #284
zephen wrote: post #268

Earlier quoted context omitted.

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 f…

> Complexity-wise, this version is more complicated (mixing different styles and paradigms)

Really? In the other Python version the author went out of his way to keep two variables, and shit out intermediate results as you went. The raku version generates a sequence that doesn't even actually get output if you're executing inside a program, but that can be used later as a sequence, if you bind it to something.

I kept my version to the same behavior as that Python version, but that's different than the raku version, and not in a good way.

You should actually ignore the print in the python, since the raku wasn't doing it anyway. So how is "create a sequence, then while it is not as long as you like, append the sum of the last two elements" a terrible mix of styles and paradigms, anyway? Where do you get off writing that?

> Lines of code don't matter anyway, cognitive load does.

I agree, and the raku line of code imposes a fairly large cognitive load.

If you prefer "for" to "while" for whatever reason, here's a similar Python to the raku.

  seq = [0,1]
  seq.extend(sum(seq[-2:]) for _ in range(18))
The differences are that it's a named sequence, and it doesn't go on forever and then take a slice. No asterisks that don't mean multiply, no carets that don't mean bitwise exclusive or.

> 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.

It's not (in my case, anyway) actually about imperative vs functional. It's about twisty stupid special symbol meanings.

Raku is perl 6 and it shows. Some people like it and that's fine. Some people don't and that's fine, too. What's not fine is to make up bogus comparisons and bogus implications about the people who don't like it.

Post reply on HN