HN user
That is basically true for every such system. Trust Signal? They could ship a backdoor in the next release. Same with Threema, WhatsApp (if you want to trust it today) and other services. You can expand that to the operating system as well. And who able to verify hardware security, anyway?
The right reason to hate XML would be some technical limitation or technical issues with it. But XML works quite well and is reasonable powerful. So the complaints usually boil down to: It is ugly and verbose.
Interesting point of view. JSON is also not the right thing to use in many scenarios, but it is the de-facto standard now. Maybe something like protobuf is the way to go.
At least XML is hated for the wrong reasons (e.g. verbosity, esthetics) most of the time. There was for sure an era where it was overused (see Apache Cocoon from 2006 https://en.wikipedia.org/wiki/Apache_Cocoon). But XML is still a pretty good format to exchange (and store) data and make sure the data conforms to a certain schema. JSON Schema in comparison is not nearly as powerful.
Maybe Peter Thiel and Elon Musk will meet again cryogenically preserved ;-) https://fortune.com/2023/05/04/peter-thiel-cryonics-cryogeni...
Everything will be folded in "X" eventually, anyway.
Looks good, but I'm not sure about security: https://bearyangry.com/2026/04/29/carrot-disclosure-forgejo-...
It works as long as your are the only user. Sharing passwords with shared keepass files didn't work properly for me. It was the main reason to move to 1Password (and I never looked back).
Passbolt https://www.passbolt.com/ might be an interesting alternative. The feature set looks pretty good at first sight. The only real downside I see so far is that it doesn't have macOS and Linux apps. Other than Bitwarden it is real open source.
It is limited to ... well ... Firefox! Sometimes you need passwords elsewhere. Besides that Firefox (or other browser password managers) doesn't support more advanced use cases like shared vaults.
I think that Java has a really good solution to offer: Virtual Threads. They share the same interface with native threads and free developers from the burdens of async programming. You only need to take care of some things like accidental thread pinning (through legacy code) and the use of ThreadLocal, but otherwise this complexity is hidden.
https://docs.oracle.com/en/java/javase/21/core/virtual-threa...
Might be true, but Subversion was also good enough and a de-facto standard.
`var` has nothing to do with dynamic typing. It is still statically (compile time) typed, so the type can not change at runtime. Compare that to JavaScript where you could easily switch the type of a variable from Number to String.
It is not like auto-wiring would turn Java magically into a dynamically typed language!
In my opinion Helidon is the most refreshing of these frameworks. It supports virtual threads from the ground up and comes with clean, function, mostly annotation free APIs. It really looks like a Java framework should look today.
Windows reputation is declining, so the operating system might be the actual crisis. Linux with modern desktops (e.g. Gnome 3) might fill the gap, but the market is far from broad adoption. Promoting and improving Linux desktop and apps would be a long endeavour, but betting only on Windows which degrades to a cloud and AI advertising surface might be fatal.
I fear that a redesign won't help in this (terminal) stage.
Do have any links to back this up? I'd be really interested.
Gradle could be used as an AI benchenmark on its own! The syntax of plugin DSLs changes all the time. Special credits could be achieved for handling old (Groovy) and new versions (Kotlin) of Gradle itself.
However, the cause it not really Java as such, but massive frameworks and tooling (e.g. Maven). Maybe AI will bring some fresh air to Java, because old truths might no longer be valid. But it will be hard to get rid of old habits because it manifested in AI training data.
Project Lombok rewrites code, however it misuses annotation processing.
My takeaway is that Go almost always prefers simplicity and not so much good software engineering. `nil` without compiler checks is another example, or designing a new language without generics. However the overall simplicity has its own value.
I don't like Bitwarden UI/UX. It looks not really polished. Especially the "folders" are akward. How the implemented it, calling them labels and designing them like labels would make way more sense. But the whole UI looks like software developers - and not designers - built it.
In the end, even Java code becomes machine code at some point (at least the hot paths).
This statement makes the Copilot key on newer keyboards even more questionable!
Nobody would spend the whole day typing on a virtual keyboard, so that change makes a lot of sense to me.
As others already pointed out, UUIDv7 is a solid choice and if you don't like the default representation, you can encode the underlying byte array with base62 for example, to get short, URL-friendly IDs.
That is not quite true. Google did much of the research OpenAI used to build ChatGPT. It is just that OpenAI came up with the first popular mainstream AI tool.
Just look what Google does with its Tensor Processing Units ... they are developing AI chips for a decade now!
... and now we have this damn copilot key on our keyboards!
This story reminds of Scala. The language as such is also fine, but has (had?) a cultural problem. There functional programming fundamentalists always promoting the purest solution without solid reasoning - as if god had decided that only pure functional programming is your ticket to paradise. In addition, Scala comes also with powerful language features to build abstractions, like traits, generics, and almost arbitrary names for classes, objects, and functions. All that lead to a culture of unreadably "try to be clever" code. I'm not sure whether the Scala authors paved the way with methods like :\ (fold left) or whether that happened, because the language had the features, but I tend to assume the latter. It is a great responsiblity of a language designer to think about what others might do with the language later. Regarding language features the rule "when in doubt, leave it out" applies. See Go (although not my favorite language).