oftenwrong

Related: https://nyc.streetsblog.org/2025/05/29/data-dump-e-bike-cras...

The stated reasoning behind this new policy is not backed by data; e-bike collisions and injuries are down in NYC and are insignificant compared to the harm caused by cars. Rather than looking at the data to determine the urgency of the problem, the police merely listened to complaints from community members and assumed that the complaints had merit.

I am excited to learn of this project. I started working on something quite similar recently. It's a surprisingly unaddressed niche.

One thing your tool appears to be missing (IMO) is execution sandboxing. This is useful, as you likely know, for avoiding undeclared dependencies and for avoiding dirty builds due to actions polluting the source directory, among other things. I was playing around with allowing configurable sandboxing, with symlink forest and docker as two intial options.

There is also a question of what developers should be developing against. A typical monorepo approach allows many developers to develop only against trunk, and not have to allow the messy world of releases and deployments into their brain.

Regarding priorities, a manager from my past used a system that I liked: Each person had a set of tickets assigned to them, but there was always an unambiguous priority order. At any given time, a given worker would work on their highest-priority ticket that progress could be made on at that time. If anyone wanted to shift that worker to another ticket, then the priorities needed to be adjusted, and the worker would be notified (if they didn't do it themselves). This helped make it clear what people were expected to be working on, and made it easy to see what people were currently working on.

I am not an expert in SAML, but my understanding is that the cert is typically included in the SP metadata. It seems to me that icluding the SP cert in the AuthnRequest would defeat the purpose of signing the request. Is that supported in the standard?

For the house, hire a professional inspector who will use an x-ray fluoresence meter and dust test strips. You want a professional because they will be more thorough, and check things that you would not know to check.

To test your children's exposure, you can have their blood tested. They may very well be exposed from sources other than your house

This appears similar to Java's String Template preview feature that was withdrawn:

https://openjdk.org/jeps/465

This is probably the best overview of why it was withdrawn:

https://mail.openjdk.org/pipermail/amber-spec-experts/2024-A...

I used to use uMatrix and would often disable CSS, but enable necessary JS. This allowed most sites to work properly while displaying them in a plain HTML look that I prefer. I think what you are describing is aimed at a similar end result, but would require less faff.

I've had the misfortune of working on "enterprise" software where avoidance of "hard-coding" went so far that the core system did almost nothing other than exist as a way to plug in mutable functionality. All in the name of not having to re-build, or to re-deploy, and being able to tell the customer that no code changes would be required, even though the "configuration" was practically code, and required many of the things that code might require, like qualified configuration developers, test suites, and detailed deployment plans. Truly madness. In the era of software as a service via internet, software is more "soft" than it has ever been. You can change it and deploy it to production any time you please.

This is a typical use case for views and stored procedures in RDBMSs. They can be used to provide a stable API for a given client even as the underlying tables change. To your point, however, these still do not solve the problem.

Alternatively, we could use a model in which functions are immutable, and therefore make such breaking changes impossible. This is the approach taken by Unison:

https://www.unison-lang.org/docs/the-big-idea/

I recommend reading The world in which IPv6 was a good design by apenwarr:

https://apenwarr.ca/log/20170810

It has been submitted many times here:

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

You will find at the end that it has received an update of sorts here:

https://tailscale.com/blog/two-internets-both-flakey

I was curious how the times were obtained. It uses https://github.com/nathan-osman/go-sunrise , which links to this calculation method: https://en.wikipedia.org/wiki/Sunrise_equation#Complete_calc...

>Our neighboring town has a beautiful system in place. It tracks your average speed over +- 100m. If you speeded, you get a fine and even better: the light always turns red and you have to wait for a minute. If you run that red light, you get another (heftier) fine. If you drive normally, the light is always green.

I have never seen a system like that. What town? Or what system?

The reason for avoiding OS threads is not only the cost of creating them, but also the overhead of scheduling them. The kernel uses preemptive multitasking, so it does work to determine when it should switch control between threads, and which threads should be running, and there is a cost of performing that context switch. The OS also can tell from syscalls when a thread is waiting on I/O.

Java virtual threads are more similar to async/await since they are a form of cooperative multitasking. That is, virtual threads must explicitly tell the runtime when they are ready to yield execution to other tasks. In practice, the programmer does not need to do this manually; the low-level 'blocking' operations in the JDK have been modified to signal this state. This is why you do not need to use an explicit syntax like async/await. Under the bonnet, virtual threads are mounted and unmounted to/from platform threads (JVM wrappers for OS threads) in a pool. All of this involves overhead of copying virtual thread contexts to and from the heap, and of managing the scheduling of virtual threads.

Why don't other languages use this implicit approach? I am sure there a various reasons, but I cannot really speak to them in specifics. I would be interested to know as well. I would guess that the overhead of the implementation is one major reason.

According to this 2020 paper, "resuspended" particulate matter may be a major, previously unaccounted-for contributor to pollution from roads.

https://www.mdpi.com/1660-4601/17/8/2851

>Traffic-related resuspended dust is particulate matter, previously deposited on the surface of roadways that becomes resuspended into the air by the movement of traffic.

>Results show that the inclusion of resuspended dust in the emission and dispersion modeling chain increases prediction of near-road PM2.5 concentrations by up to 74%.

The weight, speed, and volume of traffic, are therefore considerable factors even beyond the pollutants the vehicles leave behind.

Lead does not readily degrade, either. It is still in the soil, the dust, our building, our foods, et cetera. People seem to be generally less exposed in each successive generation, however.

https://www.efsa.europa.eu/en/efsajournal/pub/1570

If you are open to using zsh, take a look at https://github.com/larkery/zsh-histdb . It stores your zsh history in a sqlite3 db. The benefit of this is that your history is well-structured and indexed, and that you can use SQL to query it. The working directory, exit status, and more are included, so you can easily implement your own smart history tools.

This is similar to how java.util.concurrent.atomic.LongAdder works:

https://github.com/openjdk/jdk/blob/master/src/java.base/sha...

I agree with your sentiments. It's not always possible or worth it to go again the dominant culture of Java and most Java shops is against it. I have lost more of these kinds of battles than I have won.

I see Boot as a major risk for long term maintainability unless you are willing to keep Boot experts on staff. This is relevant: https://news.ycombinator.com/item?id=33185010

I wouldn't say the same for Tika, which I have used many times. It has a relatively small and readable codebase, excluding the parsers it depends on, and does not impose much upon its host code. While complex, it is significantly more feasible to fork or adopt it, if necessary.

To your point, the typical golang library, from what I have seen, is closer to being something manageable.

The Java community is too accepting of hacks (or hack-like things) such as bytecode manipulation, annotation processing, classpath scanning, classloader tricks, reflection, excessive reliance on not-quite-code configuration, etc. There are legitimate use cases for these techniques, but they should be used sparingly, and with great care.

The logging situation is emblematic of Java's tendency to on third-party solutions even for basic, primary concerns. The development and build tooling is another major example. Whereas golang provides tools that are standard, powerful and beloved, the JDK only provides low-level tools that are fairly half-baked and require significant orchestration for typical tasks. Same situation with JUnit instead of having a sensible, built-in approach like go test. The list goes on...

You were certainly bitten by the Java ecosystem, but I would agree that you hold some responsibility. Adopting Spring Boot so casually is really quite questionable. It's essentially opting to build your application within a giant, bonkers codebase. In the golang community there is a held value of using the standard library and tools, which is helped those being very good. I would suggest that Java is a better experience if you follow that same approach. If you want to serve HTTP, use the jdk.httpserver module. If you want to make HTTP requests, use java.net.http. If you want to interact with the filesystem, use java.nio.file. To build, use the included tools in the JDK. When it comes to cases where a third party dependency is warranted, such as use cases for Tika, you will have to deal with some questionable design decisions, but it's much easier when you have just a few libraries that you use by hand, and no insane framework trying to stitch everything together for you. For getting those dependencies, you are going to be acquiring them from public maven repositories, but I would suggest using Coursier or Maven Resolver instead of actually using Maven.

The error handling is explicit only in a limited way. As the author points out, you have to explicitly propagate an error condition, but you don't have to explicitly not-propagate it. Exceptions are reversed in this way: propagation is implicit, and not-propagating is explicit. I would prefer that handling is fully explicit in all cases, and not depend on supplemental linting or sheer discipline. It's a bit incongruous that golang compiler is so fussy about unused imports, but has nothing to say about silently ignored errors.

I also find that stack traces are generally more useful than plain wrapped errors. I want to know the code path in most cases where I am looking at an error.

More generally, it's disappointing that golang has so many idiosyncrasies given its philosophy of straightforwardness. I struggle to think of any useful, general purpose language that has fared better, though.

Gradle and Spring Boot are not a part of the JDK, so it seems unfair to discount Java due to their poor designs.

>Stored Procs make everything about your standard DevOps and SDLC process harder - branching, blue green deployments and rolling back deployments.

There is a naming/namespacing strategy incorporating a immutable version identifier that makes this easier, which I have described here:

https://news.ycombinator.com/item?id=35648974

Note that this requires a strategy for cleaning up old procedures.

It also is possible to individually hash each procedure, which is more sophisticated, and would allow for incremental creation of new procedures.

OCI image _is_ a vendor neutral VM image format; the runtime spec includes facilities for running VMs: https://github.com/opencontainers/runtime-spec/blob/main/con...

I am disappointed by the lack of citations in this article. I am assuming much of this information is from the mentioned book, McNamara's Folly.

Not sure if this fits, but JDK 24 includes a new API, java.lang.classfile, for classfile manipulation.

https://openjdk.org/jeps/484

Rich Hickey on HttpServletRequest?

https://www.youtube.com/watch?v=aSEQfqNYNAc

In small companies, cloud also provides the ability to work around technical debt and to reduce risk.

For example, I have seen several cases where poorly designed systems that unexpectedly used too much memory, and there was no time to fix it, so the company increased the memory on all instances with a few clicks. When you need to do this immediately to avoid a botched release that has already been called "successful" and announced as such to stakeholders, that is a capability that saves the day.

An example of de-risking is using a cloud filesystem like EFS to provide a pseudo-infinite volume. No risk of an outage due to an unexpectedly full disk.

Another example would be using a managed database system like RDS vs self-managing the same RDBMS: using the managed version saves on labor and reduces risk for things like upgrades. What would ordinarily be a significant effort for a small company becomes automatic, and RDS includes various sanity checks to help prevent you from making mistakes.

The reality of the industry is that many companies are just trying to hit the next milestone of their business by a deadline, and the cloud can help despite the downsides.

>Lightweight Java has always been a thing for those who appreciate Java-the-language but despise Java-the-ecosystem.

I always disliked Java until I was converted by some developers of that group in a past job. I suppose it is fair to judge a language by the overall flavour of its ecosystem, but it is a bit disappointing. I wish more people could see how simple and _good_ it can be when you use the JDK itself, and not go through other overcomplicated systems to use it. For example, Spring Boot is basically a massive pile of hacks (regardless of whether you consider it good or bad), and Java only really serves as an underlying support technology for it.