MurphyA/hacker-news huggingface dataset:
by apwell23 | 2025-10-04 17:09:17+00:00
> The easiest way is to actively work to make a high-profile project successful. This is more or less what you ought to be doing anyway, just as part of your ordinary job

this involves you getting a chance to work on it in the first place. why would you in particular be getting to work on those projects?

you have to first align yourself with VP and become their bitch. someone who they can trust. you should always follow prison strategy of finding the biggest bully in the yard and becoming their bitch. only then you get to even sniff work thats important. don't even think that you will be given important projects if you show off your technical acumen and skills. that strategy usually backfires and puts a target on your back both from ur peers and superiors who now see you as a threat.

just remember ppl who got into managment positions have no technical skills anymore and are highly insecure of that fact. they will murder you if they even have a little bit of inkling that you are someone who is technically proficient that can drive projects with little help.
by MobiusHorizons | 2025-10-04 17:09:26+00:00
For certain classes of dynamically typed languages the unit test serves the function that a compiler or linter would perform just by running the code on any input to ensure it can run at all. Basically since these checks are runtime instead of compile time, you have to run the code to get even basic syntactical checking. I think ruby, python and JavaScript all used to use unit tests in this way. These days static analysis tooling is much more advanced and can provide much of the same benefit without running the code, but I think this is where the idea of 100% line coverage comes from.

Strong typing certainly doesn’t remove the need for testing, but it does change what type of issues you test for. And for certain classes of boring code that just transform or move data, a single integration test can give you all the assurance you need.
by al_borland | 2025-10-04 17:09:29+00:00
Where I’m at, needless complexity is forced upon us. At the same time, we are constantly pushed to deliver new capabilities on timelines that are dictated to us, devoid of any grounding in reality. There is no room to even have the conversation about proper design or solving the right problems. It’s all about hitting arbitrary dates with “features” no one really cares about, while ignoring the foundation it all has to sit on.

The more loudly someone speaks up, the faster they are shown the door. As a result, most people keep their head down, pick their battles carefully, and try to keep their head above water so they can pay the rent.
by Earw0rm | 2025-10-04 17:10:27+00:00
They don't, as a rule, drink alcohol, which helps quite a bit for GI, breast and liver cancers.

Wear modest clothing, cover themselves up from the sun. Although that can lead to Vit D deficiency when they move to high latitude countries.

And they don't eat bacon, sausages, salami or other salt-cured pork products which are thought to promote some GI cancers due to the curing process forming nitrosamines.
by quietbritishjim | 2025-10-04 17:10:35+00:00
(Honest question from non Rustacean.)

How does the cancellation story differ between threads and async in Rust? Or vs async in other languages?

There's no inherent reason they should be different, but in my experience (in C++, Python, C#) cancellation is much better in async then simple threads and blocking calls. It's near impossible to have organised socket shutdown in many languages with blocking calls, assuming a standard read thread + write thread per socket. Often the only reliable way to interrupt a socket thread it's to close the socket, which may not be what you want, and in principle can leave you vulnerable to file handle reuse bugs.

Async cancellation is, depending on the language, somewhere between hard but achievable (already an improvement) and fabulous. With Trio [1] you even get the guarantee that non-compared socket operations are either completed or have no effect.

Did this work any better in Rust threads / blocking calls? My uneducated understanding is that things are actually worse in async than other languages because there's no way to catch and handle cancellations (unlike e.g. Python which uses exceptions for that).

I'm also guessing things are no better in Ada but very happy to hear about that too.
by john01dav | 2025-10-04 17:11:07+00:00
One possible factor is the proliferation of LLMs to write code for us. I noticed that a few versions after Jetbrains implemented LLM integration, the bugs in their products skyrocketed. Also, in my own job, it's often tempting to use LLMs where I really shouldn't, by which I mean where I can't easily check the code to ensure that it's fully and subtly correct. For example, if I'm working with an unfamiliar library I might ask an LLM what the incantation is to do something, and then check it by reading the docs of each thing that it references. I regularly find issues when doing so, but a different developer who didn't check these docs may miss this and ship a subtle bug.
by xbar | 2025-10-04 17:11:13+00:00
Personal accountability with consequences that make fraud unpalatable means setting a high bar on white collar crime.

If you are saying that twentysomething founders should not be held accountable for the mistakes of their "youth," then you might be inclined hold the investors personally accountable for funding them--similar to parents being liable for their teenagers' driving mishaps.

I am disinclined to believe that Javice and his ilk are very much corrected by the Department of Corrections or later life experiences.
by vacuity | 2025-10-04 17:11:27+00:00
Linux's use of pointer-heavy datastructures is largely justified even today. The low-level kernel bookkeeping requirements rule out many typical suggestions. Modern hardware suggests certain patterns in broad strokes, which are sound for mostly any software. But the kernel has the unique role of multiplexing the hardware, instead of just running on the hardware. It is less concerned with, e.g., how to crunch numbers quickly than it is with how to facilitate other software crunching numbers quickly. As someone else noted elsewhere in the top-level thread, unsafe Rust is the appropriate compromise for things that must be done but aren't suitable for safe Rust. Unsafe Rust is one of the best realizations of engineering tradeoffs that I've seen, and neither C nor safe Rust justify its absence. Rust is only a "systems" language with unsafe, and that doesn't drag Rust down but rather strengthens it. "Here is the ugliness of the world, and I will not shy from it."
by therobots927 | 2025-10-04 17:12:28+00:00
The slide into hell is steep and slippery. I’m afraid we’re in a dark period of history that’s only going to get darker.

I want proponents of this tech to explain something to me. Why has the rate of stochastic terrorism only increased since the NSA and Palantir started spying on all of us? Isn’t the whole point of this to preempt those kinds of things?
by kcplate | 2025-10-04 17:12:41+00:00
All of it is subjective of course, and I will admit that once upon a time I was a tinkerer to try and find the perfect DE and UI for me. However, about 15 years ago I just got tired of that pursuit and just decided what MacOS gave me out of the box was fine. Now only tweaked by Rectangle just to handle window tiling a bit better.

What I discovered is that all of the effort I spent trying to get to that place of “productivity” I lost so much time that the juice wasn’t worth the squeeze. Not to mention the amount of time needed just to replace a machine to get it “usable”. My efforts towards that productive utopia made me not productive.

Hats off though to anyone who actually gets there and gets a measurable net benefit for their efforts. But for those still in that pursuit, I’d recommend trying to just go out of the box for awhile. It can be liberating and you might find those annoyances you are fixated on in your current out of the box OS, might become less important if you just dive in.
by elevatortrim | 2025-10-04 17:12:50+00:00
What you say about "extroverted" is interesting, because I do not see myself as an introvert. Once I am familiar with the people around, I am social bee, very chatty, energised by speaking with others etc. I crave social relationships but I can't find or start them.

My wife is exact opposite. She is an introvert who does not have a problem with approaching people. Relationships drain her energy, she can't chat to even a close friend for more than a couple of hours, but approaching a complete stranger when necessary or she wants to? That's not a problem for her at all, she just does not usually want it, and she loves her alone times.
by TuringTest | 2025-10-04 17:13:30+00:00
It took several environment-changing events to get our unique kind of intelligence; mammals had to thrive in place of saurs; and then, Africa needed to be split by the Rift and to create the dry savannah.

This forced some apes to climb down the trees and depend on a diet of scavenging for meat, which happened to both increase brain size AND require improved intellect to survive, forcing the evolution of our hypertrophied symbolic brain.

Had this not happened however, other intelligent species could have filled the niche. There's no shortage of other intelligent species in our planet, not just other mammals but octopus and some birds. And then you get hive intelligence, which could equally be forced to evolve into a high problem-solving organism.
by epage | 2025-10-04 17:13:58+00:00
> You only build the world occasionally

Unless a shared dependency gets updated, RUSTFLAGS changes, a different feature gets activated in a shared dependency, etc.

If Cargo had something like binary packages, it means they would be opaque to the rest of your project, making them less sensitive to change. Its also hard to share builds between projects because of the sensitivity to differences.
by Earw0rm | 2025-10-04 17:14:21+00:00
Which is in itself odd, as there's no obvious mechanism (at least in a developed nation inhabitant who typically have considerable fat reserves and ready availability of food) for the immune system to need resources which would be otherwise used by the muscles.

Like we can all feel the lack of "energy", but that energy isn't the same thing as actual calories, glycogen, blood O2 and so on. Presumably a lot of CFS conditions are relating to that biological switch - "you're ill, rest up!" - getting stuck in the "on" position, but AFAIK nobody has definitively found it despite a whole lot of looking.
by BearOso | 2025-10-04 17:14:30+00:00
> It’s not that baseball got lazy. It got layered, commercialized, optimized, and strategized, but it forgot about time management.

This is why I can't stand modern basketball. Deliberate fouling in the last quarter is optimal and strategic as far as winning. I'm sure those extra commercial slots are enticing to the networks as well. But it's boring as hell when the last 5 minutes stretch out to an hour, and the final result now boils down to a lucky draw instead of skill. Any sense of fun has been lost.
by RHSeeger | 2025-10-04 17:14:31+00:00
I tend to approach it a similar way...

- If we do it <this way>, will <this requirement> be impossible to implement (without a huge rewrite cost) later? If so then, if <this requirement> is a realistic possibility, consider <this way> is probably a poor choice

- If we do it <this way>, will <this requirement> be harder to implement, but not terribly so? If so, then weigh the cost/probability of doing it and it not being needed vs not doing it and it being needed

- If we do it <this way>, will <this requirement> not be any more cost to add then if we did it now? If so, then don't do it now. Because you're risking unneeded time for no benefit

Admittedly, all three of those are the same "equation", just the three ranges of where the numbers stand. But it's nice to specifically ask the first and third questions... because they can cut short the analysis.
by Qem | 2025-10-04 17:14:50+00:00
Maybe they didn't produce an intelligent species just because they had not the luck of living in the unprecended time in the history of Earth with both high atmospheric O2 and very low atmospheric CO2 we enjoyed for a while, before we started to burn fossil fuels by the gigaton. See https://www.qeios.com/read/IKNUZU
by kzrdude | 2025-10-04 17:14:55+00:00
I think it's good that people give advice. I need people to be explicit and not leave things unsaid. Better be upfront. I have needed this advice. Of course it takes luck for it to land, when you need it, but I have needed it. Quitting caffeine definitely did wonders for me (and 2 years after I ramped it up very carefully).
by palata | 2025-10-04 17:14:59+00:00
I am amazed by the number of articles like this, that essentially say "you should not write bad code, you should write good code", while somehow implying "listen to me, I know better" (otherwise I wouldn't write the article...).

The truth is that writing good code takes experience. Those who live by the rule "thou shalt not over-engineer" risk writing bad code. Those who live by the rule "thou shalt know all the patterns and use them" risk writing bad code.

You should strive to write code that others can understand and maintain, period. If you need to justify your lack of "something" ("It's not a hack because..." or "I don't use OOP because..." or "I duplicated this code because..."), then it feels like it says something about your opinion of your own code, IMHO.
by adverbly | 2025-10-04 17:15:11+00:00
Yes I wasn't specific enough and contradicted myself.

I said anyone can be a cost cutter, and that includes engineers.

Where engineers are unique is in their ability and training to be efficiency and value creators. They are productivity increasers.

Their value comes from productivity increases - not their ability to cut budgets. Cutting a budget might be a side effect of a productivity increase, but the profitability increases that finance first leaders push for is often at the expense of long term productivity rather than because of it.

Hope that makes more sense!
by Aurornis | 2025-10-04 17:15:20+00:00
> - Have someone in management or a PM who is good at selling your wins

Looking back on my career, one of the single biggest changes I could have made to improve my success was escaping teams with bad PMs as fast as possible.

Great PMs improve everything, but they're hard to find. I spent too much time sticking around on teams where bad PMs were driving us in the wrong direction and failing to interface effectively with the rest of the management team. As soon as something changed that removed those PMs from the situation, everything improved.
by estimator7292 | 2025-10-04 17:15:28+00:00
You must not have actually experienced computing in the past.

In the dark, distant past, we wrote programs that ran in kilobytes of memory on a double-digit-MHz CPU. Multiple cores or threads did not exist.

Today, the same program requires gigabytes of RAM and takes multiple seconds to do the same work with 32 4GHz CPUs.

This is truly not an exaggeration. Everyone who actually handled a Windows 95 machine in its natural environment will tell you that the experience of using a computer today is ten times slower and forty times more frustrating. Computers are slower than they ever have been, despite having hardware that is fast beyond the limits of anything we even dared to dream of in the 90s.
by magicalhippo | 2025-10-04 17:15:47+00:00
True, though at least here that'll be older stuff, and seems almost exclusively Intel parts.

I found a used server with 768 GB DDR4 and dual Intel Gold 6248 CPUs for $4200 including 25% VAT.

That's a complete 2U server, the CPUs are a bit weak but not too bad all in all.
by akkartik | 2025-10-04 17:15:49+00:00
Human beings are ephemeral. They're born, they die.

Everything human beings create is ephemeral. That restaurant you love will gradually drop standards and decay. That inspiring startup will take new sources of funding and chase new customers and leave you behind, on its own trajectory of eventual oblivion.

When I frame things this way, I conclude that it's not that "software quality" is collapsing, but the quality of specific programs and companies. Success breeds failure. Apple is almost 50 years old. Seems fair to stipulate that some entropy has entered it. Pressure is increasing for some creative destruction. Whose job is it to figure out what should replace your Apple Calculator or Spotify? I'll put it to you that it's your job, along with everyone else's. If a program doesn't work, go find a better program. Create one. Share what works better. Vote with your attention and your dollars and your actual votes for more accountability for big companies. And expect every team, org, company, country to decay in its own time.

Shameless plug: https://akkartik.name/freewheeling-apps
by whartung | 2025-10-04 17:16:20+00:00
Anytime the inning ends, or the pitcher changes, there's a 2 minute pause. Save for the mid-7th inning, when it jumps to 3 minutes. I believe they are longer during the All Star Game, and, maybe, the WS. I didn't notice them longer during the recent Wild Card.

They typically jump to commercial on every break. I watch all my games on delay, and for local broadcasts, it's 3 clicks on the skip button (1.5m) and we're back in the ball park. On national broadcasts, it's 4 clicks and we typically return with the ball in flight or the batter swinging at the first pitch. They cut it really close.

During things like mound visits, they'll slip in an interstitial ad, that's about 10s. There's also voice over ads from the announcers during short pauses (between batters, say), which is almost always team related vs a sponsor, but not as bad as on the radio. On the radio its "First pitch brought to you by...", things like that.

My nits on advertising are the shoulder patches for the players and the stencil on the mound. I particularly hate when a national broadcast layers in something over the batters eye, the locals do not do that. Last year, the Umpires were carrying sponsor patches (some crypto company), I honestly can't recall if they were wearing anything this year. The rotating banners in the back that are in park or green screens overlayed by broadcast behind the plate don't really bother me. I always find it amusing when they turn almost entirely Japanese when the Dodgers are playing.

The pitch clock and shift changes have been great, I love the game. Yankee/Red Sox series last week was a nailbiter. Being at the the local park when the Yankees are in town is a blast.
by valdezm | 2025-10-04 17:16:36+00:00
Location: San Francisco, CA

Remote: Yes

Willing to relocate: No, staying in Bay Area

Technologies: 15 years full stack - react and ruby -- but very broad bleeding edge. Build 0-1 products with Founders for 10+ years. Built geosite.io first year beta/foundation before entering Y-Combinator in 2019. Building AI in 2025 - competed and won Hacking Agents Hackathon put on by Datastax (Langflow) at Cloudflare in March 1st 2025. Spent the last 4 months building an POC AI marketplace, https://goodbruce.com Open to contract roles @ http://sharedfounders.com/ Open to FTE Founding Engineering roles

Résumé/CV: https://valdezm.com https://www.linkedin.com/in/markavaldez/

Email: hello@valdezm.com
by razoorka | 2025-10-04 17:16:37+00:00
Ok, I agree with most what you are saying, but most part of those issues can be find with a proper testing. For instance, Steve Jobs Apple era is much more focused on quality and attention to detail. Under Tim Cook, Apple shifted from “it just works” to “ship fast, fix in updates.”

The difference isn’t complexity it’s priorities. Jobs-era Apple had smaller teams building fewer products with obsessive quality standards. Cook-era Apple has massive teams shipping constantly with “good enough” as the bar.

You’re right that testing helps. But when quality becomes optional, no amount of testing infrastructure fixes the cultural problem. We test for “does it work?” not “is it excellent?”

These issues passed all automated tests. They just didn’t pass the “would we be embarrassed to ship this?” test. That test doesn’t exist anymore at scale.
by john01dav | 2025-10-04 17:16:45+00:00
The people who decide platform support for major apps are usually business people, not developers. Businesses want control, which is toxic to the user. So, the only way for a new OS to get enough software support to get off the ground is to take away even more control and allow more abuses by app owners. If an OS has no user base and has pro user anti app owner security design, then very few app owners will provide apps. This problem applies both to android forks and novel systems.
by tialaramex | 2025-10-04 17:16:54+00:00
I wonder where the cut-off is where a work stealing scheduler like Tokio's is noticeably faster than just making a bunch of threads to do work, and then where the hard cut-off is that making threads will cause serious problems rather than just being slower because we don't steal.

It might be quite small, as I found for Maps (if we're putting 5 things in the map then we can just do the very dumbest thing which I call `VecMap` and that's fine, but if it's 25 things the VecMap is a little worse than any actual hash table, and if it's 100 things the VecMap is laughably terrible) but it might be quite large, even say 10x number of cores might be just fine without stealing.
by a022311 | 2025-10-04 17:17:32+00:00
> I for one love terrible out of the box experiences and have to magically know what extensions are good and will solve whatever problems I have with the DE.

The first day you got your Mac, did you know what apps to install or where you can get them from? Did you know how to customize your desktop or set a screensaver? macOS is becoming less and less intuitive with every update.

No matter what you do, using Linux with any DE requires this to some extent. I didn't know about these things either when I started using GNOME.

> It's so freeing to spend all my time hunting down extensions and and keeping them updated or magically have them break when the DE updates.

Extensions are automatically updated once a new version is released. Finding them is as easy as finding apps in any app or extension store and the same goes for KDE.

Actively maintained extensions have no issues with breaking updates and there's always the option of delaying a GNOME upgrade until things stabilize. Apps like Extension Manager let you know about compatibility issues before upgrading.

> Even better is when all these extensions aren't handled by the distros' package manager!

Your distro's package repositories have no obligation to support installing extensions for your DE. Do you only install Microsoft Store apps?