Live data from Hacker News

Closing this as we are no longer pursuing Swift adoption

github.com

91–100 of 332 posts

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

#91
post #87
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.

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?

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

#92
post #35

Earlier quoted context omitted.

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.

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.

To be fair, work on Swift began in 2010, which would technically predate Tim Cook's accession to the position of CEO by a year or so.

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

#93
post #9
post #4

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…

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

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

#94
post #65

Earlier quoted context omitted.

What language do you recommend?

The best tool for the job is the one you know and love.

I have not developed a deep love for a language yet. Swift has been interesting me, but so has Zig.

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

#97

Earlier quoted context omitted.

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

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.

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

#98
post #90
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…

How many languages are using LLVM as its backend vs Go's?

Go never advertised, designed for, nor supported external usage of their backend.

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

#99
post #90
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…

How many languages are using LLVM as its backend vs Go's?

[deleted]

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

#100
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…

> WebKit

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.

Post reply on HN