What does HackerNews think of servo?

The Servo Browser Engine

#12 in Rust
If Rust is a must, surely contributing to Servo[1] and learning by sending small PRs to start with would be more beneficial.

However, I do understand as I've done this kind of "from scratch" project before just because I thought I could do it better or because I couldn't get into reading the existing codebase easily. To each their own...

[1] https://github.com/servo/servo

What I'd really like to see with CEF et al, is JS being dropped, in favor of directly controlling the DOM from the host language. Then we could, for example, write a Rust (or Kotlin, Zig, Haskell, etc) desktop application that simply directly manipulated the DOM, and had it rendered by a HTML+CSS layout engine. Folks could then write a React-like framework for that language (to help render & re-render the DOM in an elegant way).

Ultralight (https://ultralig.ht/) looks pretty cool. I think another possible option is Servo (https://github.com/servo/servo) – it was abandoned by Mozilla along with Rust during their layoffs a while back (but the project still seems to have a decent bit of activity). It would be great if some group of devs could revive the project, or a company could fund such a revival.

Eventually, we'll need to reflect on, and explore whether HTML+CSS is really the best way to do layout, and we could maybe perhaps consider porting the Android/iOS layout approach over to desktop. Maybe WPF/GTk/Qt/etc even got things right, and HTML+CSS isn't the best way to do layout.

It’s gonna depend on what kind of system you use and what kind of external things are needed.

It can be more involved, it can be less involved.

For example https://github.com/servo/servo seems a bit involved to set up for development but at the same time not too bad either.

The Servo Parallel Browser Engine Project

    Servo is a prototype web browser engine written in the Rust language. It is currently developed on 64-bit macOS, 64-bit Linux, 64-bit Windows, and Android.

    Servo welcomes contribution from everyone.
https://github.com/servo/servo
> Mozilla had a project called Servo which aimed at replacing just a small slither of Firefox and the project ran for years with a huge monetary investment and eventually was canceled.

Haven't some parts of it been integrated in Firefox?

The project does still seem to go on, although outside of Mozilla: https://github.com/servo/servo

note: IIRC Wikimedia had deprecated Bugzilla for bug reporting and replaced it by Phabricator.

> Github issues are nowhere near usable for a large product such as gecko/firefox

I have huge doubts about that. Looking at the development of Servo on github was beautiful, the colored tags, the PR views, the activity stats, the reviews diffs, the wikis, everything about it was much more readable than it is on Bugzilla/phabricator IMHO. https://github.com/servo/servo The same can be said currently about webrender.

About scale, github is battletested, for Example Rust is an example of a large scale repo with a LOT of activity (~has more weekly commits than gecko-dev) so the premise Github issues are nowhere near usable for a large product seems false. What idiosyncrasies could mozilla devs have that are immutable and that make them so much different from large projects developped on github? You specifically mention issues: Github can do meta-issues, can auto closes issues after PR merge, has bidirectional PR/issues references, can autoclose issues on markdown checklist check, etc etc and if you couldn't fit into existing github features, I'm pretty sure you could totally solve your issues with Actions such as https://github.com/marketplace/actions/dependent-issues Also github is accomodating, when the Apache foundation migrated to github they were open to do changes to the platform to facilitate Apache needs, cf: https://github.blog/2019-04-29-apache-joins-github-community...

In addition to my belief that github can be better or at least as good as buzilla, if gecko migrated to github, it would attract order of magnitudes more open source contributions because of the lower barrier to entry and to familiarity (also bugzilla is awful on smartphones) You really think you should seriously consider the migration.

Servo was never supposed to be a browser. It was a testbed for new browser tech/components, some of which got ported into Firefox. I had hopes that Servo would also be an embeddable browser engine, but not sure if that was ever a serious goal.

Servo still exists and has been spun out of Mozilla's org (https://github.com/servo/servo/). Certainly development will be slower without a dedicated, paid team behind it, but it's still alive (last merge to master was 9 days ago). And perhaps without Mozilla's direct control, it will actually end up becoming the browser you hoped it would be.

It's not. Just look at outstanding issues in Servo.

https://github.com/servo/servo

What Mozilla did was move few stable components to FireFox and shitcanned the rest.

Ok, we've changed to that URL from https://github.com/servo/servo. Thanks!

+title changed from "Servo Parallel Browser Engine Project"

I think the best course of action is to build elinks-like console interface on top of the Servo[1]. Just without the WebRender and optional JavaScript engine.

[1] https://github.com/servo/servo/

Not only is your understanding of history at odds with the facts, which anyone can look up for themselves, but I am extremely confused at why the ill-defined concept of “Servo as a whole browser” is important at all.

Servo is a browser engine, not some VR project (where the heck did you get that? Go to https://github.com/servo/servo ); what’s more, Firefox is “Servo as a whole browser,” whatever that is supposed to mean. Of course you are able to run Servo “by itself,” how the heck do you expect Servo developers to be able to test their browser engine?

I’m not sure what weird dramatization of history you are trying to create, but it’s all the more bizarre in that (1) this all happened in the open, so you should easily be able to see what you are saying is and was simply not the case, and in that (2) far from Servo being killed, it is the future of Firefox, so what on earth is there to be upset about? This has been surreal; good luck.

I agree with you that we do need to do better about writing more robust software, and type safe languages are a good way to do that.

But what you're saying is as if you suggest that since the metric system is more consistent and more widely used than the English, I as a bolt distributor should start selling my bolts in metric sizes, despite the fact that the nuts that everyone has are in English sizes.

The browser vendors, at least, are working on implement their browsers in more type-safe languages (https://github.com/servo/servo), but even still they have to work with the content that is produced by thousands of different languages, frameworks, and tools, and millions of hand written HTML files, templates, and the like. Just turning on strict XML parsing doesn't make that go away, it just makes your browser fail on most websites.

Some of my favorite examples:

https://os.phil-opp.com

https://github.com/helena-project/tock

https://www.redox-os.org

https://github.com/redox-os/tfs

https://github.com/intermezzOS/kernel

The biggest application example:

https://github.com/servo/servo

And some self promotion:

https://github.com/bluejekyll/trust-dns

----

I encourage all programmers to check it out. You may discover like me, that Rust is a compiler and language which guards against all the hard learned lessons I've had over my career. It's an amazing language to program in.

The problem is systems software is hard and takes awhile.

While HTML/CSS/JavaScript have historic oddities these only go back 15-20 years. x86/IBMPC legacy has 40years of horrible decisions burned into it.

To that end there is a lot of progress in the systems world, but core infrastructure isn't something you just rewrite/replace overnight.

* Redox is a full micro-kernel OS from scratch [1]

* Rustls is a TLSv1.3 compliant server [2]

* Ring is _mostly_ Rust (uses some C for where Rust doesn't work) [3]

* Subtle is consistent time library for building crypto libraries with [4]

* An entire webbrowser (well the JS is still C++) [5]

* A terminal emulator [6]

* A grep replacement [7]

* A non feature complete tar archiver that supports gzip, bzip2, xz, zstd, brotli, and lz4 [8]

The real challenge is Rust has been _released_ for 2 years now. C is approaching 50 years old. C/C++ has _a lot_ of momentum, history, and existent libraries.

[1] https://github.com/redox-os/redox

[2] https://github.com/ctz/rustls

[3] https://github.com/briansmith/ring

[4] https://github.com/isislovecruft/subtle

[5] https://github.com/servo/servo

[6] https://github.com/jwilm/alacritty

[7] https://github.com/BurntSushi/ripgrep

[8] https://github.com/valarauca/car

> You can write a system in any language right? Python is a scripting language and lots of people use it everyday to write systems.

Systems here means things like an operating system, a device driver, video games or a web browser, things that need fast execution, direct access to hardware and the ability to manually maintain memory. Stuff that C/C++ are normally used for.

Could you do it in Python? Not really, since Python has garbage collection, a very high-level of abstraction and is extremely slow for these kinds of tasks.

> What problems is it trying to solve?

It's trying to make it possible to write programs that require manual memory management, but that are checked for correctness of that manual memory management automatically, so that you can avoid many bugs that are related to memory and are commonplace in programs written in C/C++, like referring to a certain object that is in fact no longer present etc.

> Also how does it compare to Go? It seems to me that both Go and Rust are mainly used by C/C++ folks that want a new shiny language that somehow resemble the syntax or structure or funcionality of the former and at the same time add some modern features

Go is not really used by C/C++ programmers, as it does have a garbage collector, just like Python. Unlike Python however it is way faster and unlike Java, it is compiled to a native executable, thus it is used by many Python/Ruby/Java programmers who want a faster/native language with similar capabilities.

Go is mainly used for writing web applications and command line apps, just like Python.

> Do you feel more productive writing software in it than in let's say JS?

Rust targets a very different market from JS, but it has a very strong type system and catches a lot of errors at compile time, which to me makes it a lot more productive than JS is, just by not having things explode on me at runtime.

As for the syntax, it actually feels very neutral once you spend a couple of days with it and read the book + apart from the 'lifetime annotation there aren't really any other weird symbols for the category of language Rust is.

For example things like https://github.com/redox-os/redox or https://github.com/servo/servo would be very hard to write in both Python & Go, because they require direct access to hardware, fastest possible execution and manual memory management. They could've been written in C/C++, but would then contain many memory management errors, (given its manually done by the programmer and programmers are fallible humans), which could lead to crashes or serious security problems. Rust aims to prevent these drawbacks of C/C++, while still maintaining all of their benefits, i.e. speed, manual memory management etc.