MurphyA/hacker-news huggingface dataset:
by Alupis | 2025-07-24 16:54:34+00:00
> and are sure to disappear in 4 years

I wouldn't be so sure about that. The Biden Admin left in-place a lot of Trump foreign policy, and Democrats (the likely next admin-party) have been wishing for tariffs for years. Currently they're playing their part as the "opposition" but I'd bet money most of the tariffs stay during the next admin.

Your point about changing every 2 weeks is sound, however.
by chowells | 2025-07-24 16:54:47+00:00
I don't think it's true that Rust is safer, using the terminology from the article. Both languages prevent you from doing things that will result in safety violations unless you start mucking with unsafe internals.

Rust absolutely does make it easier to write high-performance threaded code correctly, though. If your system depends on high amounts of concurrent mutation, Rust definitely makes it easier to write correct code.

On the other hand, a system like STM in Haskell can make it easier to write complex concurrency logic correctly in Haskell than Rust, but it can have very bad performance overhead and needs to be treated with extreme suspicion in performance-sensitive code. It's a huge win for simple expression of complex concurrency, but you have to pay for it somewhere. It can be used in ways where that overhead is acceptable, but you absolutely need to be suspicious in a way that's never a concern in Rust.
by jjk166 | 2025-07-24 16:55:05+00:00
> It'll be fine in the short term, but in the long term it'll cost you more money. That's the primary reason why I don't think AI will catch on - its short termist thinking from people who don't understand what makes software complex to build, or how to actually produce software that's cheap in the long term. Its also exactly the same reason that Boeing is getting its ass absolutely handed to it in the aviation world. Use AI if you want to go bankrupt in 5 years but be rich now

I think your analysis is sound from a technical perspective, but your closing statement is why AI is going to be mass adopted. The people who want to be rich now and don't care about what will happen in 5 years have been calling the shots for a very long time now, and as much as we technical folks insist this can't possibly keep going on forever, it's probably not going to stop sometime soon.
by tialaramex | 2025-07-24 16:55:14+00:00
I can buy that claim for the .NET CLR but I've never seen it nailed down properly the way Java did which gives me pause.

I worry about the Win95-era "Microsoft Pragmatism" at work and a concrete example which comes to mind is nullability. In the nice modern software I often work on I can say some function takes a string and in that program C# will tell me that's not allowed to be null, it has to be an actual string - a significant engineering benefit. But, the CLR does not enforce such rules, so that function may still receive a null instead e.g. if called by some ten year old VB.NET code which has no idea about "nullability" and so just fills out a null for that parameter anyway.

Of course the CLR memory model might really be set in stone and 100% proof against such problems, but I haven't seen anything to reassure me as I did for Java and I fear that if it were convenient for Windows to not quite do that work they would say eh, good enough.
by dunham | 2025-07-24 16:55:17+00:00
I did this with manual, and my EV does this with a single pedal control. Letting off of the pedal will engage regenerative breaking to the extent that you let off the pedal, it does not engage the brakes. I find that in a lot of city driving I don't need the brakes, but they do work fine when I need them. I really like this functionality. The car can also creep along at 1-2 Mph when necessary - so I don't need brakes to deal with slow traffic. (With a manual, first gear would sometimes suffice for this.)

So the premise in the title of the article does not surprise me, but I thought that the primary pollution complaint about electric vehicles was tire pollution and not brake dust.
by azimafroozeh | 2025-07-24 16:55:25+00:00
Arrow is primarily an in-memory format, while Parquet is commonly used for on-disk storage. Typically, data is stored in Parquet and then read into memory as Arrow. FastLanes is a new on-disk file format, comparable to Parquet, but offers around 40% better compression and faster decoding thanks to its data-parallel encoding design.

Disclaimer: I'm the first author of the paper.
by agustinl | 2025-07-24 16:56:34+00:00
Hi all!

A few months ago I started noticing how many sites I used to love are now gone—some 404'd, some replaced, others just vanished. So I built Webituary, a small side project where people can submit and "bury" dead websites, leaving behind a brief memory or story.

It's a bit nostalgic, a bit silly, but also a way to reflect on the changing web. Would love your thoughts or ideas to make it better.

Im from 90s, and I started use internet on early 00s. I missed the time where one search in Google open the gate to a lot of curios websites.

Today, you start typing your question, and Google automplete it, show a IA generated answer, three sponsored links, first pages of high traffic websites (always the sames).

And that curios websites dead. :'(

When a website is submitted, I check if is a old website and I generate the metadata automatically:

- Favicon and first screenshot timestamp from wayback machine. - Screenshot from this timestamp with thum.io (screenshot can took some seconds to load) - Obituary, tags and years live with IA

Hope you enjoy it and submit your websites!

All feedback always welcomed (L
by munificent | 2025-07-24 16:56:34+00:00
> A memory safe, managed language doesn't become unsafe just because you have a race condition in a program.

The author's point is that Go is not a memory safe language according to that distinction.

There are values that are a single "atomic" write in the language semantics (interface references, slices) that are implemented with multiple non-atomic writes in the compiler/runtime. The result is that you can observe a torn write and break the language's semantics.
by constantcrying | 2025-07-24 16:56:42+00:00
>Also who hurt you?

I do not own a car, I walk/bike/bus/train everywhere and almost every time it is a terrible experience.

I want to have a better city, but a city does not become "walkable" or "unwalkable" because of zoning. It becomes either because it is either a good place to be or a terrible place to be. The obvious drug dealing at train stations make it a bad place, the obnoxious people with a total disregard for others make it a bad place, the trash everywhere make it a bad place, etc.

If you do not make cities nice places to be nothing else matters. And if you do make them nice places, everything else will follow, since now people want to be there and will demand e.g. better zoning and infrastructure.
by Alupis | 2025-07-24 16:57:08+00:00
Reciprocal tariffs have been something many people (on both sides of the isle) have been wishing for forever... It's not normally a D vs. R thing, except right now where the D's feel a need to play the opposition role.

On the other hand... most of the tariffs you hear about aren't real and never had/will-have an impact, and are clearly being weaponized as a way to get trading partners in-line. Few actual tariffs have been realized as-of yet... but if you read the news you'd be led to believe everything you buy is tariffed all to hell.
The Cult of AI
by d00mB0t | 2025-07-24 16:57:22+00:00
Do any of these ring a bell?

- Absolute authoritarianism without accountability

- Zero tolerance for criticism or questions

- A belief that the leader is right at all times

- A belief that the leader is the exclusive means of knowing “truth” or giving validation

- Suppression of Critical Thinking

- Loyalty Above All Else
by zer0tonin | 2025-07-24 16:57:56+00:00
There used to be a series of book called "Learn code the hard way". It was basically exactly this, you would have a bunch of code, and you were expected to retype it. The examples would progressively increase in complexity.

It helped me learn C 10 years ago when I was a student. Sadly, I doubt it's still relevant nowadays.
by IggleSniggle | 2025-07-24 16:58:02+00:00
Of course I trust my kids to make the most of the environment they are given, and given that their environment will differ from the one I am adapted for, they will likely surpass me in being well adapted to the environment of the future; it's still my responsibility to prepare them as best as I can for it.

You might put a baby in a pool so it can learn to swim, but you make sure their environment is such that drowning is an impossibility. A child destined to be an Olympian swimmer still requires guidance, even if their natural ability and inclinations outpace both their peers and their elders.
by wslh | 2025-07-24 16:58:20+00:00
I think part of the solution is to start discussing the specific limitations of LLMs, rather than speaking broadly about AI/AGI. For example, many people assume these models can understand arbitrarily long inputs, but LLMs have strict token limits. Even when large inputs fit within the model's context window, it may not reason effectively over the entire content. This happens because the model's attention is spread across all tokens, and its ability to maintain coherence or focus can degrade with length. These constraints along with hardware limitations like those in NPUs are not always obvious to everyday users.
by tocs3 | 2025-07-24 16:58:45+00:00
I listened to the "Joy of Y" podcast of an interview with Ewin Tang and thought it was an enlightening view of the current state of quantum computing.

https://www.quantamagazine.org/what-is-the-true-promise-of-q...

Edit: in light of a couple comments here I would like to say the podcast interview with Tang was this year. (May 3, 2025)
by hardolaf | 2025-07-24 16:58:56+00:00
Wow. So you really know nothing about the technology and are just spreading fear. The Chernobyl exclusion zone is mostly safe for people now outside of the fact that Russia is current bombing Ukraine.

The issue with cleanup at Fukushima Daichii is one of money and political will, not one of technology. We've had the ability to clean up nuclear accidents since the 1950s.

Also, the future of power is increasingly looking like LNG plants which pump only slightly less radioactive carbon into the atmosphere than coal plants do.
by ninetyninenine | 2025-07-24 16:59:05+00:00
This can be done in typescript. It’s not super well known because of typescripts association with frontend and JavaScript. But typescript is a language with one of the most powerful type systems ever.

Among the popular languages like golang, rust or python typescript has the most powerful type system.

How about a type with a number constrained between 0 and 10? You can already do this in typescript.

type onetonine = 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

You can even programmatically define functions at the type level. So you can create a function that outputs a type between 0 to N.

type Range<N extends number, A extends number[] = []> = A['length'] extends N ? A[number] : Range<N, [...A, A['length']]>;

The issue here is that it’s a bit awkward you want these types to compose right? If I add two constrained numbers say one with max value of 3 and another with max value of two the result should be max value of 5. Typescript doesn’t support this by default with default addition. But you can create a function that does this.

// Build a tuple of length L type BuildTuple<L extends number, T extends unknown[] = []> = T['length'] extends L ? T : BuildTuple<L, [...T, unknown]>; // Add two numbers by concatenating their tuples type Add<A extends number, B extends number> = [...BuildTuple<A>, ...BuildTuple<B>]['length']; // Create a union: 0 | 1 | 2 | ... | N-1 type Range<N extends number, A extends number[] = []> = A['length'] extends N ? A[number] : Range<N, [...A, A['length']]>; function addRanges< A extends number, B extends number >( a: Range<A>, b: Range<B> ): Range<Add<A, B>> { return (a + b) as Range<Add<A, B>>; }

The issue is to create these functions you have to use tuples to do addition at the type level and you need to use recursion as well. Typescript recursion stops at 100 so there’s limits.

Additionally it’s not intrinsic to the type system. Like you need peanno numbers built into the number system and built in by default into the entire language for this to work perfectly. That means the code in the function is not type checked but if you assume that code is correct then this function type checks when composed with other primitives of your program.
by dathinab | 2025-07-24 16:59:32+00:00
Some things:

- there is an official check sum VFS shim, but I never used it and don't know how good it is. The difference between it and WAL checksum is that it works on a per page level and you seem to need manually run the checksum checks and then yourself decide what to do

- check sums (as used by SQLite WAL) aren't meant for backup, redundancy or data recovery (there are error recovery codes focused on allowing recovering a limited set of bits, but they have way more overhead then the kind of checksum used here)

- I also believe SQLite should indicate such checksum errors (e.g. so that you might engage out of band data recovery, i.e. fetch a backup from somewhere), but I'm not fully sure how you would integrate it in a backward compatible way? Like return it as an error which otherwise acts like a SQLITE_BUSY??
by jesse__ | 2025-07-24 16:59:36+00:00
Hey, thanks for the comment! I did actually take a look at the aes instructions and came to the conclusion that they are in fact faster than the hash I used, but I think I'd decided I would have to swizzle the data in a way that was a pain because of how the aes mixdown works (ie it mixes across lanes, so I would have to change the output pattern, if that makeshifts sense)

Maybe I'll dust it off one day and try again. That seems like it could be an easy win.
by schwartzworld | 2025-07-24 17:00:02+00:00
> That is: you're left with a bunch of skeleton issues filed only for the sake of shoving it into a TODO comment

Nobody says it needs to be one ticket per TODO. For example, I usually maintain a CSS punch list ticket to avoid too much yakshaving when developing functionality. Not only will it be more likely to get scoped and done, but another dev will know exactly where the fixes are needed by grepping for the ticket number.

But the other upside is that if it's really not worth filing a ticket for, why not just do it? I'm curious what scope of work you think is worth tracking in TODOs but not tickets. If it would be a point of work it probably deserves a ticket. If it's less than a point of work, shouldn't you just do it?

> Those tickets end up getting auto closed after X time anyways.

That feels like it reinforces my argument to me. If you can't make time for it when it's a ticket, how would you make time when it's just a comment? At least if the team decides in grooming that the work doesn't really need to be done, it's a group decision and not just me passing the buck.
by ryoshu | 2025-07-24 17:00:04+00:00
Montessori is great. Highly recommend it. In later years students get access to devices in the one I'm familiar with, but in the early formative years they still use the same old-school materials for learning shapes, objects, quantities, math, etc.

They also teach cursive. The head of curriculum talks about how it unlocks different neural pathways. There was recent research that confirmed this.
by empath75 | 2025-07-24 17:00:07+00:00
> Another way to reach the same conclusion is to note that this post's argument proves far too much; by the definition used by this author, most other higher-level languages (the author exempts Java, but really only Java) also fail to be memory safe.

Yes I mean that was the whole reason they invented rust. If there were a bunch of performant memory safe languages already they wouldn't have needed to.
by WorldMaker | 2025-07-24 17:00:15+00:00
I have taken this to an extreme, I suppose. I sequestered my Google Account entirely to a Firefox container on my PCs and pretty much the YouTube app and only the YouTube app on my phone. Most random videos I watch in Discord embeds and mobile Safari/Firefox views that are never logged in to my Google Account.

My YouTube ads (and Recaptcha experiences) have gotten terrible because Google seems to punish you more the less data you feed them, but for the most part I feel like I have control of the data that I do feed them (some of which is intentionally misleading because they have no right to know and I hate targeted ads; I love Spanish language ads, for instance, though my level of Spanish comprehension is stuck somewhere around first year of high school courses).
by abraxas | 2025-07-24 17:00:26+00:00
It's fine to let exceptions percolate to the top of the call stack but even then you likely want to inform the user or at least log it in your backend why the request was unsuccessful. Checked exceptions force both the handling of exceptions and the type checking if they are used as intended. It's not a problem if somewhere along the call chain an SQLException gets converted to "user not permitted to insert this data" exception. This is how it was always meant to work. What I don't recommend is defaulting to RuntimeException and derivatives for those business level exceptions. They should still be checked and have their own types which at least encourages some discipline when handling and logging them up the call stack.
by qsort | 2025-07-24 17:00:41+00:00
I'm also seeing benefits, and I'm on pretty much the same stack as you. The METR paper I'm citing was misquoted a lot (N was small, and it wasn't a favorable setup for AI tools), but the most important finding was that it's very easy to fool ourselves about productivity benefits.

Am I going to cancel my Anthropic subscription? Certainly not, but I'm not going to pretend like my setup is The One True Way. The plural of anecdote isn't data. Nobody has this figured out, nobody.
by fragmede | 2025-07-24 17:01:04+00:00
That was four short paragraphs with basically no details - there's basically nothing for eyeballs to see. If I wrote a history of the world that consisted of "Some people lived and died, some of them were bad, I guess", how many copies do you think I'd sell? Any? What's interesting is the details, and a post giving actual detail of building some app, and the benefits and shortcomings of a specific tool would be of great interest to many. If I ask an LLM to save the date to the database, and then ask it to save the time, do I get two variables in two columns? Does that make sense for my app? Do I have to ask it to refactor? Is it able to do that successfully? Does it drop tables during program initialization? How does the latest model do with designing the entire program? How often does it hallucinate for this set of libraries and prompts? There's quite a bit of variance! If it hallucinated libraries and APIs left and right it would be far less useful. Some people don't even get hallucinations because their prompts are so we'll trod. There are all sorts of interesting details to be learned and shared about these new tools that would get a ton of eyeballs.
by munificent | 2025-07-24 17:01:04+00:00
I agree with the author's claim that you need thread safety for memory safety.

But I don't agree with:

> I will argue that this distinction isn’t all that useful, and that the actual property we want our programs to have is absence of Undefined Behavior.

There is plenty of undefined behavior that can't lead to violating memory safety. For example, in many languages, argument evaluation order is undefined. If you have some code like:

foo(print(1), print(2));

In some languages, it's undefined as to whether "1" is printed before "2" or vice versa. But there's no way to violate memory safety with this.

I think the only term the author needs here is "memory safety", and they correctly observe that if the language has threading, then you need a memory model that ensures that threads can't break your memory safety.

Go lacks that. It seems to be a rare problem in practice, but if you want guarantees, Go doesn't give you them. In return, I guess it gives you slightly faster execution speed for writes that it allows to potentially be torn.
by jajuuka | 2025-07-24 17:01:27+00:00
To a degree sure. I think a common architecture should be prioritized to ensure software portability. Similar to x86/x64. Where anyone can make hardware for the platform and porting software is much easier. Returning to the old days of every computer have their own unique architechture is not a good idea. Just caused insane fragmentation and nobody could truely invest in a computer without being worried about not getting certain products or software.

CPU space is definitely easier to disrupt but the GPU space requires a HUGE investment and you're fighting uphill against proprietary technology like CUDA that has become industry standards. Intel, Qualcomm, Samsung and Google have made inroads with budget to mid range which is the highest selling segment. But to compete with Nvidia or AMD on the high end you either need a whole datacenter or many years of R&D with very little return for a long time. Apple would be on this list but they have siloed off themselves entirely.
by zozbot234 | 2025-07-24 17:01:46+00:00
> And frankly, a lot of software I write is just boring, and Go does fine for a lot of that. I try Rust periodically for things, and romantically it feels like it's the closest language to "the future", but I think the future might still have a place for languages like Go.

It's not so much about being "boring" or not; Rust does just fine at writing boring code once you get familiar with the boilerplate patterns (Real-world experience has shown that Rust is not really at a disadvantage wrt. productivity or iteration speed).

There is a case for Golang and similar languages, but it has to do with software domains where there literally is no viable alternative to GC, such as when dealing with arbitrary, "spaghetti" reference graphs. Most programs aren't going to look like that though, and starting with Rust will yield a higher quality solution overall.
by perrygeo | 2025-07-24 17:02:22+00:00
To everyone with complaints about the new "Shortbread" styling, I agree that it's not perfect but that's kinda missing the point. The real story is that vector tiles have the styling applied client-side so anyone can tweak the look with a little javascript.

The prior raster tiles have the style baked in; if you want a new look, you need to generate a new image. So each map publisher ends up running their own data and server infrastructure just to tweak the style.

The vector tile approach means a single (cacheable) asset can be used in many different maps. Huge win. If you don't like the style, you can make your own without having to literally download the planet.
by leptons | 2025-07-24 17:02:46+00:00
I use Youtube on a Chromecast with the SmartTube-beta app, which skips in-video ads, if they are demarcated by the creator - and most videos with in-video ads have that. The app just skips right by the in-video ad, as well as a bunch of other non-interesting video content if it is specified in the video timecodes by the creator.

Another great feature of SmartTube-beta - and it's the feature that brought me to that app - is the ability to completely remove all "shorts" from the entire app. No more shorts. I've configured the app to eliminate them completely like they never existed.