Readit News logoReadit News
redcannon218 commented on Rust is a great fit for the agentic era   kerkour.com/rust-agentic-... · Posted by u/randomint64
redcannon218 · 2 months ago
TL;DR: Programming agents need strong typing and compiler-enforced correctness to get feedback.
redcannon218 commented on Why I Use a Dumbphone in 2025 (and Why You Should Too)   samueleamato.xyz/2025/06/... · Posted by u/rd_wei
redcannon218 · 3 months ago
The claims about privacy are, at best, dubious.

While it's true that there are less opportunities to track you through leaky / malicious apps, "dumbphones" remain, well, phones, with data retention laws in almost all countries in the world (and the subsequent leaks / hacks, see the recent Salt typhoon events for a good example) plus extra vulnerabilities due to poorly-developed Operating Systems.

redcannon218 commented on AES and ChaCha   phase.dev/blog/chacha-and... · Posted by u/nimishk
miloignis · 5 months ago
I'm curious if there are any good benchmarks of ChaCha8 (as advocated for in the "Too Much Crypto" paper https://eprint.iacr.org/2019/1492.pdf ) vs hardware-accelerated AES.

The best I could find was a rough 2.5x speedup of ChaCha8 vs ChaCha20 in the "Too Much Crypto" paper and https://github.com/jedisct1/rust-aegis#benchmarks that benchmarks ChaCha20 and various AES implementations in addition to AEGIS, where it looks like ChaCha8 might be competitive with hardware-accelerated AES on some platforms (AMD) but not others (M1).

redcannon218 · 5 months ago
My benchmarks are not public, but on AMD EPYC processors ChaCha12 (5 GB / s) is faster than hardware-accelerated AES-256-GCM (3.5 GB / s).

Unfortunately, this is comparing apples to oranges because AES-256-GCM is authenticated, so you will need a MAC with ChaCha12 (usually Poly1305) which finally makes ChaCha12 in AEAD mode slower than AES-256-GCM.

But the real question is: What is fast enough?

I believe that between 1 and 2 GB / s per core for an AEAD is fast enough as I/O will be your bottleneck way before that.

This is why I will always favor a ChaCha20/ChaCha12-based AEAD over AES and its many footguns.

redcannon218 commented on Evolving Scala   scala-lang.org/blog/2025/... · Posted by u/pjmlp
pkolaczk · 5 months ago
1. Rust has had 10x better tooling right from the start. Cargo vs SBT, no joke.

2. Rust has improved its compiler performance by >3x in the last 5 years.

3. Rust hasn't gotten any major new language feature in the last 6 years. Most language improvement is improving orthogonality of existing features.

4. Rust has an excellent backwards compatibility story also right from the start. Code/libraries written in 2015 can be still compiled and used together with code from 2025.

5. Rust has a serious backing from all major IDE / editor providers.

6. Rust has integrates easily with other languages and ecosystems. It's easier to call Rust from Python than to call Scala from Python. It's easier and more performant to call C from Rust than to call C from Scala. Things like that. It's sad that Scala even struggled with interoperability with Java; which should theoretically be easy as it is the same platform.

Seriously, doesn't look to me like the same mistakes. It's actually quite opposite.

redcannon218 · 5 months ago
I need to hash something, one way or another, in virtually 100% of my projects. Where is SHA-256 in the standard library?
redcannon218 commented on Evolving Scala   scala-lang.org/blog/2025/... · Posted by u/pjmlp
culi · 5 months ago
Rust is younger than Scala. It makes sense for it to still focus on features
redcannon218 · 5 months ago
But Go has proven that the ecosystem is way more important than the language.

It's time to shift priorities.

redcannon218 commented on Evolving Scala   scala-lang.org/blog/2025/... · Posted by u/pjmlp
pas · 5 months ago
Care to elaborate on which changes do you consider a mistake?

---------

To me the goals are sensible the flagship goals (for 2025H1 for example [1]) are all about DX and focus on downstream devs and their needs (all hands, Rust in the kernel).

The usual problem of "compile times" [2] (usually link times and LLVM throughput and so on) are things that are being worked on, but fundamentally they all can only be solved by caching, incremental compilation, and better developer tooling that are not language problems.

[1] https://rust-lang.github.io/rust-project-goals/2025h1/goals....

[2] https://old.reddit.com/r/rust/comments/1if5wpm/high_hopes_fo...

redcannon218 · 5 months ago
Please see my edit
redcannon218 commented on Evolving Scala   scala-lang.org/blog/2025/... · Posted by u/pjmlp
epolanski · 5 months ago
> Another common request is to “stop implementing features”.

Yes, it's a very common one shared by virtually all Scala 3 developers. Stop. At least for a couple of years.

Tooling and the community just can't keep up and the language is very good already that the focus should be on the ecosystem and not language.

But Scala devs are beyond deaf and that's what you get when a programming language is an ongoing research project on which many students and professors depend.

It's not enough to say "if we stop developing new features the language will die" when there's 0 evidence by it and a huge fatigue towards the relentless development coming from most of the community.

redcannon218 · 5 months ago
Unfortunately Rust is making the exact same mistake.

Edit: It focuses too much on the language instead of the ecosystem.

u/redcannon218

KarmaCake day13December 9, 2024View Original