It’s immutable npm, you can’t unpublish I believe but yeah it’s trick of allowing one to publish typescript packages rather than compiled js only applies to deno.
There may be use-cases (and the RFC allows ignoring the SHOULD clause with enough reasoning), but GET does not have a request body as per specification, and a LOT of things drop it because of that (most notably - nginx! Also applies to HAProxy and Apache HTTP server afaik, but also a bunch of load balancers)
Setting aside the fact that using Rust for a JIT won't help that much - a new JS engine is a huge undertaking, especially if the goal is to compete with V8. They could eventually switch to Boa[1] if they wanted more safety, but it's still ways off and doesn't seem necessary enough just yet
Also, isn't the goal of Servo to effectively compete with CEF first and foremost? Because you don't need memory safety for that really
> we should be taking a more “batteries included” approach to language and library design.
Okay, but how do we decide which approach to a problem should be standardised?
Rust's approach of "provide a minimal core to build libraries on top of" provides a fairly significant benefit - flexibility.
A prominent example is async: Rust has three fairly prominent async runtimes (being Tokio for general server-side use, smol for a simple non-work-stealing approach and embassy for embedded). Which one do you make the default? Tokio is very complex and work-stealing is arguably a very bad default in terms of development complexity. smol doesn't fit some workloads because of a simpler execution model. Embassy is way lower level and much more constrained than most applications need. Standardising over one implementation instead of the current (even if still messy due to early portability woes) standardisation around traits and general async semantics would make switching runtimes more problematic, even though the general case is solved with the same approach as Python's
Database access is also a complicated topic. Rust has multiple fairly popular DB libraries. The first two that come to mind are SQLx and Diesel. Both are too complex to be a part of the standard library, both required a fair bit of breaking changes, and if you wanted a raw core to build on top of - you can't really build SQLx on the type of core e.g. Go's database/sql has, you'd be basically forced to implement it all from scratch to handle the compile time type checks anyway
RNG sounds simple, except there are good reasons behind both rand and fastrand existing, and behind rand not being stabilised at 1.0.
DateTime handling is notoriously complicated, has multiple competing implementations (chrono, time, jiff) with various trade offs
Where do you draw the line? What do you standardise and which implementation do you standardise against?
I've seen golang exemplified a lot in adjacent threads, but golang's standard library both has fairly significant issues (json, no set type, very limited CLI flag parsing, UUID took until 1.28) and is standardised around a relatively specific goal (unix server usage)
Dunno, I'm not entirely sold on the whole "extend the standard library" idea for a language meant to run both high level applications and embedded stuff. If anything, recommending blessed.rs more is a better way IMO
I wouldn't really say DeltaDB is a showcase project, given Zed has been working on it for at least a year, so it's likely been a focal point of development for quite some time. If there is funding to secure, they either should've been louder on the initial announcement, or not thrown a year on this, right?
I missed that the announcement was actually from two months ago.
It will be interesting to see how they handle balancing both an editor and a VCS without Big Tech resources like Microsoft's. Considering how many contributions and years it took for Git to reach its current level of maturity, taking on both projects seems like a massive undertaking.
Lem can also render via ncurses, which works fairly fine if you don't need mouse support. It used to also have an SDL2 frontend, but it was deprecated for reasons I don't remember
The compatibility layer mention is valid for many projects, and I personally greatly appreciate that it exists, even if it's a bit buggy
osu! however, is only officially distributed on Linux via AppImage (and semi-officially via Flatpak) and bundles its own SDL for the reasons that, to my knowledge, range from the general pinning to a known stable version approach to the team backporting functionality from SDL3 to SDL2 (last one I remember is non-text-based clipboard functionality, not entirely sure though)
osu! has spent a lot of time trying to switch from SDL2 to SDL3, but due to their high platform coverage (all three major desktop OSes + iOS and Android) and an attempt to keep all functionality native (so properly working Wayland supporr, along with other things) delayed the switch by around 2 years total. For the first time, the current switch seems actually final
That's mostly because BEAM uses an actor-style approach while predating the concept of actors, isn't it? Interesting artefact of history if so
Edit: upon rechecking, apparently that's not exactly right, and Erlang designers learned of actors after designing the language, which makes it all the more interesting
I've spent the last decade in erlang / elixir / OTP. I think a lot of the naming comes from the early use of erlang as effectively an "OS" for telecom switches.
I always joke that BEAM wants to be the operating system.
Unsafe code can break certain invariants of Rust, as `unsafe` is just a compiler "hold my beer" flag, which is why you're meant to do safety checks in your safe interface around unsafe code. If the unsafe code is wrapped in a way that does no guarding (or does something stupid in general), it is technically marked safe (because you said "rustc, hold my beer" as `unsafe` is also a contract) despite actually being unsafe
reply