Live data from Hacker News

Verso – Web browser built on top of the Servo web engine

github.com

191–200 of 343 posts

Re: Verso – Web browser built on top of the Servo web engine

#191

Earlier quoted context omitted.

Rust can absolutely crash. It crashes ("panics" in Rust terminology) in a memory safe way but it's still a crash (please don't try to redefine the word "crash" to be more specific than it actually is). And Rust can still have unsafe code so it can crash in memory unsafe ways too (though it is very unlikely unless you're doing things very wrong).

> And Rust can still have unsafe code so it can crash in memory unsafe ways too (though it is very unlikely unless you're doing things very wrong). From when I grokked the code a bit (back in 2017) there was a non trivial amount of unsafe code, especially related to integration with SpiderMonkey (the js engine) so it wouldn't even be particularly surprising to see segfaults in servo, unlike most rust projects.

Most crashes I've seen trying this out seem to stem from panics. As an end user I would call that a crash, but from a programmer standpoint you could say it's an unexpected normal shutdown.

Re: Verso – Web browser built on top of the Servo web engine

#192
post #180
post #174

Earlier quoted context omitted.

Okay, so you're saying you don't know what Swift Concurrency is and they say Swift is a failure. Swift has async/await built into the language with many compile time guarantees of thread safety.

> Okay, so you're saying you don't know what Swift Concurrency I just looked it up. It is Swift's version of async/await. That is a different thing from threads. I know what that is, used it a lot, because using threads was such a nightmare in Swift. > language with many compile time guarantees of thread safety From two separate threads you can access the same memory. No trouble (apart from crashes memory corruption.…

> Whatever, async/await is no replacement for parallel programming with threads.

Is it not for the vast majority of use-cases?

Sure, you can use async/await without parallelism, via a single-threaded runtime to just get single-threaded concurrency, but with a multi-threaded worker-pool async/await-like tasks or fibers I think mostly cover the use-cases you'd have for parallelism?

You have to make sure that you e.g. don't starve other tasks via having no yield points in a task that does a lot of computation (if you're doing cooperative tasks which Swift is doing iirc), but that's not a big one, and can mostly be solved by the runtime too (e.g. Go had cooperative fibers for a long time, until they chose to introduce preemption).

Re: Verso – Web browser built on top of the Servo web engine

#193
post #2

According to https://servo.org/about/ Servo currently passes ~60% of the web platform tests. Does anyone have experience how far that subset gets you on the open internet?

If it's anything like learning Japanese, it gets you approximately nowhere.

Re: Verso – Web browser built on top of the Servo web engine

#194

Earlier quoted context omitted.

Scoop is the main package manager I've been using for years on windows apart from chocolatey. Dunno many others aside from the official windows one: winget.

I've been using Windows as dev platform since it was called "DOS but don't look too closely", I know chocolatey, ninite, winget, and powershell's own built-in nonsense, and yet had never head of scoop until just now. So... that really just tells us that any application manager we think is popular, ubiquitous, and the obvious choice is still really just a niche program =( Contrast that to brew on MacOS: ever non-devs…

And from all of those, which I'd heard of, I think scoop is the only one to allow a package author to just create a git repo, and publish a package that way.

Like brew does. That why I use scoop.

Chocolatey would rather charge money for that, for some reason, and people are still willing to donate them their free time.

Re: Verso – Web browser built on top of the Servo web engine

#195
post #67
post #57

Have a read about Servo, it is binding with SpiderMonkey as JS engine. Is there some chance, that servo decomposed from SpiderMonkey? If it is not, I don't think anyone can tell difference between firefox and other browser use Servo.

There's a lot more to a browser than the JS engine. And in general, we would want all of the browsers JS engines to be essentially the same. I think starting with an existing engine is the most logical approach

They plan to abstract it (work is underway) to make it even possible to use chromium's js engine. https://www.phoronix.com/news/Servo-JavaScript-Engine-Modula...

Re: Verso – Web browser built on top of the Servo web engine

#196
post #170

Earlier quoted context omitted.

A chromium fork is not chrome. Why assume a fork has to accept upsteam changes?

why fork chrome rather than another browser, or starting from scratch?

Less work, more features, proven, security lindy

Re: Verso – Web browser built on top of the Servo web engine

#197
post #5

So we will, in ~5 years time have two new browser, one in Rust and one in Swift. I hope in the process of doing it we will find new ways of doing things.

I'd like to see Swift adopted more on non-Apple operating systems, some of the recent GTK apps written in Swift are pretty cool.

I'd really rather not, personally. All my Swift experiences have been fighting the abysmal compilation times.

Re: Verso – Web browser built on top of the Servo web engine

#198
post #170

Earlier quoted context omitted.

why fork chrome rather than another browser, or starting from scratch?

Because it's infinitely less work than starting from scratch. It's a valid argument.

infinitely doesn't mean what you think it means

Re: Verso – Web browser built on top of the Servo web engine

#200

Earlier quoted context omitted.

I somewhat wonder—Firefox and Chrome are in a constant race to have the best JavaScript performance. In general, the sites I want to browse use minimal JavaScript, prudently, if at all, just where it is strictly necessary to add little dynamic features. So, I don’t really care about JavaScript performance at all. Optimization sometimes introduces additional complexity, which might open up the possibility of security…

> wonder if there’s room for a browser engine that ditches performance and just focuses on correctness and safety Isn't this just the noscript, which breaks most sites to a degree where they're impossible to use or load?

That arguably ignores correctness completely
Post reply on HN