@graves501 For me Rust is like nextgen C++ and Go is like nextgen userspace C. I do a lot of #Go #golang and #Cpp (because I have to) and while I tried #Rust I rather port things I can from C++ to Go because I hardly see any use of all that C++ “what if” abstraction anymore. Rather than rewriting 1:1 I enjoy shrinking and reducing them to simplicity. I quite enjoy Go and understand other folks enjoy Rust. It is nice we have choice and languages evolve.
Today I realized #Go and #Rust both have panics instead of exceptions and both originate from the second half of the 2000s.
These facts are now mentioned in https://gato-lang.dev/
If you have experience with Go or Rust, I'm interested in your thoughts on the lack of exceptions in these languages. It looks to me like an attempt to simplify things that eventually backfired, as evidenced for example by https://www.crowdstrike.com/en-us/blog/dealing-with-out-of-memory-conditions-in-rust/
｢ Go is the most hated programming language. Compared to other languages, it provides 80% of utility with 20% of complexity. The hate comes from people who want 81% of utility, or 85% or 97% ｣
https://blog.kowalczyk.info/article/d-2025-06-26/go-is-8020-language.html
small circle 🕊 in calmness
boosted
Despite traveling, I've been working on some things for #GoActivityPub and one of them is the ability to generate web optimized images when uploading JPG/PNG files.
The end result is an Image object containing multiple URL entries to small/medium web-optimized copies, plus the original.
This still requires some work on the frontend web components to be able to select from multiple variants based on the reported width/height.
But it also allowed me to fix issues with the ability of the library to process activities that contain multiple Objects.
Sigh. We are, as a security community, making good progress on some old as well as some new topics. #Rust, #Go, and other memory safe systems languages are going well and having a real impact in reducing memory safety issues - which has been the most important security bug class for decades, and we are finally improving! Compartmentalization and isolation of processes and services have now become common knowledge and the minimum bar for new designs. Security and privacy by design are being honored in many new projects, and not just as lip service, but because the involved developers deeply believe in these principles nowadays. #E2EE is finally available to most end-users, both for messaging and backups.
And again and again, we are forced into having discussions (https://www.theregister.com/2025/04/03/eu_backdoor_encryption/) about breaking all the progress.
Let me be clear for Nth time:
* We cannot build encryption systems that can only be broken by the "good guys". If they are not completely secure, foreign enemy states, organized crime, and intimate partners will break and abuse them as well. There is no halfway in this technology. Either it is secure or it isn't - for and against everybody.
* We cannot build safe, government-controlled censorship filters into our global messaging apps that are not totally broken under the assumption of (current or future) bad government policies and/or insider attacks at the technology providers (https://www.mayrhofer.eu.org/talk/insider-attack-resistance-in-the-android-ecosystem/). Either one-to-one communication remains secure and private, or it doesn't (https://www.ins.jku.at/chatcontrol/).
* We cannot allow exploitation of open security vulnerabilities in smartphones or other devices for law enforcement. If they are not closed, they are exploitable by everybody. "Nobody but us" is an illusion, and makes everybody less secure.
My latest recorded public talk on the topic was https://www.mayrhofer.eu.org/talk/secure-messaging-and-attacks-against-it/, and nothing factual has changed since then. Policymakers keep asking for a different technological reality than the one we live in, and that sort of thing doesn't tend to produce good, sustainable outcomes.
(Edited to only fix a typo. No content changes.)
CC @epicenter_works @edri @suka_hiroaki @heisec @matthew_d_green @ilumium