Hacker Newsnew | past | comments | ask | show | jobs | submit | abbadadda's commentslogin

In 2025 I was on a road-trip with my then girlfriend of a few months. Life was then, as it is now, a lot. I’ll spare the details, but at some point she asked “what’s the worst case scenario?” Calmly and casually I said, “Worst case scenario is I take my own life.” I was going to continue going, and was just matter of factly stating that suicide was a “ripcord” or last option. This apparently triggered her and she said, “if you feel that way I might was well jump out of the car right now.” I was pretty shocked to hear this, and perceived it as a general lack of support. And I felt ashamed for sharing this. But after unpacking things I learned her mother used to threaten self-harm as a matter of routine and her default response became to threaten to leave the situation, or something.

I’m not sure exactly why I share this, perhaps I think some comments about suicide being an “escape hatch” resonated with me. I’ve since sought support, going just short of self-hospitalization, and I was on a SSRI until recently switching to a non-antidepressant.

While life remains Messed Up, I keep telling myself two things: (1) If you’re really considering killing yourself, try “ killing yourself” in the gym (often super hard exercise makes me feel infinitely better); and (2) “Wouldn’t it make a better story if I didn’t (kill myself)?”

I’m getting through, day by day, and I’ve got some strong “protective factors,” however they’re not invincible or bulletproof so I need to remain vigilant and avoid doing anything impulsive. And just try to remember that if I keep making good decisions one day at a time things will get better in the long-run.


LOL, replace “Yoga” and “Wellness” with whatever relevant subject and OP could use the same text verbatim on almost any submission.

lol, I was actually talking about both.

Oof, this tracks with my experience on the NHS… it seems like extreme busyness comes off as a lack of due care.

One time I met a psychiatrist after moving to a new area. In our very first meeting he takes me off a medicine I’ve been on for nearly 7 years, cold turkey. Then? _Zero_ follow-up, no check-ins, and I can’t get an appointment on my own for months. The decision may have been wise, leaving out specifics here, but the lack of follow-up really was negligent.


> "Making" the pizza with a premade dough and pre-cut toppings is just a 1 minute operation to spread sauce and throw some toppings on it isn't it? Not much bonding there in my eyes.

I bet you’re fun at parties!


If you meant this ironically you would be spot on ;)


Are there any plans to more seriously develop the standard library in Rust? Or is the plan to remain in this status quo where users of Rust import nonsense and the dependency tree explodes (or users are forced to invent their own wheel?).

Are there any comparisons between the state of the stdlib in C++ vs. Rust? I’d think that would serve as an excellent jumping off point to start chipping away.


The idea that Rust has a small standard library is a weird meme. Rust has an enormous standard library. Look at any Rust release and you'll see dozens of new library APIs added, and consider that Rust has about nine releases a year, meaning that Rust adds over a hundred APIs per year, and has consistently for the past ten years. Rust frequently adds things that obviate popular crates, most recently the cfg_if crate was made redundant by the new cfg_select macro. And half of every dependency graph that people wrong their hands over are actually first-party external crates provided by either the Rust organization itself or by known contributors to the project. When people say that Rust has a small standard library, mostly they seem to just mean that it doesn't include a webserver.


It still lacks basic functionality like a JSON parser, regex, directory walker, rnd generator and cli arg parsing.

I won't mention lack of date/time lib because that's complex and changes often.

That's why projects end up with 100s of crates, sometimes 1000s.

This might not be a well received fact in Rust community, but it's a fact nonetheless.


JSON support is provided by serde_json, which is owned by dtolnay, a longtime member of the Rust standard library team. Regex is provided by the regex crate, owned by burntsushi, a longtime member of the Rust standard library team. Directory walking is provided by walkdir, also owned by burntsushi. RNG is provided by the rand crate, owned by the rust-random organization, also full of longtime Rust contributors. CLI argument parsing is provided by the clap crate, owned by epage, the lead developer of Cargo. These aren't randos, these are all de-facto first party libraries. You can trust these developers as much as you trust any random owner of any random Debian package.


Ok, so I created an empty cargo project and added serde_json, regex, walkdir and rand. This added 28 crates, several of these from the same authors.

If the absence of these features caused 1000s of dependencies, then where are the remaining 972?

When I look at a project at work then what inflates the dependency tree is a combination of a whole webserver application stack plus SDKs consisting of dozens of crates. Those then pull in an async runtime or two, different HTTP clients, dozens of crypto crates and so on.

The crate count is a poor metric anyway since some subtree of dependencies is often provided by a single organization.

And I find it quite questionable that everything that's needed for an enterprise grade webserver stack should be part of the standard library, not even Java has that. Relatedly, cryptographers have failed to come up with a proven set of primitives, what's standard changes every few years.


28 crates for 3 of the most common functionalities.

And it would have been 0 crates in .NET or Go. Even after adding a web server.


> 3 of the most common functionalities.

Four. Though you initially asked for five features, so let me add lexopt, which brings the number up to 29.

> That's why projects end up with 100s of crates, sometimes 1000s.

If your argument is "out of 1000s of dependencies 29 could be easily removed" then it does sound a lot less of a deceive change when it comes to supply chain security.

And even getting those 29 right is hard. For example people do want regular expressions with lookaround assertions, but most implementations suffer from runtime blowups (resulting in ReDoS attacks) and improving on that is a fairly recent research[0], so this is hardly a trivial and settled thing to implement. So often there's a tradeoff between choosing more powerful regular expressions and DoS-resistant ones, not one standard.

[0] https://systemf.epfl.ch/blog/re2-lookbehinds/


My personal opinion on each of those:

JSON: there are a ton of different ways to do serialization and deserialization, each with their own tradeoffs, and serde (the most popular) is far from universally agreed upon. The same goes for JSON specifically, there are many different serialization formats with different tradeoffs.

regex: Owned by the rust-lang organization already. You get the benefits of trust (if you trust std, you trust the rust-lang organization anyway), but without the issues of being in std (backwards compatibility and bloat). The only problem I see with that is that BurntSushi is still the owner of the package and as such can still publish new versions on his own (AFAIK crates.io currently requires at least one user owner, but that's something that can be solved by improving crates.io permissions).

walkdir: It has been been postponed, due to the complexity of WalkDir, but may be added in the future. I agree this should be in std. https://web.archive.org/web/20260820171531/https://github.co...

RNG: rand is still evolving, with breaking changes half a year ago. Preferred generators tend to change over time, so I don't see those getting into std (remember, it has to be maintained forever!). I could see the interface (traits) getting into std, but I see no advantage to it: it's maintained by rust-random, but even if you wanted it to be maintained by the same authors as the Rust language (let's say you trust them more than rust-random), you could just move it back to rust-lang-nursery or rust-lang.

CLI arg parsing: not simple at all! The community's preferred solution has 70kLOC (with support for so many features), but there's also argh, pico-args, and others, each with their own tradeoffs.

> That's why projects end up with 100s of crates, sometimes 1000s.

Also because libraries are split up in many crates. For example, regex is split in 3 crates: regex, regex-syntax and regex-automata, and depends on other crates from the same author, such as aho-corasick.

All that said, there are many crates, such as algorithms like aho-corasick, that I think could me moved into the rust-lang org, like regex was.

See also: https://home.expurple.me/posts/a-big-standard-library-is-ove...


On the topic of RNG, the functionality of the getrandom crate is getting ready to be exposed from libstd: https://github.com/rust-lang/rust/pull/157168


A big issue here is the complete lack of namespacing. You have these sub crates with zero ability to know whether they are related to a given organization/author/project.

I mean look at the people defending the lack of namespacing:

https://samsieber.tech/posts/2020/09/registry-structure-infl...

One of the most obvious problems with the lack of namespacing is that if you have a group of crates belonging together, you have to reserve them all at once otherwise an automated script could detect your package and add common suffixes like -sys and take the name even though you got the non sufficed name.

You cannot add name spacing by just prefixing everything with your preferred prefix, because anyone can publish under that prefix.


The standard library is not versioned, so any API*/behaviour there must be maintained forever. When you put it in a separate crate, you can make better interfaces or be displaced by a better crate, while old code still compiles against the version it was written for. So even code effectively maintained within rust teams (hashbrown, rand, regex) may be in separate crates, std is specifically for OS abstraction and a shared type vocabulary.

That doesn't mean you jump to importing nonsense or trivial dependencies. The top hundred are efficient, well-designed crates of the quality you'd expect in a large std like Go or Swift, sometimes even higher as people can write better implementations that they otherwise wouldn't (or wouldn't be used over std). And those languages make breaking changes! C++ is mostly stable, so it's full of junk like <regex> or just unordered_map. Rust managed to wholesale reimplement HashMap 6 months after SwissTable released, like it is also easier to express this level of encapsulation, but that's part of countless design/interface decisions made deliberately to not constrain forwards compatibility, including a smaller std.

However, that's no excuse to have a worse developer experience in this area. We need better tools to vet and communicate the quality of a crate and its supply-chain, like community-curated or even additional org-maintained crates, and maybe a handful delivered precompiled in the default rustup distribution which can change over time. I don't think they need to be added to std itself though


What purpose does “undeniable” serve here? This tips over into hyperbole, in my opinion, whereas “it’s foresight” is much simpler and stronger. YMMV.


I think it was to make the tongue-in-cheek nature of the comment more apparent.


That’s undeniable.



It is probably worth noting Drew very much does have his own brand as a co-founder of Defector.com. While not as popular as Levine’s money stuff, Defector.com survives on user subscriptions alone and a lot of URL requests are direct. Drew freelances for SFGate, and with that said I think he’s writing from the perspective of his “freelancer hat” and lamenting the impact “Google Zero” will have on websites around the world dependent on Google’s traffic.


I actually learned about what a ramjet is after looking up the definition of “scramjet” when watching the _Top Gun: Maverick_ movie with my son. This is at the beginning of the movie when he is flying the Dark Star plane designed in conjunction with Skunk Works from Lockheed Martin. Well, we are obviously a ways away from Mach 10 reached in the film by the SR-71 Blackbird descendant, the new technology pushing Mach 5 and into high hypersonic is pretty impressive.

> A scramjet is a variant of a ramjet airbreathing jet engine in which combustion takes place in supersonic airflow. As in ramjets, a scramjet relies on high vehicle speed to compress the incoming air forcefully before combustion, but whereas a ramjet decelerates the air to subsonic velocities before combustion using shock cones, a scramjet has no shock cone and slows the airflow using shockwaves produced by its ignition source in place of a shock cone - Wikipedia


As I understand, the problem with anything over Mach 4 (or 5), the metal begins to disintegrate. It is fine for a one way missile, but not a reusuable aircraft. Without some alien tech (see 1990s game "X-Com 2"), I cannot believe that we can build a reusuable aircraft that can reliably and safely fly for long periods over Mach 5.


Ramjets are limited in the speed they can operate because slowing the air to subsonic speed in the engine causes it to become hot, and the temperature increases rapidly with speed (the kinetic energy of an incoming air parcel is proportional to the square of the vehicle's speed, and most of that energy is being converted to heat.)


So am I not supposed to be typing “WHAT THE FUCK DID YOU DO???” in Slack to my colleagues?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: