Live data from Hacker News

Ladybird browser to start using Swift language this fall

twitter.com

121–130 of 205 posts

Re: Ladybird browser to start using Swift language this fall

#121

For those who are worried, Andreas is a thoughtful dude. This decision was not made on a whim. Also, they’re not doing a massive rewrite: > The Swift team is also investing heavily in C++ interop, which means there's a real path to incremental adoption, not just gigantic rewrites. To me, the Tweet does a good job justifying the decision. I’m rooting for Ladybird, and I hope this decision pays off. A modern browser in…

> For those who are worried, Andreas is a thoughtful dude. This decision was not made on a whim.

Yes. But many terrible decisions are taken this same way.

> and I hope this decision pays off

It is terrible when we need to hope for something to succeed because we see that they are clearly doing something wrong but will do it that way anyway because they are strong-willed. Just take the obvious path everybody is pointing to.

Guy doesn't even know Swift yet, wants to rewrite a Chrome/Firefox alternative using it. That's a great recipe for failure. Alright, I need to find another browser project to be delusional about.

Re: Ladybird browser to start using Swift language this fall

#122

For those who are worried, Andreas is a thoughtful dude. This decision was not made on a whim. Also, they’re not doing a massive rewrite: > The Swift team is also investing heavily in C++ interop, which means there's a real path to incremental adoption, not just gigantic rewrites. To me, the Tweet does a good job justifying the decision. I’m rooting for Ladybird, and I hope this decision pays off. A modern browser in…

I strongly disagree. This is not a justified decision, they just feel like it based either on vague and speculative reasons, or because they are funded to do so, I would not be surprised if they had discussions with the Swift marketing team.

Can you back up this claim? Knowing what I know of both Andreas and the Swift team I find this comment incredibly bizarre.

You either know something the rest of us don’t or you have made an emotional outburst in the form of an insult.

Re: Ladybird browser to start using Swift language this fall

#123
Hm. Not sure, if this is really a wise choice. After all they are choosing to use an Apple controlled programming language. Whatever direction Apple wants to go in, they will face themselves with following or working around. As an example we can look at Go and the whole GOPROXY debacle. And they will also have to deal with Apple not going into a direction, if they need that direction. Might have to build more stuff themselves, than with a language that is basically community owned. What if the Swift compiler starts doing things they don't like? They just going to be stuck at an obsolete version then? Or fork the language?

Re: Ladybird browser to start using Swift language this fall

#124
post #7

============================== Andreas Kling @awesomekling · 44m My general thoughts on Rust: - Excellent for short-lived programs that transform input A to output B - Clunky for long-lived programs that maintain large complex object graphs - Really impressive ecosystem - Toxic community ==============================

Interesting re complex projects. Compared to other langs I've used, rust gives me more confidence in maintaining and refactoring complex projects, maintaining state etc. I think this is due to the strict type checks, the helpful compile errors, and the ownership system. Maybe also due to the robustness of what I call struct-and-enum-oriented programming. I have plenty of my own beefs with rust that I won't go into he…

It's definitely more clunky for complex object graphs. Making a useful directed graph with cycles is pretty annoying. Not impossible my any means (I'm currently working on a Rust project for audio graphs that allows cycles), but not nearly as easy as a GC language would make it.

Re: Ladybird browser to start using Swift language this fall

#125

Earlier quoted context omitted.

> I would have thought that Ladybird would be using a language that specifically guarantees memory safety which is Rust. Rust isnt the only compiled language that provides memory safety by default. Swift does as well.

Does Swift enforce memory safety in concurrent code also, i.e. preventing thread-unsafe data access in safe code? That's a really hard problem that Rust tries to address mostly successfully, and many other languages don't.

Yes. That is a new feature as of version 6 of Swift.

https://www.swift.org/migration/documentation/swift-6-concur...

Re: Ladybird browser to start using Swift language this fall

#126
post #85
post #65

Earlier quoted context omitted.

C# has a uphill battle against those that don't believe in systems programming languages with GC, despite several graphical workstations have been done in the past in such languages. Unfortunately freebie UNIX, and security was yet decades away to be relevant to governmental regulators, thus they never managed to gain enough mindshare to keep going. Additionally even with all the .NET team efforts, the technology rem…

GC still has the downside of higher memory overhead. While I’m not particularly a fan of Swift, this is a relevant argument for a general-purpose browser implementation.

Reference counting is also a GC algorithm, even though people pretend otherwise, as they seldom learn from CS literature.

Plus all systems languages with GC, including C#, can do C and C++ style memory management.

Re: Ladybird browser to start using Swift language this fall

#127
post #7

============================== Andreas Kling @awesomekling · 44m My general thoughts on Rust: - Excellent for short-lived programs that transform input A to output B - Clunky for long-lived programs that maintain large complex object graphs - Really impressive ecosystem - Toxic community ==============================

I'd drop the "long-lived" and "short-lived" from the first two points. Rust is great for long lived programs, and is extremely clunky for managing any kind of object graph in general. The lifetime of the program has little to do with it, so I'm confused by those qualifiers. I've written plenty of Rust software that has run uninterrupted for years. I've seen way more people complaining about Rust evangelism and toxici…

> I'm starting to wonder if the Rust toxicity and evangelism are more meme than reality.

Doubtful. If you're running a somewhat known FOSS C or C++ project, chances are you've had to close issues from Rust fanatics aggressively urging you for a rewrite, and shaming you if you object. Nothing has changed in that regard.

Re: Ladybird browser to start using Swift language this fall

#128
post #85
post #65

Earlier quoted context omitted.

C# has a uphill battle against those that don't believe in systems programming languages with GC, despite several graphical workstations have been done in the past in such languages. Unfortunately freebie UNIX, and security was yet decades away to be relevant to governmental regulators, thus they never managed to gain enough mindshare to keep going. Additionally even with all the .NET team efforts, the technology rem…

GC still has the downside of higher memory overhead. While I’m not particularly a fan of Swift, this is a relevant argument for a general-purpose browser implementation.

The degree to which GC issues in the context of deterministic memory management apply to C# is incomparably lower to pretty much every other language that offers GC (especially JVM family) or a similar automatic memory management capability (except Swift or D).

However, D's GC is very rudimentary, and Swift pays very hefty performance price imposed by ARC for lower memory footprint and somewhat more predictable memory behavior.

In the context of writing something like a browser engine, both Swift and C# offer strong if different capabilities to control or avoid allocations, with Swift introducing Rust-like lifetime annotations for affine-like memory management, while C# relying on improving escape analysis in compiler and much better integration of plain structs and byreflike structs (they can hold GC-aware pointers called byrefs (`ref` keyword) to arbitrary memory) with generics for zero-cost abstractions.

Note that today, if I ever dared to even think about writing a browser engine, then the choice would have been Rust. But if not Rust, then C# would have been the next on the list. Some may suggest Zig but I have only brief knowledge of it so cannot comment further.

Re: Ladybird browser to start using Swift language this fall

#129
post #94

Earlier quoted context omitted.

"They" as a gender neutral singular pronoun has never been bad grammar, and has been accepted in common use for many hundreds of years.

In casual use, yes. In formal writing, the broad switch to acceptance of singular "they" is only about 15 years old. Up until that point it's the sort of thing that would be flagged by an editor, or lose you marks in an English paper.

I'd be shocked if that were universal over that time, given that even formal language has undergone many changes in attitude. Over hundreds of years, I bet that in many times and places it has not considered it a problem, particularly given its use in the King James Bible.

Re: Ladybird browser to start using Swift language this fall

#130
post #7

============================== Andreas Kling @awesomekling · 44m My general thoughts on Rust: - Excellent for short-lived programs that transform input A to output B - Clunky for long-lived programs that maintain large complex object graphs - Really impressive ecosystem - Toxic community ==============================

I'd drop the "long-lived" and "short-lived" from the first two points. Rust is great for long lived programs, and is extremely clunky for managing any kind of object graph in general. The lifetime of the program has little to do with it, so I'm confused by those qualifiers. I've written plenty of Rust software that has run uninterrupted for years. I've seen way more people complaining about Rust evangelism and toxici…

"Managing any kind of object graph in general" is just a hard problem. It's what tracing GC was actually invented for! (And indeed, that is still the only one-size-fits-all solution.) It's not fair to blame Rust for surfacing the issues instead of just sweeping them under the rug and letting them blow up in production.
Post reply on HN