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.
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.
> If those "popular websites" are the likes of Facebook and Instagram, I don't see that as a big loss.
Personally I wouldn't mind either but my point is that they probably want to cater to the average person, and not just security conscious tech savvy people, and if that's the case, then you really can't exclude FB/IG/YT and others from working properly in your browser.
The commit removing Swift has a little bit more detail:
Everywhere: Abandon Swift adoption
After making no progress on this for a very long time, let's acknowledge
it's not going anywhere and remove it from the codebase.
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.
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 still have.
Compare them to Google, with - TensorFlow, k8s, Android (nominally), Golang, Chrome, and a long tail of other shit. Or Meta - PyTorch and the Llama model series. Or even Microsoft, which has dramatically reversed course from its "open source is a cancer" era (yeah, they were openly saying that, can you believe it?) to becoming one of the largest contributors on GitHub.
Apple I've heard even have harshest restrictions about it - some teams are just not permitted to contribute to OSS in any way. Obsessively secretive and for what price? No wonder that Apple's software products are just horrendously bad, if not all the time - well, too often. And on their own hardware too.
I wouldn't mind if Swift dies, I'm glad Objective-C is no longer relevant. In fact, I can't wait for Swift to die sooner.
>> 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...
I talked to an apple engineer at a bar years ago and he said they aren’t allowed to work on _anything_ including side projects without getting approval first. Seemed like a total wtf moment to me.
Sort of an exception that proves the rule. Yes, it's great and was released for free. But at least partially that's not a strategic decision from Apple but just a requirement of the LGPLv2 license[1] under which they received it (as KHTML) originally.
And even then, it was Blink and not WebKit that ended up providing better value to the community.
[1] It does bear pointing out that lots of the new work is dual-licensed as 2-clause BSD also. Though no one is really trying to test a BSD-only WebKit derivative, as the resulting "Here's why this is not a derived work of the software's obvious ancestor" argument would be awfully dicey to try to defend. The Ship of Theseus is not a recognized legal principle, and clean rooms have historically been clean for a reason.
The fact that Swift is an Apple baby should indeed be considered a red flag. I know there are some Objective-C lovers out there but I think it is an abomination.
Apple is (was?) good at hardware design and UX, but they pretty bad at producing software.
For what it’s worth, ObjC is not Apple’s brainchild. It just came along for the ride when they chose NEXTSTEP as the basis for Mac OS X.
I haven’t used it in a couple decades, but I do remember it fondly. I also suspect I’d hate it nowadays. Its roots are in a language that seemed revolutionary in the 80s and 90s - Smalltalk - and the melding of it with C also seemed revolutionary at the time. But the very same features that made it great then probably (just speculating - again I haven’t used it in a couple decades) aren’t so great now because a different evolutionary tree leapfrogged ahead of it. So most investment went into developing different solutions to the same problems, and ObjC, like Smalltalk, ends up being a weird anachronism that doesn’t play so nicely with modern tooling.
I've never written whole applications in ObjC but have had to dabble with it as part of Ardour (ardour.org) implementation details for macOS.
I think it's a great language! As long as you can tolerate dynamic dispatch, you really do get the best of C/C++ combined with its run-time manipulable object type system. I have no reason to use it for more code than I have to, but I never grimace if I know I'm going to have to deal with it. Method swizzling is such a neat trick!
Many of the built-in types in Objective C all have names beginning with “NS” like “NSString”. The NS stands for NeXTSTEP. I always found it insane that so many years later, every iPhone on Earth was running software written in a language released in the 80s. It’s definitely a weird language, but really quite pleasant once you get used to it, especially compared to other languages from the same time period. It’s truly remarkable they made something with such staying power.
Next was more or less an Apple spinoff, that was later acquired by Apple. Objective-C was created because using standards is contrary to the company culture. And with Swift they are painting themselves into a corner.
Years ago I wrote a toy Lisp implementation in Objective-C, ignoring Apple’s standard library and implementing my own class hierarchy. At that point it was basically standard C plus Smalltalk object dispatch, and it was a very cool language for that type of project.
I haven’t used it in Apple’s ecosystem, so maybe I am way off base here. But it seems to me that it was Apple’s effort to evolve the language away from its systems roots into a more suitable applications language that caused all the ugliness.
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 left Apple back then in 2017.
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 (when swift started and when it was released), the ecosystem was a lot different. Oracle v Google was still going on and wasn't finished until 2021. So Java really wasn't on the table. Kotlin hit 1.0 in 2016 and really wasn't at a stage to be used when Apple was creating Swift. Rust was still undergoing massive changes.
And a big part of it was simply that they wanted something that would be an easy transition from Objective-C without requiring a lot of bridging or wrappers. Swift accomplished that, but it also meant that a lot of decisions around Swift were made to accommodate Apple, not things that might be generally useful to the lager community.
All languages have this to an extent. For example, Go uses a non-copying GC because Google wanted it to work with their existing C++ code more easily. Copying GCs are hard to get 100% correct when you're dealing with an outside runtime that doesn't expect things to be moved around in memory. This decision probably isn't what would be the best for most of the non-Google community, but it's also something that could be reconsidered in the future since it's an implementation detail rather than a language detail.
I'm not sure any non-Apple language would have bent over backwards to accommodate Objective-C. But also, what would Apple have chosen circa-2010 when work on Swift started? Go was (and to an extent still is) "we only do things these three Googlers think is a good idea", Go was basically brand-new at the time, and even today Go doesn't really have a UI framework. Kotlin hadn't been released when work started on Swift. C# was still closed source. Rust hadn't appeared yet and was still undergoing a lot of big changes through Swift's release. Python and other dynamic languages weren't going to fit the bill. There really wasn't anything that existed then which could have been used instead of Swift. Maybe D could have been used.
But also, is Swift bad? I think that some of the type inference stuff that makes compiles slow is genuinely a bad choice and I think the language could have used a little more editing, but it's pretty good. What's better that doesn't come with a garbage collector? I think Rust's borrow checker would have pissed off way too many people. I think Apple needed a language without a garbage collector for their desktop OS and it's also meant better battery life and lower RAM usage on mobile.
If you're looking for a language that doesn't have a garbage collector, what's better? Heck, what's even available? Zig is nice, but you're kinda doing manual memory management. I like Rust, but it's a much steeper learning curve than most languages. There's Nim, but its ARC-style system came 5+ years after Swift's introduction.
So even today and even without Objective-C, it's hard to see a language that would fit what Apple wants: a safe, non-GC language that doesn't require Rust-style stuff.
>For example, Go uses a non-copying GC because Google wanted it to work with their existing C++ code more easily. Copying GCs are hard to get 100% correct when you're dealing with an outside runtime that doesn't expect things to be moved around in memory.
Do you have a source for this?
C# has a copying GC, and easy interop with C has always been one of its strengths. From the perspective of the user, all you need to do is to "pin" a pointer to a GC-allocated object before you access it from C so that the collector avoids moving it.
I always thought it had more to do with making the implementation simpler during the early stages of development, with the possibility of making it a copying GC some time in the feature (mentioned somewhere in stdlib's sources I think) but it never came to fruition because Go's GC was fast enough and a lot of code has since been written with the assumption that memory never moves. Adding a copying GC today would probaby break a lot of existing code.
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.
Swift has it's problems, and I certainly wouldn't use it for anything outside of development for Apple platforms, but saying they had no experts on the team is a stretch. Most Swift leads were highly regarded members of the C++ world, even if you discount Chris Lattner.
I meant no Swift experts in the Ladybird team. Their expertise is C++, you may think the transition is easy, and it can be pretty painless at first, but true language expertise means knowing how to work around its flaws, and adapting your patterns to its strenghts. Cool for a hobby, but switching language in the middle of an herculean work is suicide.
The point of Swift is not really the language, it's the standard ABI for dynamic code. The Rust folks should commit to supporting it as a kind of extern FFI/interop alongside C, at least on platforms where a standard Swift implementation exists.
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.
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.
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.
The language's largest project before it hit 1.0 was Servo. The language wasn't designed for browsers, but it certainly was informed by them and their struggles with maintaining and developing Firefox.
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".
> 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 downvotes, -3 is a little wild, given current replies don't raise any issues.
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.)
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.
The RUST ecosystem barely just started getting into shape on the GUI toolkits frontend... So perhaps save your criticisms for something that wasn't born out of the vacuum.
> Why did Ladybird even attempt this with Swift, but (I presume) not with Rust? I
Probably the same reason why Rust is problematic in game development. The borrow checker and idiomatic Rust do not go well together with things that demand cyclic dependencies/references. Obviously there are ways around it but they're not very ergonomic/productive.
I so wholeheartedly agree. You are making a new web browser - akin to a new OS - and you want it open source for everybody but you choose swift not rust?
Lots of people seem really committed to OOP. Rust is definitely a bad fit if you can't imagine writing code without classes and objects. I don't think this makes rust is a bad language for the problem. Its just, perhaps, makes rust a bad language for some programmers.
It looked to me like it was just due to recurring build issues. Lots of "swift can't import these conflicting C++ versioned libraries concurrently" and "can't use some operator due to versioning or build conflicts". Basically it sounds like trying to add swift to the project was breaking too many things, and they decided it wasn't worth it.
It's a shame, I think swift is an underappreciated language, however I understand their reasoning. I think if they tried to just use swift from the beginning it would have been too ambitious, and trying to add swift to a fragile, massive project was probably too complex.
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.
Not too surprising. Swift is too tied to Apple and it's not really clear what the benefit would be relative to a subset of C++ written with contemporary memory safety practices. It's a battle tested choice and pretty much every browser actually in use is written in C++.
> 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 C++ decoder as such a colossal liability.
IMO the takeaway is that although those browsers do use a ton of C++ and probably always will, their hard-won lessons have led them to wish they didn't have to, and to write a brand new browser in C++ is just asking to needlessly repeat all of the same mistakes. Chromium uses C++ because Webkit used C++ because KHTML used C++ in 1998. Today we have the benefit of hindsight.
> Chromium even blocked JPEG-XL adoption until there was a safe implementation because they saw the reference C++ decoder as such a colossal liability.
Quickly followed by several vulnerabilities in that reference library as well; good move
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 can be written entirely from scratch, the former not even using any standard libraries; so beware when you are inclined to say 'not feasible'.
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.
migrating any large project is going to be billions of dollars worth of labor. Language isn't a large factor in that cost, you can save few tens of millions at most with a better language.
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.
> 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 race 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?
Having a checklist of "things not to do" is historically a pretty in effectiveway to ensure memory safety, which is why the parent comment was asking for details. The fact that this type of thing gets dismissed as a non-issue is honestly a huge part of the problem in my opinion; it's time to move on from pretending this is a skill issue.
Servo is slowly but steadily getting there. The thing with Servo is that it's highly modularized and some of its components are widely used by the larger Rust ecosystem, even it the whole browser engine isn't. So there's multi-pronged vested interest in developing it.
Moreover, Servo aims to be embeddable (there are some working examples already), which is where other non-Chrome/ium browsers are failing (and Firefox too).
Thanks to this it has much better chance at wider adoption and actually spawning multiple browsers.
> The thing with Servo is that it's highly modularized and some of its components are widely used by the larger Rust ecosystem, even it the whole browser engine isn't.
Alas not nearly as modularized as it could be. I think it's mainly just Stylo and WebRender (the components that got pulled into Firefox), and html5ever (the HTML parser) that are externally consumable.
Text and layout support are two things that could easily be ecosystem modules but aren't seemingly (from my perspective) because the ambition to be modular has been lost.
I've seen recent talk about swappable js engine, so I'm unsure about the ambition being lost.
I'm eyeing Blitz too (actually tried to use it in one of my projects but the deps fucked me up).
Servo's history is much more complicated and originally was planned to be used for the holo lens before the layoff. Comparing trajectory doesn't make sense they had completely different goals and directions.
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.
> 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.
This is disingenuous. Servo is using RUST, language which grew together with it, pretty much, and all components surrounding it.
C++ is how old, please remind me?
Well, it was a terrible idea in any case unless it was for high-level-ish code only. Swift generally can't compete with C++ in raw performance (in the same way as Java - yeah, there are benchmarks where it's faster, but it basically doesn't happen in real programs).
Performance wasn't really the issue here though. The issue was that Swift's C++ interop is still half-baked and kept breaking the build. You can write a perfectly fast browser in Swift for the non-hot-path stuff, which is most of a browser. They killed it because the tooling wasn't ready, not because the language is slow.
It wasn't the reason why it was removed, but, well we agree, it would have been a problem if used indiscriminately. I didn't do any additional research, but what I read in public was simply "Ladybird is going to use Swift".
Hurray for micro benchmarks. Anyway, every language can be abused. I can make Java run slower than Ruby. Given that it runs on Microcontrollers on billions of devices, I don't think Swift is necessarily the problem in whatever case you have in mind (And yes I stole oracle's java marketing there for Swift, it is true though.)
This reads like an AI response to me. Would you elaborate? I can see no reason to believe it would achieve stability based on many of the statements in this issue.
The task list with possible workarounds was there, so I imagine there was also the possibility of continuing with the integration. I understand that after two years it may be inconvenient, but they had already started, so why throw away all that time? As for the “AI” issue, I think we need to start being less paranoid about it
Chiming in: indeed, the response is very dry, and raises suspicion. It states the obvious facts and then makes a boring statement, lacking any nuance of the conversation. It is not argumentative in the very least.
Time has been spend, yes. But the topic at hand is after so much time the conclusion to abandon this path is justified.
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.
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 agnostic" assembly, which is very similar to the IR idea with LLVM.
Swift: I was very excited with the first release of Swift. But it ultimately did not have a very focused vision outlined for it. Because of this, it has morphed into a mess. It tries to be everything for everyone, like C++, and winds up being mediocre, and slow to compile to top it off.
Mojo isn't doesn't exist for the public yet. I hope it turns out to be awesome, but I'm just not going to get my hopes up this time.
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
As far as I know, only Go uses Go's back end because it was specifically designed for Go. But the architecture is such that it makes it trivial for Go to cross compile for any OS and architecture. This is something that LLVM cannot do. You have to compile a new compiler for every OS and arch combo you wish to compile to.
You could imagine creating a modified Go assembler that is more generic and not tied to Go's ABI that could accomplish the same effect as LLVM. However, it'd probably be better to create a project like that from scratch, because most of Go's optimizations happen before reaching the assembler stage.
It would probably be best to have the intermediate language that QBE has and transform that into "intermediate assembly" (IA) very similar to Go's assembly. That way the IL stage could contain nearly all the optimization passes, and the IA stage would focus on code generation that would translate to any OS/arch combo.
You don't explain or support your position, you are calling Lattner names. That's not helpful to me or anyone else if we are trying to evaluate his work. Swift has millions of users as does Mojo and Modular in general. These are not trivial accomplishments.
> 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 language to write, hence, why they shoehorned it in, in the first place.
Mojo is fine, but I wouldn't really know how you or I would judge it. For me, I'm not super-opinionated on Python, and it doesn't diverge heavily from it afaik.
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.
This kills the internet.
Personally I wouldn't mind either but my point is that they probably want to cater to the average person, and not just security conscious tech savvy people, and if that's the case, then you really can't exclude FB/IG/YT and others from working properly in your browser.
Swift is a poorly designed language, slow to compile, visibly not on path to be major system language, and they had no expert on the team.
I am glad they are cutting their losses.
Also funny enough, all cross platform work is with small work groups, some even looking for funding … anyway.
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 still have.
Compare them to Google, with - TensorFlow, k8s, Android (nominally), Golang, Chrome, and a long tail of other shit. Or Meta - PyTorch and the Llama model series. Or even Microsoft, which has dramatically reversed course from its "open source is a cancer" era (yeah, they were openly saying that, can you believe it?) to becoming one of the largest contributors on GitHub.
Apple I've heard even have harshest restrictions about it - some teams are just not permitted to contribute to OSS in any way. Obsessively secretive and for what price? No wonder that Apple's software products are just horrendously bad, if not all the time - well, too often. And on their own hardware too.
I wouldn't mind if Swift dies, I'm glad Objective-C is no longer relevant. In fact, I can't wait for Swift to die sooner.
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...
Sort of an exception that proves the rule. Yes, it's great and was released for free. But at least partially that's not a strategic decision from Apple but just a requirement of the LGPLv2 license[1] under which they received it (as KHTML) originally.
And even then, it was Blink and not WebKit that ended up providing better value to the community.
[1] It does bear pointing out that lots of the new work is dual-licensed as 2-clause BSD also. Though no one is really trying to test a BSD-only WebKit derivative, as the resulting "Here's why this is not a derived work of the software's obvious ancestor" argument would be awfully dicey to try to defend. The Ship of Theseus is not a recognized legal principle, and clean rooms have historically been clean for a reason.
Apple is (was?) good at hardware design and UX, but they pretty bad at producing software.
I haven’t used it in a couple decades, but I do remember it fondly. I also suspect I’d hate it nowadays. Its roots are in a language that seemed revolutionary in the 80s and 90s - Smalltalk - and the melding of it with C also seemed revolutionary at the time. But the very same features that made it great then probably (just speculating - again I haven’t used it in a couple decades) aren’t so great now because a different evolutionary tree leapfrogged ahead of it. So most investment went into developing different solutions to the same problems, and ObjC, like Smalltalk, ends up being a weird anachronism that doesn’t play so nicely with modern tooling.
I think it's a great language! As long as you can tolerate dynamic dispatch, you really do get the best of C/C++ combined with its run-time manipulable object type system. I have no reason to use it for more code than I have to, but I never grimace if I know I'm going to have to deal with it. Method swizzling is such a neat trick!
I haven’t used it in Apple’s ecosystem, so maybe I am way off base here. But it seems to me that it was Apple’s effort to evolve the language away from its systems roots into a more suitable applications language that caused all the ugliness.
So they already got what they wanted without inventing a new language. There must be some other reason.
[0] https://atp.fm/205-chris-lattner-interview-transcript#swiftc...
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 (when swift started and when it was released), the ecosystem was a lot different. Oracle v Google was still going on and wasn't finished until 2021. So Java really wasn't on the table. Kotlin hit 1.0 in 2016 and really wasn't at a stage to be used when Apple was creating Swift. Rust was still undergoing massive changes.
And a big part of it was simply that they wanted something that would be an easy transition from Objective-C without requiring a lot of bridging or wrappers. Swift accomplished that, but it also meant that a lot of decisions around Swift were made to accommodate Apple, not things that might be generally useful to the lager community.
All languages have this to an extent. For example, Go uses a non-copying GC because Google wanted it to work with their existing C++ code more easily. Copying GCs are hard to get 100% correct when you're dealing with an outside runtime that doesn't expect things to be moved around in memory. This decision probably isn't what would be the best for most of the non-Google community, but it's also something that could be reconsidered in the future since it's an implementation detail rather than a language detail.
I'm not sure any non-Apple language would have bent over backwards to accommodate Objective-C. But also, what would Apple have chosen circa-2010 when work on Swift started? Go was (and to an extent still is) "we only do things these three Googlers think is a good idea", Go was basically brand-new at the time, and even today Go doesn't really have a UI framework. Kotlin hadn't been released when work started on Swift. C# was still closed source. Rust hadn't appeared yet and was still undergoing a lot of big changes through Swift's release. Python and other dynamic languages weren't going to fit the bill. There really wasn't anything that existed then which could have been used instead of Swift. Maybe D could have been used.
But also, is Swift bad? I think that some of the type inference stuff that makes compiles slow is genuinely a bad choice and I think the language could have used a little more editing, but it's pretty good. What's better that doesn't come with a garbage collector? I think Rust's borrow checker would have pissed off way too many people. I think Apple needed a language without a garbage collector for their desktop OS and it's also meant better battery life and lower RAM usage on mobile.
If you're looking for a language that doesn't have a garbage collector, what's better? Heck, what's even available? Zig is nice, but you're kinda doing manual memory management. I like Rust, but it's a much steeper learning curve than most languages. There's Nim, but its ARC-style system came 5+ years after Swift's introduction.
So even today and even without Objective-C, it's hard to see a language that would fit what Apple wants: a safe, non-GC language that doesn't require Rust-style stuff.
Do you have a source for this?
C# has a copying GC, and easy interop with C has always been one of its strengths. From the perspective of the user, all you need to do is to "pin" a pointer to a GC-allocated object before you access it from C so that the collector avoids moving it.
I always thought it had more to do with making the implementation simpler during the early stages of development, with the possibility of making it a copying GC some time in the feature (mentioned somewhere in stdlib's sources I think) but it never came to fruition because Go's GC was fast enough and a lot of code has since been written with the assumption that memory never moves. Adding a copying GC today would probaby break a lot of existing code.
And someone will be stuck not to do anything because they are unsatisfied with all languages. :-)
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.
Tools to do X better are often designed by people who get paid a lot to do X and worry about losing their job if they are not good enough at X.
I think you are conflating the development of Servo with the design and development of Rust.
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 downvotes, -3 is a little wild, given current replies don't raise any issues.
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.
Igalia had five engineers working full time who turned that science project into v0.0.1 in less than two years.
So long as you don't mind a 2-4x performance & memory usage cost.
> Job done.
Seems like you forgot a few stops in your train of thought, Speed Racer.
[1] https://www.swift.org/documentation/cxx-interop/
Said differently: the C++ interop did not support calling the C++ library I wanted to use, so I wrote a C wrapper.
Probably the same reason why Rust is problematic in game development. The borrow checker and idiomatic Rust do not go well together with things that demand cyclic dependencies/references. Obviously there are ways around it but they're not very ergonomic/productive.
20240810 https://news.ycombinator.com/item?id=41208836 Ladybird browser to start using Swift language this fall
Lots of people seem really committed to OOP. Rust is definitely a bad fit if you can't imagine writing code without classes and objects. I don't think this makes rust is a bad language for the problem. Its just, perhaps, makes rust a bad language for some programmers.
For the record, I don't have a dog in this fight. As long as it runs on Linux, I'm willing to test drive it when it's ready.
It's a shame, I think swift is an underappreciated language, however I understand their reasoning. I think if they tried to just use swift from the beginning it would have been too ambitious, and trying to add swift to a fragile, massive project was probably too complex.
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.
From what I can tell they're pretty laser focused on making a browser (even in this issue, they're abandoning Swift).
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 C++ decoder as such a colossal liability.
IMO the takeaway is that although those browsers do use a ton of C++ and probably always will, their hard-won lessons have led them to wish they didn't have to, and to write a brand new browser in C++ is just asking to needlessly repeat all of the same mistakes. Chromium uses C++ because Webkit used C++ because KHTML used C++ in 1998. Today we have the benefit of hindsight.
Quickly followed by several vulnerabilities in that reference library as well; good move
And Andreas Kling already proved the naysayers wrong when he showd that a new operating system and Web browser can be written entirely from scratch, the former not even using any standard libraries; so beware when you are inclined to say 'not feasible'.
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.)
Ranges are not memory safe. Sorry.
Having a checklist of "things not to do" is historically a pretty in effectiveway to ensure memory safety, which is why the parent comment was asking for details. The fact that this type of thing gets dismissed as a non-issue is honestly a huge part of the problem in my opinion; it's time to move on from pretending this is a skill issue.
Moreover, Servo aims to be embeddable (there are some working examples already), which is where other non-Chrome/ium browsers are failing (and Firefox too). Thanks to this it has much better chance at wider adoption and actually spawning multiple browsers.
Alas not nearly as modularized as it could be. I think it's mainly just Stylo and WebRender (the components that got pulled into Firefox), and html5ever (the HTML parser) that are externally consumable.
Text and layout support are two things that could easily be ecosystem modules but aren't seemingly (from my perspective) because the ambition to be modular has been lost.
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] https://en.wikipedia.org/wiki/Servo_(software)
When Servo is done, it's going to be a beast.
It's getting hundreds of commits per week:
https://github.com/servo/servo/graphs/commit-activity
And no, they're not being disingenuous.
https://en.wikipedia.org/wiki/Sunk_cost
Time has been spend, yes. But the topic at hand is after so much time the conclusion to abandon this path is justified.
What are other projects trying something similar that deserve attention?
Carefully making decisions and then reassessing those choices later on when they prove to be problematic is the opposite of handwavey...
Edit: I explained my position better below.
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 agnostic" assembly, which is very similar to the IR idea with LLVM.
Swift: I was very excited with the first release of Swift. But it ultimately did not have a very focused vision outlined for it. Because of this, it has morphed into a mess. It tries to be everything for everyone, like C++, and winds up being mediocre, and slow to compile to top it off.
Mojo isn't doesn't exist for the public yet. I hope it turns out to be awesome, but I'm just not going to get my hopes up this time.
LLVM is
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 thatMojo... 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
You could imagine creating a modified Go assembler that is more generic and not tied to Go's ABI that could accomplish the same effect as LLVM. However, it'd probably be better to create a project like that from scratch, because most of Go's optimizations happen before reaching the assembler stage.
It would probably be best to have the intermediate language that QBE has and transform that into "intermediate assembly" (IA) very similar to Go's assembly. That way the IL stage could contain nearly all the optimization passes, and the IA stage would focus on code generation that would translate to any OS/arch combo.
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 language to write, hence, why they shoehorned it in, in the first place.
Mojo is fine, but I wouldn't really know how you or I would judge it. For me, I'm not super-opinionated on Python, and it doesn't diverge heavily from it afaik.
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.
If he's such a horrible engineer then we should have lots of LLVM replacements, right?