chiffaa

I wanted to give Laravel a spin to have PHP+Laravel under my belt for future. `laravel new` couldn't even initialize a project fully, which might be the first time I've seen a framework-specific setup tool fail this fast

Ah, fair enough, makes the whole situation a bit more lame

isn't that fairly irrelevant if Deno dies out? Does anything else use JSR?

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?

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

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

Google people were specifically talking about memory safety. Logic bugs happen. All of the issues in TFA are effectively logic bugs or POSIX stuff, which is a different category entirely that Rust never claimed to solve

Few things to note

1. uutils as a project started back in 2013 as a way to learn Rust, by no means by knowledgeable developers or in a mature language

2. uutils didn't even have a consideration to become a replacement of GNU Coreutils until.... roughly 2021, I think? 2021 is when they started running compliance/compatibility tests, anyway

3. The choice of licensing (made in 2013) effectively forbids them from looking at the original source