Ladybird isn't promising for a few reasons, like the poor choice of language, and the fact that it's developed by fascists.
Also, Ladybird did not start in 2024. That's when Kling left the SerenityOS project to focus only on Ladybird. Ladybird as a browser started in 2022, but LibWeb, the actual web engine, started in 2019.
Things get funnier once you learn one of the first real (not compatibility benchmark) websites to be tested during development (as you can see on Andreas' old videos) was 4-freaking-chan.
While on the purely technical side, yes, it is really simple as far as modern websites go, it was a warning of the future I sadly took too long to understand.
There is a section titled "Is it really a new web engine" in the article itself
In any case we cannot consider it really “new”, but Servo is way younger than other web engines that started decades before.
In 2023, Igalia took over Servo project maintenance, with the main goal to bring the project back to life after a couple of years with minimal activity.
A highlight is that the project community has been totally renewed and Servo’s activity these days is growing and growing.
Even with this valid criticism GraphQL is years ahead of OpenAPI with everything having to do with type safety (I challenge you to write a compex OpenAPI Nest.js project with valid scheme). GraphQL comes with great tooling for consuming types, schema governance and documentation while offering a unique consumer side safety and ergonomics with fragments. Although it’s far from perfect I think it’s the best we got so far and future protocols should start from learning and adopting GraphQLs philosophy
Swagger typedefs are a nightmare, if only for the way that it intermixes details of an object property in with details of the type of that property. It's way too complicated in some areas, and not descriptive enough in others, the official spec simply leaves out about half of the most important details as "basically like JSON schema" another, even more overcomplicated system.
I haven't used OpenAPI that much, so I can't really say that with confidence, but this has been my feeling as well. I agree with you that, type-wise, this is much easier to work with, which I try to convey at the end. I don't want us to stop at GraphQL though.
Definitely agree with you on OpenAPI. I've observed my team and an adjacent team rework their implementations to fit schemas that could be expressed. The result was clunky, confusing, and consistently delayed tasks. One of the key issues was, if I recall, sum types.
I also feel that protobuf ought to get a mention too, especially for GRPC APIs. Protobuf felt more rigid and trustworthy (to review and rely upon over time) as an IDL, while GraphQL was more fun and flexible. GraphQL's interactive tools (hardly any useful tools exist for GRPC) are so ergonomic that I would not hesitate to recommend it for client to server APIs.
The OpenAPI specification allows using JSON Schema to describe types with quite sophisticated types. It's really up to the codegen implementation to translate that into something appropriate for the type system of the target language. If anything, it's probably a bit too powerful for most implementations to cover all the edge cases that can be specified.
In terms of schema governance and documentation it's not that difficult to upload the schema and its documentation page (kinda trivial with Swagger/Rapidoc/etc.) alongside the API itself.
Particularly if you what you want is “garbage collected Rust that’s not Go”, OCaml is a good choice.
Rust and Go fits different purposes. And why should OCaml be chosen over Go? The main point of using Go is to get amazingly short compilation and test cycles, even for large projects.
the OCaml compiler is also fairly fast, particularly compared to the Rust compiler.
The bytecode compiler is much faster than the native code compiler though. To the point where in some cases I found myself using the bytecode compiler because compilation times were dominating my otherwise short test cycle.
nulls is not a common type error in Go. I understand that it may look that way from a syntax perspective, but in practice, and from a deployment/security perspective, I don't believe that this is the case.
I wish there was statistics available on this for Go.
While not a direct answer to your question, some of the concerns raised in this paper make me want to believe that you are much more likely to shoot yourself in the foot in Go, security and deployment wise.
OCaml compilation and test cycles are not appreciably different from Go's during development. I've used both. OCaml gives me much better type safety. In Go what I'm always wary of is the default emptiness of values which aren't initialized for whatever reason. E.g. if I have a struct type and add a new field, the compiler doesn't help me refactor my code in all places which work with this struct to ensure that the new field is handled. In OCaml it does.
I think the author agrees here : Rust and garbage collected Rust fit different purposes.
That's very subjective so probably not exactly what the author has in mind, but what I imagine a garbage collected Rust could be is a language whose design would de-emphasize performance a bit in favor of ease of use. So no lifetimes, no multiple variants of string, but the type safety story. And I imagine the performance would be in the same ballpark as Go, hence the mention.
Yes and no. Python's type system affects runtime in the sense that you can analyse it on runtime while TypeScript's is build only and removed at build time. But both serve the same core goal of adding stricter typing to dynamic languages (Python and JavaScript) and they learn a lot from each other.
No. Assuming we're talking about mypy (Python doesn't have a blessed type system, but type annotations), then mypy by default is nominally typed rather than Typescript's structural typing (though Mypy has support for protocols, which look like structural typing)
Ultimately Python's object model is very different from Javascripts due to descriptors, so it makes stuff like Django models hard to model. On top of that, mypy doesn't have some extremely useful type system utilities like declared type guards and type intersections.
In my experience, mypy often feels like its approaching what many have experienced in OOP languages, whereas Typescript's structural typing + type level programming aims to go much further.
That being said both tools have similar onboarding strategies and work reasonably well with a typed/untyped code mix.
Actually, not programming a lot. I'm working in a YC startup and the focus rn is on growth so I'm mostly writing sales emails and other prose. Last week I used some of my code smarts to find leads and enrich their data (small scripts in the Developer Tools + Excel can take you really far).
I remember spending so much time installing different builds of Chromium OS and Android X86 on my netbook. This was the first time I encountered the terminal, BIOS, etc. I’m glad there’s an official solution if I would need to modernise an old computer of a friend
new? hasn't this existed for a ~decade now? It was essentially the reason rust was created?
Relative to their other browser engines (e.g WebKit, chromium) you can say it’s fairly new
One of the more promising contenders for browser engines, Ladybird, started in 2024. Flow also exists and I believe was also started after Servo.
Also more importantly, unlike Servo those both pass the Web Platform Tests at 90% which makes them an Apple approved browser engine in Europe for iOS.
Ladybird isn't promising for a few reasons, like the poor choice of language, and the fact that it's developed by fascists.
Also, Ladybird did not start in 2024. That's when Kling left the SerenityOS project to focus only on Ladybird. Ladybird as a browser started in 2022, but LibWeb, the actual web engine, started in 2019.
Things get funnier once you learn one of the first real (not compatibility benchmark) websites to be tested during development (as you can see on Andreas' old videos) was 4-freaking-chan.
While on the purely technical side, yes, it is really simple as far as modern websites go, it was a warning of the future I sadly took too long to understand.
I think browser engines are interesting out of principle because we don’t have enough competition.
And no, Kling is not a fascist.
There is a section titled "Is it really a new web engine" in the article itself
Until lots of people are using it it remains new for them.
One of the best videos I watched on evolving software.
This is amazing progress. I really love just how nicely written this is
I'm glad you like the writing! Thanks for the feedback.
Still waiting for the pipe operator for JS
I perfectly agree with all the arguments in the article. Awesome work and let’s hope more mainstream languages will comply with it
Even with this valid criticism GraphQL is years ahead of OpenAPI with everything having to do with type safety (I challenge you to write a compex OpenAPI Nest.js project with valid scheme). GraphQL comes with great tooling for consuming types, schema governance and documentation while offering a unique consumer side safety and ergonomics with fragments. Although it’s far from perfect I think it’s the best we got so far and future protocols should start from learning and adopting GraphQLs philosophy
Swagger typedefs are a nightmare, if only for the way that it intermixes details of an object property in with details of the type of that property. It's way too complicated in some areas, and not descriptive enough in others, the official spec simply leaves out about half of the most important details as "basically like JSON schema" another, even more overcomplicated system.
I haven't used OpenAPI that much, so I can't really say that with confidence, but this has been my feeling as well. I agree with you that, type-wise, this is much easier to work with, which I try to convey at the end. I don't want us to stop at GraphQL though.
Definitely agree with you on OpenAPI. I've observed my team and an adjacent team rework their implementations to fit schemas that could be expressed. The result was clunky, confusing, and consistently delayed tasks. One of the key issues was, if I recall, sum types.
I also feel that protobuf ought to get a mention too, especially for GRPC APIs. Protobuf felt more rigid and trustworthy (to review and rely upon over time) as an IDL, while GraphQL was more fun and flexible. GraphQL's interactive tools (hardly any useful tools exist for GRPC) are so ergonomic that I would not hesitate to recommend it for client to server APIs.
The OpenAPI specification allows using JSON Schema to describe types with quite sophisticated types. It's really up to the codegen implementation to translate that into something appropriate for the type system of the target language. If anything, it's probably a bit too powerful for most implementations to cover all the edge cases that can be specified.
In terms of schema governance and documentation it's not that difficult to upload the schema and its documentation page (kinda trivial with Swagger/Rapidoc/etc.) alongside the API itself.
Rust and Go fits different purposes. And why should OCaml be chosen over Go? The main point of using Go is to get amazingly short compilation and test cycles, even for large projects.
Rust and Go are similar in that they're some of the only memory-safe ahead-of-time compiled languages at our disposal.
The specific criteria that the author was using were these points:
OCaml can be picked over Go if point 2 is more important than point 8 for your software.
It's not discussed in the article, but the OCaml compiler is also fairly fast, particularly compared to the Rust compiler.
The bytecode compiler is much faster than the native code compiler though. To the point where in some cases I found myself using the bytecode compiler because compilation times were dominating my otherwise short test cycle.
With OCaml you get more safety and expressivity
I agree. But is there measurably more safety than in Go, though, from a deployment/security perspective?
Yes.
Golang's type system doesn't even attempt to prevent nulls, which are the most common type error by a wide margin. There is an enormous difference.
nulls is not a common type error in Go. I understand that it may look that way from a syntax perspective, but in practice, and from a deployment/security perspective, I don't believe that this is the case.
I wish there was statistics available on this for Go.
While not a direct answer to your question, some of the concerns raised in this paper make me want to believe that you are much more likely to shoot yourself in the foot in Go, security and deployment wise.
https://arxiv.org/pdf/2204.00764.pdf
I'm not sure that's the case. They seems pretty common to me and I've certainly encountered them in Go projects I've used.
OCaml compilation and test cycles are not appreciably different from Go's during development. I've used both. OCaml gives me much better type safety. In Go what I'm always wary of is the default emptiness of values which aren't initialized for whatever reason. E.g. if I have a struct type and add a new field, the compiler doesn't help me refactor my code in all places which work with this struct to ensure that the new field is handled. In OCaml it does.
I think the author agrees here : Rust and garbage collected Rust fit different purposes.
That's very subjective so probably not exactly what the author has in mind, but what I imagine a garbage collected Rust could be is a language whose design would de-emphasize performance a bit in favor of ease of use. So no lifetimes, no multiple variants of string, but the type safety story. And I imagine the performance would be in the same ballpark as Go, hence the mention.
Finishing the implementation of a new formula engine for React Spreadsheet which supports dependant formulas and ranges. https://github.com/iddan/react-spreadsheet/pull/248
Are the Python and TypeScript type systems similar?
Yes and no. Python's type system affects runtime in the sense that you can analyse it on runtime while TypeScript's is build only and removed at build time. But both serve the same core goal of adding stricter typing to dynamic languages (Python and JavaScript) and they learn a lot from each other.
No. Assuming we're talking about mypy (Python doesn't have a blessed type system, but type annotations), then mypy by default is nominally typed rather than Typescript's structural typing (though Mypy has support for protocols, which look like structural typing)
Ultimately Python's object model is very different from Javascripts due to descriptors, so it makes stuff like Django models hard to model. On top of that, mypy doesn't have some extremely useful type system utilities like declared type guards and type intersections.
In my experience, mypy often feels like its approaching what many have experienced in OOP languages, whereas Typescript's structural typing + type level programming aims to go much further.
That being said both tools have similar onboarding strategies and work reasonably well with a typed/untyped code mix.
Don't ES6 classes have descriptors (or at least getter / setters)?
And unless I'm misunderstanding what you mean, python does have
typing.TypeGuardWhen I was working on Cayley it was very missing. Standard iterators in Go will make any stream processing work much easier to go about.
Actually, not programming a lot. I'm working in a YC startup and the focus rn is on growth so I'm mostly writing sales emails and other prose. Last week I used some of my code smarts to find leads and enrich their data (small scripts in the Developer Tools + Excel can take you really far).
I remember spending so much time installing different builds of Chromium OS and Android X86 on my netbook. This was the first time I encountered the terminal, BIOS, etc. I’m glad there’s an official solution if I would need to modernise an old computer of a friend
[Comment removed by author]
Met some friends for speciality coffee and spent time with my family (It's the end of the weekend in Israel)