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

121–130 of 332 posts

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

#121

Post by satvikpendem »

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…

Servo was essentially integrated into Firefox. It was not a browser in itself until it was put into a foundation on its own.

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

#122

Post by amluto »

mempko wrote: post #26
amluto wrote: post #11

Earlier quoted context omitted.

> a subset of C++ written with contemporary memory safety practices What is this mythical subset of C++? Does it include use of contemporary STL features like string_view? (Don’t get me wrong — modern STL is considerably improved, but it’s not even close to being memory-safe.)

memory safety isn't really much of a problem with modern C++. We have the range library now for instance. What's nice about modern C++ is you can almost avoid most manual loops and talk at the algorithm level.

Are we talking about the same range library? The one that showed up in C++20 and is basically just iterator pairs dressed up nicely? The one where somehow the standard thought all memory safety issues with iterations could be summed up with a single “borrowed” bit? The one where instead of having a nice loop you can also build a little loop body pipeline and pass it as a parameter and have exactly the same iterator invalidation and borrowing problems that C++ has had since day 1?

Ranges are not memory safe. Sorry.

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

#123

Post by hollerith »

diath wrote: post #117
stingraycharles wrote: post #91

Earlier quoted context omitted.

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

Rust initially started as a hobby project of a person who happened to be a Mozilla employee and later got sponsored by the foundation however it was not a language that was specifically designed with browsers in mind.

How could browsers not be on his mind when his job was to contribute to Firefox as a dev?

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

#124

Post by tredre3 »

nylonstrung wrote: post #95

Hard to feel excited for this project when it feels so handwavey and when basic technical decisions have never been nailed down. What are other projects trying something similar that deserve attention?

> when it feels so handwavey

Carefully making decisions and then reassessing those choices later on when they prove to be problematic is the opposite of handwavey...

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

#125

Post by bbkane »

refulgentis wrote: post #39
losvedir wrote: post #13

Ah, that's too bad. Does that mean their own programming language, Jakt, is back on the table?

For their sake, I hope not. I don't think an outside-donation-financed project with this much ADD can survive in the long term. It's frustrating to discuss. It is a wonderful case study in how not to make engineering management decisions, and yet, they've occurred over enough time, and the cause is appealing enough, that it's hard to talk about out loud in toto without sounding like a dismissive jerk.

Maybe I misunderstand, but I thought Jakt was part of SerenityOS, not Ladybird.

From what I can tell they're pretty laser focused on making a browser (even in this issue, they're abandoning Swift).

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

#126

Post by drnick1 »

diath wrote: post #114
drnick1 wrote: post #106

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

There's just too many defense mechanisms on popular websites that would simply make Ladybird flagged as a bot and render the website unusable. I wouldn't mind a toggle to switch between this and normal behavior but having that as a default would be bad for wider adoption.

If those "popular websites" are the likes of Facebook and Instagram, I don't see that as a big loss. That being said, I find that most of the Web works just fine on Tor, so it's certainly possible. Most of the issues seem related to the (known) the exit IP being overused or identified as Tor.

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

#127

Post by diath »

hollerith wrote: post #123
diath wrote: post #117

Earlier quoted context omitted.

Rust initially started as a hobby project of a person who happened to be a Mozilla employee and later got sponsored by the foundation however it was not a language that was specifically designed with browsers in mind.

How could browsers not be on his mind when his job was to contribute to Firefox as a dev?

Do your hobbies revolve around the benefits for your employer? I don't mean it in a snarky way either, but given that Rust was initially written in OCaml, you could see how it could go like "I like programming, I like type systems but I want something procedural over functional so let me give it a go".

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

#128

Post by stephc_int13 »

mdasen wrote: post #89
isodev wrote: post #35

Earlier quoted context omitted.

Some refer to the “Tim Cook doctrine” as a reason for Swift’s existence. It’s not meant to be good, just to fulfill the purpose of controlling that part of their products, so they don’t have to rely on someone else’s tooling.

I definitely agree with the first point - it's not meant to be the best. On the second part, I think the big thing was that they needed something that would interop with Objective-C well and that's not something that any language was going to do if Apple didn't make it. Swift gave Apple something that software engineers would like a ton more than Objective-C. I think it's also important to remember that in 2010/2014…

I think that their culture of trying to invent their own standards is generally bad, but it is even worse when it is a programming language. I believe they are painting themselves into a corner.

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

#129

Post by bbkane »

jll29 wrote: post #93
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…

It's probably okay to solve one problem at a time: first solve the "free open source browser, developed from the Web standard specs" problem in an established language (C++), and then the "reimplement all of part of it in a more suitable (safer, higher productivity) language - yet to be devised - problem. And Andreas Kling already proved the naysayers wrong when he showd that a new operating system and Web browser ca…

Maybe? I feel like there's been lots of efforts to migrate large C++ codebases over the years, and few actually complete the migration. Heck, Google is even making Carbon to try to solve this.

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

#130

Post by Findecanor »

stockresearcher wrote: post #68
isodev wrote: post #35

Earlier quoted context omitted.

Some refer to the “Tim Cook doctrine” as a reason for Swift’s existence. It’s not meant to be good, just to fulfill the purpose of controlling that part of their products, so they don’t have to rely on someone else’s tooling.

That doesn’t really make sense though. I thought that they hired Lattner to work on LLVM/clang so they could have a non-gpl compiler and to make whatever extensions they wanted to C/Obj-C. Remember when they added (essentially) closures to C to serve their internal purposes? So they already got what they wanted without inventing a new language. There must be some other reason.

The Accidental Tech podcast had a long interview with Lattner about Swift in 2017 [0]. He makes it out as something that had started as side-project / exploration thing without much of an agenda, which grew mostly because of how good positive feedback the project had got from other developers. He had recently left Apple back then, and supposedly left the future of Swift in other peoples' hands.

[0] https://atp.fm/205-chris-lattner-interview-transcript#swiftc...

Post reply on HN