That page is an insult to their customers. So what, if I want to be protected from a security issue you acknowledge, I'll need to make modifications to my system configuration?
It’s interesting they call out as “optional” removing sectigo roots.
If you’re not removing them you better be sure anything that runs on the system has full revocation support including intermediates. Which is.. kind of an impossible thing to assert as true. Which is why most trust stores just removed that as well last week.
No, we would simply have to make spying illegal and require offenders criminally to pay restitution plus fines for each violation. You'd see vast improvements in folks' behavior pretty damned quick if people started getting thrown into jail AND bankrupted for spying.
Nah. There's a manager at my company that's pushing this, and it sucks for pretty much everyone except him. I suppose it's fine if you're delegating sprint management to AI agents, but everyone except the manager is going to be using this tool to manage sprints.
I agree there's a systemic failure, but think the article mischaracterizes the situation. Congress didn't pass the "aid to Russia" bill, for example. The article distracts from the real problems, at least in my opinion, for the sake of attention.
The 2022 bill to not buy Russia oil was passed 100-0 by the senate. I think most Americans are still on the side of the free world.
Trump on the other hand seems imperialist - Putin gets Ukraine, Trump gets Canada and the like. I'm hoping things get a bit more sane after the midterms.
Java lacks a ton of quality-of-life features that are table stakes in other languages, including C# and Kotlin. Auto-properties, async, extension methods, nullable reference types, primitive types, string interpolation/templates -- Java is inferior to C# in every one of these areas.
Java's approach to async is virtual threads. Extension methods are being explored through typeclasses. Solutions for nullability are also proposed, and in the mean time, you can use JSpecify. If by primitive types you mean value classes, they are going into preview in the upcoming JDK.
Java still inexplicably doesn't have first-class support for string interpolation/templates. They were slated to add it in Java 23, but they removed it from the preview and it hasn't been seen since.
Honestly, I still write a lot of perl, and while interpolation is nice and good to have for simple things, I find myself using sprintf more and more in production code, especially in the cases the examples always show off, such as needing to alter the variable, add two together, etc. I assume those are just shown to illustrate you you can do that, and not imply you should, because commonly using arbitrary code execution within interpolation is something I'd feel compelled to beat out of my coworkers if I encountered it regularly.
The point of (sane) string interpolation is that it runs at compile time, which helps prevent people from inventing crazy template systems at runtime. And you automatically get things like safe SQL queries with parameter binding instead of injection vulnerabilities.
> The point of (sane) string interpolation is that it runs at compile time, which helps prevent people from inventing crazy template systems at runtime.
It's the trivial cases that are compile time. The interesting templating is done with input that isn't defined within the source, and those can't be run entirely at compile time.
> And you automatically get things like safe SQL queries with parameter binding instead of injection vulnerabilities.
That's been solved for decades with parameterized queries (binding variables), and doesn't require interpolation in any way (at least not in the context we're using it here, but probably not at all in most DB drivers and engines). In fact, I would go so far as to say if someone is trying to use string interpolation instead of parameterized queries to avoid SQL injection, they've fundamentally misunderstood the problem and are trying to solve it at the wrong layer.
Also, if the string interpolation for the query is done at compile time, what type of content known at compile time is something that we'd be worried about SQL injection being in?
The "trivial" cases are also the cases people actually need like structured logging, sanitized HTML, and SQL.
SQL doesn't require interpolation, but it's much cleaner to write it that way and not have to explicitly do binding. It's not an "instead." Like I said, what the interpolator does is automatic safe binding with interpolation syntax.
The content known at compile time is the query template that you're binding. The point is a compile-time interpolator turns e.g. `sql"""select * from users where name=$name"""` into `Statement("select * from users where name=?").bind(name)`.
You can also have macro fragments as "inline def" functions in e.g. Scala so that they compose naturally. c.f. Quill[0].
Over a year your compile time interpolator would cost far more time, because even annotation processors and equivalent type technology do make a compile slower, than you typing the old way.
You're complaining about microseconds for a macro expansion. If you have to read and understand the code once ever (e.g. review it), you've saved time.
The thing that tends to be expensive for compilation, at least in Scala, is automatic recursive typeclass instance derivation. And even that one can be mitigated by just manually writing e.g. `implicit val jsonDecoder = JsonDecoder.derive[MyClass]` for each class. Otherwise compilation isn't an issue IME. Again, the time saved being able to work in "if it compiles, it works" mode easily dwarfs the time spent compiling.
Both forms are a line or two. It shouldnt cause headaches or make any difference in time or any other factor to read the more verbose version. There will always be compromises and less than optimal expressions in any code. One or two line differences like this should hardly matter.
SQL parameter bindings solve only one part of the problem, that of putting variables into value positions. They don't solve the problem of putting variables into name positions (you cannot "SELECT FROM ?" or anything like it), and they certainly don't solve the problem of dynamic SQL. This is somewhat orthogonal to the topic at hand, but the mentality should be that the problem space is still quite open, with the existing solution being a starting point, not an ending point.
At a glance, the string templating system they were trying out looked pretty good to me.
And clearly a lot of work and time went into it with the previews.
The fact that they pulled it back suggests they looked down deep into an abyss that looked back at them, and what they saw scared them.
I don't know if there has been a published deep dive post mortem on the whole string templating thing, but I am quite comfortable with the team yanking it out if they felt it wasn't right.
Syntax sugar still matters if you need to review the code. It was always about reading, not writing. Actually macros are even more powerful with LLMs. Metaprogramming has always been difficult for many (most?) programmers, but LLMs have no issue with it, and it's mostly doing the kinds of manipulations where as long as it compiles, it's correct, so you don't really need to review it in the same way.
The LLM itself is the metaprogramming, eventually we will be getting executables directly, the dream of previous AI Summers might finally materialise, with all the implications for the victims of software factories automation.
Getting it all to work nicely with easy syntax without breaking backwards compatibility at all is not easy. It's the same reason Option types don't take off in Java, as the effort to make them work in an environment with no features for null safety is going to break things.
It's a very conservative language that wants to minimize breakage, and the tradeoff is not without costs. I would argue than in LLM-world, the right tradeoffs change, but I don't think a language like Java is going to assume everyone has an LLM to do migrations for free any time soon.
That's basically what Linus said on the recent WAN show. People saw the launch announcement a while back, went "ok cool thing ya got. I don't care" and the was the end of that. People cared more about the magnetic usb-c than the product itself.
(Their review apparently performed pretty terribly relative to other videos they had at that time)
And yet, they never do.
reply