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

101–110 of 332 posts

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

#101

Post by josephg »

rvz wrote: post #69
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.)

I think we have seen enough since the best example of a Rust browser that is Servo, has taken them 14 years to reach v0.0.1. So the approach of having a new language that requires a full rewrite (even with an LLM) is still a bad approach. Fil-C likely can do the job without a massive rewrite and achieving safety for C and C++. Job done. EDIT: The authors of Ladybird have already dismissed using Rust, and with Servo p…

> Fil-C likely can do the job without a massive rewrite and achieving safety for C and C++.

So long as you don't mind a 2-4x performance & memory usage cost.

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

#102

Post by snerbles »

rvz wrote: post #57
tvshtr wrote: post #36

Earlier quoted context omitted.

What are you talking about? It doesn't have a "browser", it has a testing shell. For a time there was actual attempt with the Verso experiment but it got shelved just recently. Servo is working at being embeddable at the same time when Rust GUI toolkits are maturing. Once it gets embedding stabilized that will be the time for a full blown browser developement.

> It doesn't have a "browser", it has a testing shell. So, yes it is still pre-historic. > Once it gets embedding stabilized that will be the time for a full blown browser developement. Servo development began in 2012. [0] 14 years later we get a v0.0.1. At this point, Ladybird will likely reach 1.0 faster than Servo could, and the latter is not even remotely close to being usable even in 14 years of waiting. [0] htt…

It's by no means accurate, but the comparative histories of Ladybird vs. Servo sure has some parallels with Linux vs. GNU Hurd.

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

#103

Post by kevin_thibedeau »

fc417fc802 wrote: post #58
jsheard wrote: post #9

Earlier quoted context omitted.

> It's a battle tested choice and pretty much every browser actually in use is written in C++. Every browser in use is stuck with C++ because they're in way too deep at this point, but Chromium and Firefox are both chipping away at it bit by bit and replacing it with safer alternatives where they feasibly can. Chromium even blocked JPEG-XL adoption until there was a safe implementation because they saw the reference…

TBF that's less a C++ thing and more that there have been several high profile decoder vulnerabilities over the past however many years. Enough that Google created the custom language WUFFS for the express purpose of implementing secure parsers for arbitrary file formats.

It's emblematic of C++ devs penchant for not implementing error handling on invalid input because of the "safety net" of exceptions and not bothering to properly handle errors or exceptions.

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

#104

Post by greazy »

stingraycharles wrote: post #91
jll29 wrote: post #87

Earlier quoted context omitted.

Andreas Kling said Rust lacks OO, which he says is useful for GUI coding. He even made an attempt at creating his own language, Jakt, under SerenityOS, but perhaps felt that C++ (earlier with, now without Swift) were the pragmatic choice for Ladybird.

But wasn’t Rust designed specifically for being a language for developing a rendering engine / web browser?

No. It was developed as a general purpose language.

I think you are conflating the development of Servo with the design and development of Rust.

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

#105

Post by refulgentis »

carefree-bob wrote: post #81
refulgentis wrote: post #48

Earlier quoted context omitted.

> Everything Chris Lattner has done has been a "successful mess". I don't have an emotional reaction to this, i.e. I don't think you're being mean, but it is wrong and reductive, which people usually will concisely, and perhaps reductively, describe as "mean". Why is it wrong? LLVM is great. Chris Lattner left Apple a *decade* ago, & thus has ~0 impact or responsibility on Swift interop with C++ today. Swift is a fun…

Not just LLVM, but Google's TPU seems to be doing fine also. Honestly it's an impressive track record.

He had 0 to do with the TPU.

I was hired around Google around the same time, but not nearly as famous :)

AFAICouldT it was a "hire first, figure out what to do later", and it ended up being Swift for TensorFlow. That went ~nowhere, and he left within 2 years.

That's fine and doesn't reflect on him, in general, that's Google for ya. At least that era of Google.

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

#106

Post by drnick1 »

Regardless of the language it is written in, one thing that I hope Ladybird will focus on when the time comes is a user-respecting Javascript implementation. Regardless of what the Web standards say, it is unacceptable that websites can (ab)use JS against the users for things such as monitoring presence/activity, disabling paste, and extracting device information beyond what is strictly necessary for an acceptably formatted website. One approach could be to report standardized (spoofed) values across the user base so that Ladybird users are essentially indistinguishable from each other (beyond the originating IP). This is more or less the approach taken by Tor, and where a project like Ladybird could make a real difference.

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

#107

Post by levodelellis »

pbohun wrote: post #77
pbohun wrote: post #43

There's no way to say this without sounding mean: Everything Chris Lattner has done has been a "successful mess". He's obviously smart, but a horrible engineer. No one should allow him to design anything. Edit: I explained my position better below.

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…

Yes. I also written a compiler and I also complained about LLVM.

LLVM is

  - Slow to compile
  - Breaks compilers/doesn't have a stable ABI
  - Optimizes poorly (at least, worse than GCC)
Swift I never used but I tried compiling it once and it was the bottom 2 slowest compiler I ever tested. The only thing nearly as bad was kotlin but 1) I don't actually remember which of these are worse 2) Kotlin wasn't meant to be a CLI compiler, it was meant to compile in the background as a language server so it was designed around that

Mojo... I have things I could say... But I'll stick to this. I talked to engineers there and I asked one how they expected any python developers to use the planned borrow checker. The engineer said "Don't worry about it" ie they didn't have a plan. The nicest thing I can say is they didn't bullshit me 100% of the time when I directly asked a question privately. That's the only nice or neutral thing I could say

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

#108

Post by tomjakubowski »

rvz wrote: post #69
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.)

I think we have seen enough since the best example of a Rust browser that is Servo, has taken them 14 years to reach v0.0.1. So the approach of having a new language that requires a full rewrite (even with an LLM) is still a bad approach. Fil-C likely can do the job without a massive rewrite and achieving safety for C and C++. Job done. EDIT: The authors of Ladybird have already dismissed using Rust, and with Servo p…

Until just a couple years ago, Servo had been a pure research project with no goal of ever releasing a full browser (and it was abandoned by Mozilla in 2020).

Igalia had five engineers working full time who turned that science project into v0.0.1 in less than two years.

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

#109

Post by truncate »

iLemming wrote: post #50
isodev wrote: post #30

Earlier quoted context omitted.

Swift never felt truly open source either. That people can propose evolution points doesn’t change the fact that Apple still holds all the keys and pushes whatever priorities they need, even if they’re not a good idea (e.g. Concurrency, Swift Testing etc) Also funny enough, all cross platform work is with small work groups, some even looking for funding … anyway.

> Swift never felt truly open source either. Apple has been always 'transactional' when it comes to OSS - they open source things only when it serves a strategic purpose. They open-sourced Swift only because they needed the community to build an ecosystem around their platform. Yeah, well, sure they've done some work around LLVM/Clang, WebKit, CUPS, but it's really not proportional to the size and the influence they…

>> some teams are just not permitted to contribute to OSS in any way

My understanding is that by default you are not allowed to contribute to open-source even if its your own project. Exceptions are made for teams whose function is to work on those open-source project e.g. Swift/LLVM/etc...

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

#110

Post by elcritch »

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.

Also I believe one of the core LadyBird devs was an ex Apple employee on WebKit which has been using Swift as well.
Post reply on HN