MurphyA/hacker-news huggingface dataset:
by T0Bi | 2025-07-26 08:44:38+00:00
There are already several of such blog posts.

I use the .devcontainer¹ from the claude-code repository. It works great with VSC and let's you work in your docker container without any issues. And as long as you use some sort of version control (git) you cannot really lose anything.

¹ https://github.com/anthropics/claude-code/tree/main/.devcont...
by ovelv | 2025-07-26 08:45:54+00:00
AI Image Maker is a powerful free online image editor and design platform. Create posters, blog covers, app icons, and app store screenshots with ease. Compress, resize, crop, convert images (JPG, PNG, WEBP, GIF, PDF), remove backgrounds with AI, generate QR codes, slice images, and turn videos into GIFs—no registration required. Perfect for designers, marketers, and content creators.
by ralfj | 2025-07-26 08:46:02+00:00
Thanks! I added a reference to that in the blog post.

Interestingly, in 2012 Rob Pike explicitly said that Go is "not purely memory safe" because "sharing is legal": https://go.dev/talks/2012/splash.slide#49. However it is not entirely clear what he means by that (I was not able to find a recording of the talk), but it seems likely he's referring to this very issue.

> "The program should not be able to derive a bad address and just use it"

My example does exactly that, so -- as you say, Go mostly achieves this, but not entirely.

> Note that stated goal from 2009 is "good support for concurrency", not "concurrent-safe".

My argument is that being concurrency-unsafe implies being memory-unsafe, for the reasons laid down in the blog post. I understand that that is a somewhat controversial opinion. :)
by zapzupnz | 2025-07-26 08:46:53+00:00
Professionals use macOS. They also use iOS and iPadOS. I think Apple's success is their own poison in that the definition of who or what a professional is has expanded with their market share.

Yet, in their eagerness to transition their newer fanbase of loyal bicycle riders to the Mac mega-truck, they didn't so much as add oomph to the bike as attach pedals to a lorry.
by burnt-resistor | 2025-07-26 08:47:12+00:00
podman and Docker run just fine on arm macOS. Both also support multiple architectures through emulation. Docker supports: arm64 amd64 amd64/v2 riscv64 ppc64le s390x and 386.

Also, dev containers should == server containers. This is the proper way to develop, and it's entirely unreasonable and impractical to also foist a server OS as a developer laptop OS. Use the most useful, comfortable, and practical developer desktop OS... which, sadly, is rarely Linux even these days because app support and OS usability still isn't at parity with the $$ ones post-Canonical. Invariably, it's Mac or Windows. If someone also wishes to make their lives more difficult (or perhaps easier), then all power to them to run a Linux distro or FreeBSD.
by youngtaff | 2025-07-26 08:48:33+00:00
> HTTP 2 has been adopted by browsers for like 10 years now and its multiplexing makes packaging large single bundles of JS irrelevant

H2 doesn’t make packing irrelevant… there’s still an IPC overhead with many small files… and larger bundles tend to compress better (though compression dictionaries might help here)

Large Js bundles are a huge problem though
by nkmnz | 2025-07-26 08:49:24+00:00
lol no. Private health insurance in Germany is ~800-1000 for a 60 y.o. – public insurance might be cheaper, but you need to qualify for that when you move here by working as an employee when you're that old. Working permission will require you to work full time. So you'll end up working full time and pay ~600-1200 (based on your salary) in contributions.
by KronisLV | 2025-07-26 08:52:12+00:00
> SPAs make sense when your users have long sessions in your app.

SPAs also make sense when you want to decouple the front end from the back end, so that you have a stable interface like a RESTful API and once AngularJS gets deprecated you can move to something else, or that when your outdated Spring app needs to be updated, you'll have no server side rendering related dependencies to update (or that will realistically prevent you from doing updates, especially when JSF behavior has changed between versions, breaking your entire app when you update).

> When it is worth the pain to load a large bundle in exchange for having really small network requests after the load.

The slight difference in user experience might not even enter the equation, compared to the pain that you'd have 5 years down the line maintaining the project. As for loading the app, bundle splitting is very much a thing and often times you also get the advantage of scoped CSS (e.g. works nicely in Vue) and a bunch of other things.
by necovek | 2025-07-26 08:52:16+00:00
Sure, it's not perfect, and there are other issues. With UTF-8, you know exactly how many octets you need to read for the rest of the characters.

But for issue #2, that seems to not be too bad since you only need to look one byte backwards.

At the same time for #3, in the middle of UTF-8 bytestream, you need look backwards as well for anything but the ASCII (7-bit) codepoints too.
by erasmus | 2025-07-26 08:52:22+00:00
The ATProto (the federation protocol on which Bluesky is built) may inadvertently worsen online discourse through bad commercial incentives.

In a federated system where users can easily switch platforms with their social graphs intact, platforms will compete for users/eyeballs by optimising for engagement rather than quality content. The outcome may be that "responsible" platforms that moderate well become small, irrelevant echo chambers, while platforms that embrace sensational, low-quality content grow rapidly and dominate public discourse.
by juandsc | 2025-07-26 08:52:45+00:00
I don't think it's a modern programmers problem, in fact, I think we can argue we are much better than 20 years ago at least in terms of security.

There is a much higher concern for data validation and no one used HTTPS 20 years ago. Literally there were social networks with people uploading photos and personal stuff which didn't even have HTTPS.
by 7moritz7 | 2025-07-26 08:52:57+00:00
I assume they just decided that the whole industry, even if run legitimately in some cases, has too high of a legal risk and hence don't decide on a case-by-case basis. With how often NSFW content gets reuploaded and the source becoming unclear, they probably see the biggest risk with undetected child porn on regular porn sites. If you are involved with that as a payment processor that's obviously a huge problem.
by Einenlum | 2025-07-26 08:53:57+00:00
I remember when ChatGPT was released. I talked about it to a friend who is not technical. She said "oh wow, I really need to try it". She later said "I couldn't find the app in my AppStore".

I kept saying they had a website and why would you need an app. She couldn't understand what I was saying.

Seems like indeed the general public really likes apps and even thinks you can't do so many things in the browser.
by npteljes | 2025-07-26 08:57:11+00:00
Another framing of this: Mastercard / Visa, and by extension whomever had them to do the crackdown, are now powerless to change DLSite.

Googling for news, it seems like the story between DLSite and M/V is a push and pull. Many articles turn up that say they have an agreement, then a disagreement, then an agreement again, then a suspension, then they bring it back again etc.

My point here is that their relationship with M/V seems to have failed to actually change them, so, the point "they're powerless to change Japan" stands.
by cauch | 2025-07-26 08:58:43+00:00
Why would it be the size of the specific two people in a relationship?

It looks very clear to me that violent behavior in relationship (and more specifically, in the first few days of dating) is a question of education, not the result of one person being bigger. For example, every parents are stronger than their young children, but only some kind of parent are violent towards their children. If it's a question of education, reducing the problem of the size of the people is a terrible terrible idea: the problem will never go away because you don't understand the source and therefore don't act on the source to fix it.

It feels like some people here are framing the problem in "men vs women" framework, as if it is a competition and they don't want to accept that maybe men behavior is different from women behavior because the way they are raised in our society. I don't really see the point: I'm a man, and yet I don't take it personally. The same way I don't take it personally when someone says "don't accept candy from strangers": I'm a stranger for a lot of kids, and yet I understand why they should be prudent and I understand that, in situation where I have to interact with an unknown kid, I should do things differently (for example not giving them candy), not because I'm a danger for them, but because it is true that there is danger and that they cannot know if I'm a danger or not.

So many men take it uselessly and nonconstructively personally as soon as it is dating.
by bornfreddy | 2025-07-26 09:00:03+00:00
Ok, fair enough, if we are looking at software side of "repairs" (updates). However I'm talking about hardware side of things - with Fairphone I can remove and replace the battery by myself (or even carry a spare if I choose to), while e.g. in the newest Pixel, 9a, the battery is glued in place.

As for the requirements, I will take your word for it. And I do appreciate that you put the emphasis on security as it is often overlooked. I guess what I'm saying is that having control over my phone (as opposed to BigTech or apps having the control) is for me a much higher priority goal than just security by itself. Hardware reparability is (again, for me) a close second.

Anyway, I hope you find a good partner for the phones, and I'm curious to see what you come up with!
by sfn42 | 2025-07-26 09:00:12+00:00
> Not if the client is, e.g., constantly moving between cell towers, or right near the end of their range, a situation that frequently happens to me on road trips.

Right, but how often is a user both using my website and on a roadtrip with bad coverage? In the grand scheme of things, not very often. I also think this depends on what the round trip is for. Maybe the 10s round trip is simply because it's a rather large request.

> I don't at all disagree that too many tiny requests is the cause of many slow websites

That's not really what I was saying, though I don't disagree with it. If you're sending multiple small requests then there are two ways to go about it: You can send all of them at the same time, then wait for responses and handle them as they come back. The other option is to send a request, wait for a response, then send the next etc. The latter option causes slowness, because now you're stacking round trips on top of one another. The former option can be completely fine.

But I'm not saying the client should be sending lots of requests. I'm saying they should get the data they need rather than all the data they could possibly need. This can be done in one request that gets a few kilobytes of data, you can fit 64kb in a single tcp packet. That's quite a bit of data, easily enough space to do useful stuff. For example the front page of HN is 8kb. It loads fast.

I'm also not saying you should use SSR. I do think that SSR is a great way to build websites, but my previous comment was specifically about SPAs. You don't have to send requests for every little thing - you can validate forms on the frontend in both SPAs and SSR.

Round trips are costly but not that much. A lot of round trips are unavoidable, what I'm saying is that you should avoid making them slower by sending too much data. And also avoid stacking them serially.
by crusty | 2025-07-26 09:02:22+00:00
Passing would only be a temporary solution since the new front bus will now have the delayed position, and the more crowded bus that was passed will have the expedited position and will shortly overtake the front one. They will essentially travel at the same rate and stay bunched in this scenario.

It might make more sense, when the delay to the front bus gets to within a given time of the rear bus' expected arrival time (maybe 1 minute, maybe more, maybe less), the lead bus simply switches to a state where it only picks up when a stop is requested by a passenger until it gets to within some time differential from its scheduled arrival time.

That would suck for some people to watch it pass but realistically, if it wasn't skipping stops, the wait for leap-frogging platoon would be closer to that off the rear bus anyway.
by ralfj | 2025-07-26 09:02:27+00:00
> The C definition is that "undefined behavior" can have arbitrary concrete behavior, not that a compiler can assume it does not happen.

What is the difference between those? How does a compiler that assumes UB never happens violate the requirement that UB can have arbitrary concrete behavior? If we look at a simple example like optimizing "x + y > x" (signed arithmetic, y known to be positive) to "true" -- that will lead to some arbitrary concrete behavior of the program, so it seems covered by the definition.

I assume that what the original C authors meant was closer to "on signed integer overflow, non-deterministically pick some result from the following set", but that's not what they wrote in the standard... if you want to specify that something is non-deterministic, you need to spell out exactly what the set of possible choices are. Maybe for singed integer overflow one could infer this (though it really should be made explicit IMO), but C also says that the program has UB "by default" if it runs into a case not described by the standard, and there's just no way to infer a set of choices from that as far as I can see.
by layer8 | 2025-07-26 09:02:39+00:00
Thread-safety isn’t just about word tearing. It’s also about state invariants in your program. Even if all your threads are green threads on the same OS thread, you still have to guard critical sections that check-and-modify, or that temporarily break the invariants of state that is observable by other threads, when there’s anything in-between that may lead to a context switch. Otherwise, while you may be free of word tearing, you might still have “torn” program state.

On a single-core CPU, word tearing may similarly be absent between OS threads, but you still have to guard any critical section.

I agree with user swiftcoder that there are concurrency issues (like the above) even in the absence of hardware parallelism, or of multiple OS threads (which by themselves don’t imply hardware parallelism). I disagree that “thread-safety” isn’t an appropriate term for them. Those issues are part of what thread-safety was always about.
by zelphirkalt | 2025-07-26 09:02:55+00:00
I am not a fan of Golang or the approach taken to designing it, but I will say, that writing code in a certain way may even have zero cost, because after some time it may be natural to write code that way to someone. For example this works for programming paradigms. I am just as familiar with FP as with OOP and when writing FP code I avoid mutation. Does that make my code writing slower? Only in so far as a problem inherently is or is not more difficult to solve without mutation.
by MaxBarraclough | 2025-07-26 09:02:58+00:00
> Once you’re a good programmer, new languages are easy.

Not always. Languages can differ radically. If the new language uses concepts you've never encountered before, you're going to need to do the work of learning those new concepts.

An example I've used before: 20 years writing C code for embedded systems won't give you any insight into Haskell's applicatives or monads.
by pjerem | 2025-07-26 09:03:07+00:00
I never said public healthcare is free for strangers. It’s rarely the case.

Most of the time if you are not a citizen you need to either work or pay taxes. In fact even if you are a citizen, you may not be covered if you live abroad.

It’s relatively easy to be covered as a stranger : in 99% of situations, if you just set up here seriously and not as a tourist, you’ll be covered. I count a 60yo who never contributed to the system or worked here as a tourist.
by 44za12 | 2025-07-26 09:05:46+00:00
You know what’s wild? We’ve reached a point where the “download our app!” pop-up is basically the digital equivalent of a mall kiosk worker chasing you down with a lotion sample. I just want to read the article, not sign up for a recurring relationship. The web is supposed to be open, frictionless, and—dare I say—fun. Instead, it’s become a minefield of dark patterns, nag screens, and “please enable notifications!” popups.

I love that this post is pushing back on the norm. Maybe, just maybe, we can start a movement to make the web usable again. Or at least make “No, thanks” actually mean “No, thanks.”
by amibm | 2025-07-26 09:06:47+00:00
Totally agree. It's even difficult to accommodate too many apps in the mobile. I myself have been very cautious about the permissions, but it's a planned collaborative design of the smart phone ecosystem and so it's nearly impossible to protect personal data completely.

Also the entire tech industry is almost surviving on the promise of surveillance state and economy as if looked carefully there aren't that many success stories of the tech outside of the very obvious financial and automation industries. And that can serve only upto a certain level, but the hype of tech is way beyond that. To match that, they are desperate to break any law and all morals.

Also a glance at our own investment portfolio will tell us that it's our collective quest for wealth growth is the actual driving force of this 'everything financial' tech industry.
by WorldPeas | 2025-07-26 09:07:22+00:00
nope, it can be had via ebay for around 200 dollars, for which you get a metal chassis, 360 hinge, nice enough keyboard and track-nib, 8gb ddr4 and 64gb all to say that it's the basic system requirements to be a proper video-terminal into a mac desktop. The nanote itself has had some driver issues with its touchscreen (that I do not use, so didn't care to install) and screen rotation. I would say it's a shame we don't just have clamp on keyboards for our phones that are good enough to type on/tracknib and fit in our pockets, but that's perhaps for someone else to fix
by jiggawatts | 2025-07-26 09:08:39+00:00
> introducing new clients for feature subsets (e.g. something running on a Garmin watch) becomes trivial.

This never happens, for some values of never.

When a SPA app is initially developed, the "client" and the "API" are moulded to each other, like a bespoke piece of couture tailored to an individual's figure. Hand-in-glove. A puddle in a depression.

There is absolutely no way that some other category of platform can smoothly utilise such a specialised, single-purpose API without significant changes.

The reality is that most SPA apps are monoliths, even if the client app and the API app are in different Git repos in order to pretend that this is not the case.
by ralfj | 2025-07-26 09:10:34+00:00
> They also count data race freedom as part of memory safety, which I think is wrong (and contradicts their inclusion of Java and even Go in the list of memory safe languages).

For Java, there's no contradiction if you define data race freedom as "data races cannot cause arbitrary memory corruption / UB".

> And ive never heard “memory safe” used in relation to not having null pointer exceptions. That’s a new one and sounds nonsensical, frankly

I was also surprised, but it's what I was told by people working on verification of Java programs. And you can see e.g. at https://link.springer.com/content/pdf/10.1007/978-3-030-1750... that people are proving memory safety of Java programs, which would not make sense at all if all Java programs are memory safe by construction.
by jbreckmckye | 2025-07-26 09:11:08+00:00
This article is full of misrepresentations and lazy takes. The author has had other anti-JS polemics widely upvoted on HN, which were just as carelessly written. But people upvote it anyway.

What is the cause of this?

1. Bad experiences with JavaScript apps that have aggregated complexity (be it essential or incidental complexity)?

2. Non-JS developers mystified and irritated at a bunch of practices they've never really internalised?

3. The undercurrent of "frontend is not real programming" prejudice that existed long before React etc al. and will continue to exist long after it?
by hiAndrewQuinn | 2025-07-26 09:11:13+00:00
The web is definitely incapable of hacking the speed of light, though. And if you want truly instantaneous search - I mean deterministic, keystroke by keystroke - you have to put your data as close to the customer as possible, ideally right on the same device, ideally right in the same process.

Is this necessary for most commercial projects? Of course not. But many of the programs I consider the nicest to work with today are that way precisely because someone fought back against the call of the network.
by anovikov | 2025-07-26 09:13:50+00:00
It's just simply that in Europe we have less systematic inequality, almost no second-generation rich people. Rich people are almost always 4-7 generations old (who made money before anti-inequality regulations and values took root in ~1880-1945). These people are so many generations away from getting shit done they just don't see it as an appropriate thing for a good respectable gentleman to do. And the rest are too poor to take any risks - and the nanny state gives them an ability to keep a shitty, but almost risk-free existence.

Innovation needs systematic inequality and a culture that declares it a virtue to succeed at the expense of everyone else. America has it. China has it. India has it. Russia has it, it's just that their innovators are mostly abroad because the state is too scary and disgusting, so they prey onto Americans, mostly, because these have more disposable income to leech off.
by kuon | 2025-07-26 09:13:52+00:00
Hard disagree here. Use it. Of course, if you running code that drive a pacemaker or a train maybe be careful, but in general, do things. We don't want a world where only three old bearded guys can write a compiler or a physic engine. Do the same errors again and you'll learn, eventually you'll do better than those who were here before you.
by uecker | 2025-07-26 09:14:51+00:00
"arbitrary concrete behavior" means that at this point anything can happen on the real machine. This implies that everything before this point has to behave according to the specification. "is impossible" is stronger, as the whole program could behave erratically. But having partial correctness is important in a lot of scenarios and this is why we want to have it and in "UB" it is the former and not "impossible".

In the ISO C standard, we use "unspecified" for a non-deterministic choice among clearly specified alternatives. So this is well understood.
by W3zzy | 2025-07-26 09:14:58+00:00
The banning guns is easier when you control the sales part.

Preventing children from accessing certain websites is not working at all. It also is a cop out. I have children aged 15 and 17. They received their forest smartphone at age 12. The phones were restricted in a certain way and they didn't get unlimited use. We educated them about proper use and at age 15 restrictions were lifted. They allready know how to use VPN's because they're on my paid account. I see it no different from sexual education.

I don't need a government to make a private company collecting my personal identification. The best guardrail against data loss is not collecting any.