Reddit Programming
201 subscribers
1.22K photos
126K links
I will send you newest post from subreddit /r/programming
Download Telegram
Designing a Python Language Server: Lessons from Pyre that Shaped Pyrefly
https://www.reddit.com/r/programming/comments/1s2bw68/designing_a_python_language_server_lessons_from/

<!-- SC_OFF -->Pyrefly (https://github.com/facebook/pyrefly) is a next-generation Python type checker and language server, designed to be extremely fast and featuring advanced refactoring and type inference capabilities. Pyrefly is a spiritual successor to Pyre (https://pyre-check.org/), the previous Python type checker developed by the same team. The differences between the two type checkers go far beyond a simple rewrite from OCaml to Rust - we designed Pyrefly from the ground up, with a completely different architecture. Pyrefly’s design comes directly from our experience with Pyre. Some things worked well at scale, while others did not. After running a type checker on massive Python codebases for a long time, we got a clearer sense of which trade-offs actually mattered to users. This post is a write-up of a few lessons from Pyre that influenced how we approached Pyrefly. Link to blog: https://pyrefly.org/blog/lessons-from-pyre/ The outline of topics is provided below that way you can decide if it's worth your time to read :) - Language-server-first Architecture - OCaml vs. Rust - Irreversible AST Lowering - Soundness vs. Usability - Caching Cyclic Data Dependencies <!-- SC_ON --> submitted by /u/BeamMeUpBiscotti (https://www.reddit.com/user/BeamMeUpBiscotti)
[link] (https://pyrefly.org/blog/lessons-from-pyre/) [comments] (https://www.reddit.com/r/programming/comments/1s2bw68/designing_a_python_language_server_lessons_from/)
Don't Count Java out Yet
https://www.reddit.com/r/programming/comments/1s2gjgv/dont_count_java_out_yet/

<!-- SC_OFF -->I remember when I first started working, I loved visiting this old mainframe building, where the "serious" software engineering work was being done. The mainframe was long-gone, but the hard-core vibe of the place still lingered. As I took any excuse to walk past a different part of the building to try and sneak a peek into whatever compute wizardry I imagined was being conjured up, one thing I always noticed was copies of InfoWorld being strewn across desks and tables (and yes, even in the bathroom - hey, I said it was hard-core ;-) ). I guess those days are mostly over now, but it's nice to see that there is still some great writing going on at InfoWorld (https://www.linkedin.com/feed/?shareActive=true&url=https%3A%2F%2Fwww.infoworld.com%2Farticle%2F2335996%2F9-reasons-java-is-still-great.html&shareUrl=https%3A%2F%2Fwww.infoworld.com%2Farticle%2F2335996%2F9-reasons-java-is-still-great.html#) by some talented and knowledgeable authors. Matt Tyson (https://www.linkedin.com/feed/?shareActive=true&url=https%3A%2F%2Fwww.infoworld.com%2Farticle%2F2335996%2F9-reasons-java-is-still-great.html&shareUrl=https%3A%2F%2Fwww.infoworld.com%2Farticle%2F2335996%2F9-reasons-java-is-still-great.html#) is definitely one of them and this is a great piece on why despite the #rust / #golang / #elixir craze, #java is still the language and framework to beat. (One of these days I'm going to finally learn #spring and re-join the java club.) <!-- SC_ON --> submitted by /u/scottedwards2000 (https://www.reddit.com/user/scottedwards2000)
[link] (https://www.infoworld.com/article/2335996/9-reasons-java-is-still-great.html) [comments] (https://www.reddit.com/r/programming/comments/1s2gjgv/dont_count_java_out_yet/)
Malicious litellm 1.82.8: Credential Theft and Persistent Backdoor
https://www.reddit.com/r/programming/comments/1s2h4by/malicious_litellm_1828_credential_theft_and/

<!-- SC_OFF -->litellm, a famous python package got compromised and it executes on your system without even importing it — cloud creds, SSH keys, K8s secrets, crypto wallets, env vars and what not, all exfiltrated to the attacker's server. Full technical analysis: https://safedep.io/malicious-litellm-1-82-8-analysis/ <!-- SC_ON --> submitted by /u/No_Plan_3442 (https://www.reddit.com/user/No_Plan_3442)
[link] (https://safedep.io/malicious-litellm-1-82-8-analysis/) [comments] (https://www.reddit.com/r/programming/comments/1s2h4by/malicious_litellm_1828_credential_theft_and/)
Litellm 1.82.7 and 1.82.8 on PyPI are compromised, do not update!
https://www.reddit.com/r/programming/comments/1s2h8lt/litellm_1827_and_1828_on_pypi_are_compromised_do/

<!-- SC_OFF -->We just have been compromised, thousands of peoples likely are as well, more details updated IRL at the link Update: Callum McMahon, who discovered this, wrote an explainer and postmortem going into greater detail: https://futuresearch.ai/blog/no-prompt-injection-required <!-- SC_ON --> submitted by /u/ddp26 (https://www.reddit.com/user/ddp26)
[link] (https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/) [comments] (https://www.reddit.com/r/programming/comments/1s2h8lt/litellm_1827_and_1828_on_pypi_are_compromised_do/)
Why Raft can’t safely commit old-term entries — from an implementation/debugging perspective
https://www.reddit.com/r/programming/comments/1s32qin/why_raft_cant_safely_commit_oldterm_entries_from/

<!-- SC_OFF -->I recently finished the MIT distributed systems labs and wrote up one Raft rule that took me some time to fully understand: why a leader cannot safely commit old-term entries just because they’re replicated on a majority. When reading the paper, this can feel like a detail you just accept and move on from. But during implementation/debugging, it becomes much more concrete. You start seeing why “replicated on a majority” is not enough by itself, and why the current-term restriction matters for safety. I tried to explain it from the perspective of someone implementing and debugging Raft, not just restating the theory. Article: https://abdellani.dev/posts/2026-03-23-why-raft-cant-safely-commit-old-term-entries/ I’d be curious how this clicked for others:
did it make sense immediately from the Raft paper, or only after implementing/debugging it? <!-- SC_ON --> submitted by /u/am0123 (https://www.reddit.com/user/am0123)
[link] (https://abdellani.dev/posts/2026-03-23-why-raft-cant-safely-commit-old-term-entries/) [comments] (https://www.reddit.com/r/programming/comments/1s32qin/why_raft_cant_safely_commit_oldterm_entries_from/)
How the TeamPCP attack exploited CI/CD pipelines and trusted releases to release infected Trivy and LiteLLM packages
https://www.reddit.com/r/programming/comments/1s35ohw/how_the_teampcp_attack_exploited_cicd_pipelines/

<!-- SC_OFF -->TeamPCP attack shows how CI/CD can be abused by compromised pipelines to compromised repos to push out infostealers in the packages. Most notable ones were Aquasec's entire GitHub acc including Trivy repo and LiteLLM python package. <!-- SC_ON --> submitted by /u/raptorhunter22 (https://www.reddit.com/user/raptorhunter22)
[link] (https://thecybersecguru.com/news/teampcp-supply-chain-attack/) [comments] (https://www.reddit.com/r/programming/comments/1s35ohw/how_the_teampcp_attack_exploited_cicd_pipelines/)
GitHub will use your repos to train AI models
https://www.reddit.com/r/programming/comments/1s45lme/github_will_use_your_repos_to_train_ai_models/

<!-- SC_OFF --> Important update On April 24 we'll start using GitHub Copilot interaction data for AI model training unless you opt out. Remember to opt-out fellows engineers. Important correction: As many of you noted, the title of the post is misleading. This update will impact only "GitHub Copilot interaction" and not "all your repos". Direct opt out link: Direct opt out link <!-- SC_ON --> submitted by /u/Ok-Lifeguard-9612 (https://www.reddit.com/user/Ok-Lifeguard-9612)
[link] (https://github.com/) [comments] (https://www.reddit.com/r/programming/comments/1s45lme/github_will_use_your_repos_to_train_ai_models/)