171–180 of 197 posts
Earlier quoted context omitted.
It has one - it’s been a part of the JDK for a while https://docs.oracle.com/en/java/javase/11/docs/api/jdk.https...
sun is typically not available anymore / deprecated even and not available in the JRE or it's early access, but fair point.
Earlier quoted context omitted.
Upon reflection, my comfort with sqlalchemy, diesel, C++ STL, and vibe coding all share one thing in common - I am pretty comfortable liking to code at a high level that is productive, while at the same time going deep to know what the abstractions produce under the covers. E.g. I at least spot check my vibe coded code, I spot check the assembly from C++ STL to ensure zero cost abstraction, I spot check the SQL from…
Thanks for taking the time! I love being able to see through abstractions too, but for web applications I'm looking for a bit more "magic" (e.g., .NET's EF Core is the gold standard for what I'd look for in an ORM).
Earlier quoted context omitted.
> I mean somebody could make a singular rust dependency that re-packages all of the language team's packages. That's not the requirement though! Curation isn't about packaging, it's about independent (!) audit/test/integration/validation paths that provide a backstop to the upstream maintainers going bonkers. > But what's the threat model here. A repeat of the xz-utils fiasco, more or less precisely. This was a succe…
> A repeat of the xz-utils fiasco Wasn't that a suspected state actor? Against that threat model your best course of action is a prayer and some incense. Notably, xz utils didn't use any package manager ala NPM and it relied on package management by hand. > because the downstream Debian folks Not sure what you mean by this, but this was discovered by a Postgres dev running bleeding edge Debian. No Debian package main…
No? They caught it! But they did so because the software had extensive downstream (!) integration and validation sitting between the users and authors. xz-utils pushed backdoored software, but Fedora and Debian picked it up only in rawhide/testing and found the issue.
> Notably, xz utils didn't use any package manager ala NPM and it relied on package management by hand.
With all respect, this is an awfully obtuse take. The problem isn't the "package manager", it's (and I was explicit about this) it's the lack of curation.
It's true that xz-utils didn't use NPM. The point is that NPM's lack of curation is, from a security standpoint, isomorphic to not having any packaging regime at all, and equally dangerous.
> a Postgres dev running bleeding edge Debian
Exactly. Not sure how you think this makes the point different. Everything in Debian is volunteer, the fact that people do other stuff is a bonus. Point is the debian community is immunized against malicious software because everyone is working on validation downstream of the authors.
No one does that for NPM. There is no Cargo Rawhide or NPM Testing operated by attested organizations where new software gets quarantined and validated. If the malicious authors of your upstream dependencies want you to run backdoored software, then that's what you're going to run.
Earlier quoted context omitted.
I just ported (this week) a 20-year-old Python app to uv/polars. (With AI it took two days). App is now 20x faster.
that's polars for ya uv should not impact runtime performance at all
Earlier quoted context omitted.
sun is typically not available anymore / deprecated even and not available in the JRE or it's early access, but fair point.
I get what you’re saying but this is actually a public api in HotSpot. It was provided in JEP 408: https://openjdk.org/jeps/408
but to clarify, this was about a year ago where I struggled to find an auto completion for HttpServer and when I searched it up jdk HttpServer was simply not in the results so I made assumptions that were wrong.
Earlier quoted context omitted.
java didn't have an http client [...] and STILL doesn't have an http server. Wow. How long has it been since you guys have used Java? Serious question?
I tried to implement a minimal server just to realize that there is still no way to do so in java 21... I stand corrected I guess it was recently added: https://docs.oracle.com/en/java/javase/25/docs/api/jdk.https... , but it's a sun package instead of standard RT - but probably because it is still early.
Earlier quoted context omitted.
Lisp is the master of all. Or it would be except "Parens? Eugh! Brotha, eugh!"
Lisp lost because none the the Lisperati came down from on high and deigned to explain how to use it for tasks running on the 1980s microcomputers. Lisp also lost because the 1980s Lisperati spent all their time explaining lists and recursion over and over instead of explaining hash tables, vectors, and iteration. Somehow, Lisp lost out to pathetically slow BASIC interpreters and C compilers that you had to swap flop…
Earlier quoted context omitted.
> The tradeoff Go made is that certain code just cannot be written in it. Uh... yeah? That's true of basically all platforms, and anyone who says otherwise is selling something. > it gets painful once you leave that path Still less painful than being zero-day'd by a supply chain attack.
> > The tradeoff Go made is that certain code just cannot be written in it. > Uh... yeah? That's true of basically all platforms, and anyone who says otherwise is selling something. What code can you not write in C? Might be painful for some(many) cases, but there is nothing you can't write in C.
This falls under the "selling somthing" angle I mentioned. Yes yes yes, generality and abstraction are tradeoffs and higher level platforms lack primitives for things the lower levels can do.
That is, at best, a ridiculous and specious way to interpret the upthread argument (again c.f. "selling something").
The actual point is that all real systems involve tradeoffs, and one of the core ones for a programming language is "what problems are best solved in this language?". That's not the same question as "what problems CAN be solved in this language", and trying to conflate the two tells me (again) that you're selling something. The applicability of C to problem areas it "can" solve has its own tradeoffs, obviously.
the idea of one language to rule them all is very compelling. it’s been promised a lot, and now everyone hates Java. but the truth is that Rust is not meant for everything. UI is an abstraction layer that is very human and dynamic. and i can come and say, “well, we can hide that dynamism with clever graph composition tricks” à la Elm, React, Compose, etc, but the machinery that you have to build for even the simplest…
speak for yourself :-)
But sadly Java can't rule them all because there is no browser story and no IOS story.
The TS/React ecosystem is so mature, it's hard for Rust to compete with it. My optimal stack is currently: Rust on the backend, Typescript/React for web with OpenAPI for shared types.
What's a better alternative for shared types? OpenAPI is really outdated and the tooling is always a mess. There is ts-rs [1], but it's only for TS. [1]: https://docs.rs/ts-rs/latest/ts_rs/