Sonarqube did not flag public fields as a security issue by default the last time I used it — however it has found several real vulnerabilities for me before.
It did by default for me, and there are a bunch of other poorly implemented analyses, such as it incorrectly flagging Dictionary keys in C# as mutable, or opinionated stuff like it disliking certain names and patterns, forcing me to make arbitrary changes that often cost performance, readability or API cleanliness.
Or insane stuff like it doing a blanket-ban on security related code in the app (but importing a third party lib that does the same is fine).
The analyses in general are low quality and you can see not a lot of effort or thought went into them.
They are not the product - compliance, and dashboards for boomers is.
I'm curious about what did it detect for you? In my experience it stops very obvious bad patterns like using string manipulation to submit SQL (which in certain circumstances might even be fine, even necessary), but it can't really trace non-obvious security issues (like tracing a value through the code, making sure its valid on every codepath), it just doesn't have the compiler machinery to do that.
Same name, mostly same internal components, different chassis (mostly bigger) afaik. Same for Fiesta's except for some models (e.g. ST). I know for the Fiesta since the electronics are the same but the dash components are made for a bigger chassis (to make it fit you have to dremel quite a bit).
No point. Claude Code with skills and subagents is plenty. If they would stop breaking it constantly it would be fine.
The bottleneck has not been how quickly you can generate reasonable code for a good while now. It’s how quickly you can integrate and deploy it and how much operational toil it causes. On any team > 1, that’s going to rely on getting a lot of people to work together effectively too, and it turns out that’s a completely different problem with different solutions.
Checked exceptions are proper errors as data. There is no difference between Result[T, E] and T throws E. The same people that just rethrow as RuntimeException would call unwrap() on Result and panic. The main problem with _Java_'s implementation of checked exceptions is that they're not fully in the type system because of Java's weak type system. That is solvable with a strong type system though, like in Scala or Swift.
You can misuse the errors as data paradigm just like you can misuse checked exceptions. That doesn't make either paradigm bad, it makes the programmers who misuse them bad.
It's not just for security, it's also for maintainability. Frankly being able to reflect across package boundaries has always seemed like a misfeature for maintainability to me. The code you have that is broken by Java 9 was already badly behaved, the JVM was just lenient about it.
pro tip: don't bother with SDKMAN. use https://mise.jdx.dev to install Java, it can also install a bunch of other languages and tools. it's most likely the last tool version manager you'll ever need.
I found the documentation confusing and as so often with general-approach tools too overwhelming for what I'm trying to do. sdkman works fine for what I need it for and usually you only need one instance of gradle and maven installed.
And sdkman is written in rust and only needs curl, zip and unzip, no JVM.
I meant for focused on compilation speed to apply only to lower level languages. And when I say lower level I don’t really include D because it has a garbage collector (I know it’s optional but much of the standard library uses it I believe).
That a language has a garbage collector is completely orthogonal to whether it has type inference ... what the heck does it matter what "much of the standard library uses" to this issue? It's pure sophism. Even C now has type inference. The plain fact is that the claim is wrong.
The x axis is orthogonal to the y axis, so I can’t be interested in the area where x < 1 and y = 5?
> what the heck does it matter what "much of the standard library uses" to this issue?
It matters in that most people looking for a low level manually memory managed language won’t likely choose D, so for the purposes of “is this relatively novel among lower level, memory managed languages” D doesn’t fit my criteria.
> Even C now has type inference. The plain fact is that the claim is wrong.
reply