Recent submissions

Comment · 1 month ago
It's a decision they've made. Perfectly reasonable. If they did accept AI code, that's perfectly reasonable too. They just made their policy clear here..
Comment · 2 months ago
Three years ago I started with to work on a browser engine without too much knowledge on either Rust, nor (indepth) browser knowledge.

We are still far from where Servo or Ladybird are, but we are able to do a lot of neat things already: html5/css3 parsing works, we have a modular system that allows multiple backend renderers, sites are starting to look like sites instead of garbled text and we are in the process of implementing process isolation.

During this time, i tried to blog the experience, the planning and the things we've faced over time.

Happy to answer any questions!

Comment · 2 months ago
As one HN commenter once put it to us: "poc or gtfo"

So, here is the proof of concept: a browser engine for over 2 years in the making and we just got to the part where we connected a lot of moving parts into a single engine system. Rendered web pages are starting too look more and more like their intended view although we are still very far away to render everything as intended.

Our goal is to become yet another browser engine. Not the best, not the fastest, not the smallest. Just an alternative. We need more of them to keep the web open. We want our engine to be modular by design, meaning you are able to swap backend renderers, font systems, HTML/CSS parsers, render pipelines, and even the network stack if you want.

Right now, we are busy getting our process isolation system merged into our main engine so we can separate parts of the engine and confine them to the lowest possible security state.

On AI: yes, we do use and merge PR's generated by LLM's, provided all code is owned, understood, reviewed and tested. We are still formalizing this process, just like any other software project these days.

We are not as far as a Servo or Ladybird, and we don't pretend that we will ever reach that level, but we are hopeful considering that we never thought we would even come to this point. This also mean that we don't have all the organization, marketing, experience skills on building large software, so right now we are trying to get the word out for enthusiasts to join us and to make the project good enough to gain enough traction.

More information about the engine: https://gosub.io, and of course the GitHub repo: https://github.com/gosub-io/gosub-engine. You are always welcome to join us at the Zulip developer chat to say hi and ask questions.

Comment · 5 months ago
A solution for this in my opinion, is the same solution that everybody and their dog is afraid of taking their job: llms.

I'm not taking about "chatgpt, write me an android clone, make no mistakes". But large software projects do not have to be a solely large player game anymore. I think that with much and much less resources, there can be new alternative phone os'es either or not even based on android.

The biggest issue is market share and lock-in where this problem falls into. But this happens in every monopoly that exists. The technical barrier not a technical problem anymore, its now a political one.

Comment · 5 months ago
Why not? I think we are perfectly capable on generating a test and validation environment that we can use for correctness. Most likely llms could do this better than engineers with zero to none domain and language knowledge can do these days. From that point on, rewrites would become feasable (not easy, feasable).
Comment · 6 months ago
sorry :(
Comment · 6 months ago
That's a good insight. But how to distinguish from the rest? It seems that making a spectacle will give you points, while boring but great software will be buried. I don't mind when people are not spending all their time on looking at every bit of code that get posted, but i'm more sad by the part that people will comment anyway (negatively) nevertheless.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton