unscaled

4 ms·

1.
by unscaled 10d ago
Have you worked on large (>500KLOC) codebases with an agent? Yes. But keep in mind KLOCs are not easily comparable across languages. Java is notoriously verbose. A 500KLOC codebase in Java would usually be half that size in Rust. If you
2.
by unscaled 10d ago
I think Java explicitly refused to take some of the best features of Kotlin, like extension methods, context parameters and operator overloading.
3.
by unscaled 10d ago
> Most organizations that use Java tend to be pretty conservative with their technology picks That part i s true. > with newer Java versions the only real gap with Kotlin is null-safety But that part isn't. Kotlin has: - Structur
4.
by unscaled 10d ago
> Hiring developers is easy > And that "team" nowadays may also consist of many AI agents. And that's the part where the hireability arguments collapse. Sure Claude Code works pretty well with Java. It also works well w
5.
by unscaled 11d ago
Sure it does: https://github.com/uber-go/nilaway Not exactly the same solution as JSpecify, since it doesn't rely on annotations, but it's also more ergonomic. I'm not comparing this to "null-restri
6.
by unscaled 11d ago
Go panics.
7.
by unscaled 11d ago
Congratulations. You've added another build tool and sprinkled your code with ugly annotations and ifs and Optional Optional.of(x).map(y) all over the place to get the same thing you'd get by moving to Kotlin. I get it why this se
8.
by unscaled 11d ago
While Java can outperform Go in some cases, the situation is very much the opposite when it comes to Rust. I also don't see the case for stability. Yes, if you're still on JDK 8, it would probably chug on for a couple of years. Bu
9.
by unscaled 11d ago
I'm not sure what enterprise-level collaboration means. In my experience, "enterprise" usually means: "Let's use tools that are 10 years behind, buggier than average, and have lots of half-baked features, none of wh
10.
by unscaled 11d ago
> Go has null pointer dereference problem. Which Java famously does not have. > Rust is too low-level for typical enterprise app where requirements changes twice a day. You end up spending time and tokens fighting with borrow checker.
11.
by unscaled 15d ago
OP already answered that one: They used a closed list of 3 vendors in prioritized order, and got 429ed out of two of them, while the third one stopped serving the mode. This is less of a problem if you're running an agent locally and r
12.
by unscaled 18d ago
I think the article is a bit weak when it's making this point, because it's not about Unix pipelines. It's about POSIX shell utilities being too bare-bones. But Unix pipelines are not simple too. They have a couple of nitty-g
13.
by unscaled 1mo ago
You can mix Japanese and Chinese with modern document authoring standards or with HTML, but the fact is that most people are too lazy to do that. It's a pet peeve of mine when a document gets displayed with a Japanese font but then fal
14.
by unscaled 1mo ago
I don't know how much the USTR campaign against TRON affected the success of BTRON, but I feel like we should be careful about this explanation. This is a classic example of American exceptionalism, but it seems like the USTR mandate j
15.
by unscaled 1mo ago
In highly distributed microservice architecture, there's almost never a single upstream. In some cases you may have a couple of customer-facing entry-points (a global API gateway, and a couple of BFFs), but these are not the only paths
16.
by unscaled 1mo ago
> To handle this correctly you need your RPC framework to accurately communicate retryable vs non-retryable failures to clients. Even this is not enough, since you cannot always reliably know whether service B is dead or suffers an inter
17.
by unscaled 1mo ago
I think the "happy path" might be a slightly wrong classification in GP, since the post is in reply to a retry-storm issue and explicitly talks about retry storms and thundering herds. I've seen many cases where engineers opt
18.
by unscaled 2mo ago
That's my take. The arguments for Go over Rust used to be: - Better concurrency story - Native cross-compilation of static binaries (great for CLIs) - Easier to learn, easier to teach - Opinionated: You don't have to enforce a sin
19.
by unscaled 2mo ago
I don't think it was true even in 2023. This sounds like tackling the problems of C++ in the early 2000s. 1. Casey Muratori also that DRY shouldn't doesn't have to result in non-performant code. 2. Smaller functions, function
20.
by unscaled 2mo ago
For this testing to be really effective at stopping "dangerous and misaligned" models from leaking out, you need a mechanism for banning failed models that prevent them from being released in the first place, not just prevent US c
21.
by unscaled 2mo ago
The law is airtight. Acceptance must be informed and freely given (this includes forcing through dark patterns and annoying banners that force you not to read), and withdrawal should be as simple as acceptance. GDPR article 7 and its variou
22.
by unscaled 2mo ago
Despite this being called a "cookie banner", this is not _just_ about cookie. When you click "Accept all" you are giving your consent to any form of tracking and information sharing mentioned in the details. The site you
23.
by unscaled 2mo ago
It doesn't even have to be something as bare-bones as pass. You can have a full-fledged password manager that is open-source and local-first. KeepassXC (and the OG Keepass) were always OSS and local-first. The original version of Keepa
24.
by unscaled 2mo ago
"supposed" is doing a lot of heavy-lifting here. According to who? The FIDO2 or Webauthn standards? Or in a perfect world? FIDO 1.0 started as two different standards: UAF and U2F. U2F was for USB keys used as second factors (so a
25.
by unscaled 2mo ago
Passkeys is basically a brand name for "discoverable credentials" (a Webauthn term). They do a little more than that technically, but in practice their purpose is what you said. Replace passwords. Or more accurately usernames and
26.
by unscaled 2mo ago
The FIDO set of standards (UAF, U2F which predated passwords and passkeys) haven't even started as enterprise standards. There are multiple origins for what became FIDO, but the main ones I know are: 1. PayPal was looking for a physica
27.
by unscaled 3mo ago
For what? For just authenticating a client application to a server without getting access to any user data? By all means. You usually don't need the client credentials in OAuth 2.0 if you don't want to use it. But if you want acce
28.
by unscaled 3mo ago
PKCE, OAuth 2.0 for Native Apps and the Device Code flow are a thing. In practice all of these clients work so well with OAuth 2.0, that the implicit and resource owner password credential grants have been removed from OAuth 2.1 and are the
29.
by unscaled 3mo ago
I wish I was young. Did I explicitly said TLS __1.3__ or did I not? A lot of effort was put into making TLS 1.3 a stronger, less agile and more misuse-resistant standard than its previous iterations. And that effort worked.
30.
by unscaled 3mo ago
True. But XSS stealing your token (which is always possible with localStorage) is still worse than XSS using your token. It's the principle of least privilege all over again.

More ›