Stefano Azzolini

Today #Typescript creator Anders Hejlsberg announced that they have started rewriting it in Go for a ~10x improvement in speed. It's a curious choice given Deno (a runtime that was created by the main figure behind Node.js), was initially written in Go but later changed to Rust. The reasons were: 💡Garbage Collector Issues: Go has a garbage collector, and so does V8. This could lead to potential conflicts between the two garbage collectors, which motivated the switch to Rust, which does not have a garbage collector. 💡Dependency Management: Rust offers better dependency management through its Cargo system, making it easier to integrate third-party libraries compared to C++. 💡Performance and Simplicity: Rust provides a way to express low-level machinery with simplicity, making it a better choice for Deno's needs. #Deno is a runtime. The #Typescript announcement is for the `tsc` compiler. `esbuild` is also written in Go. So is the majority of SRE tooling like Kubernetes, Prometheus, etcd, Grafana, Terraform, CoreDNS, etc. #Go has garbage collection whereas #Rust forces a paradigm that reduces memory waste. Both languages have a good performance for sure and a rewrite in either of them is bound to yield massive improvement compared to the current TypeScript implementation. Go has an smaller learning curve but if they picked Rust, #Deno would probably be happy! What do you think? https://lnkd.in/dAtXDfFf

58

5 commenti

"Two front-end developers are sitting at a bar. They have nothing to talk about." I first heard this quote from Chris Coyier in 2019 - but it feels even more relevant today. The idea is that that front-end has grown to cover so many different areas that it's *really hard* to be an expert at all of it. Some might be great at HTML/CSS and working closely with designers to implement slick designs and interactions. Others might be entirely focused on mastering a modern JS framework + metaframework to handle data fetching and building an architecturally sound front-end application. These are all important skills, but mastering everything is simply too much to ask of most front-end developers (especially juniors). That's why I think it's important to realize what you most enjoy working with, and then doubling down on that part. Of course it's great to have an understanding of both "ends" of the front-end. But to really excel your career, you probably have to narrow your focus ✌

932

99 commenti

This is some of the really fun distributed stuff I've been working on at Helsing — a robust, bandwidth-efficient, JSON-like CRDTs for communication in highly jammed, degraded and dynamic front-line networks. I'm so excited that we've now open-sourced the core CRDT Rust implementation based on the DSON paper (https://lnkd.in/duR8NCaF), and even though there's a bunch more sitting around it to make it practical, the primitives are essential building blocks that others can hopefully also make use of! Huge props to Oliver Wangler (the data systems team lead) and the rest of the team for the effort and excellent work in getting the system production-ready 🎉 You can find it on crates.io here: https://lnkd.in/dqT6DtjY Blog post with much more details on the why, what, and how here: https://lnkd.in/dB4frJEi

414

7 commenti

The power of open source lies in shared ownership. Anyone can suggest improvements through a pull request, helping shape the product they use every day. In the early days, every single pull request in Umbraco went through one person: Sebastiaan Janssen. He reviewed it. He approved it. He merged it. Even when a community team was formed to help, Sebastiaan was still the bottleneck. The only one allowed to “push the button.” That meant even strong contributions had to wait. So we changed it. For the past 5 years, the Core Collaborators Team (made up of trusted community members) has been able to merge changes themselves 🫣 Yes, some eyebrows were raised. Non-employees contributing code directly to a live product? That’s bold. But still to this day, Sebastiaan has only had to edit a pull request three times. That’s not just trust. That’s what a thriving open-source ecosystem looks like 🔓💛 #Umbraco #OpenSource

52

9 commenti

I’ve been using GitHub Copilot with VS Code and Visual Studio 2022 for the past couple of years. It’s been great for speeding up development and clearing mental blocks. Then I gave Codium a try—and it felt like a step up: smarter suggestions, better context, more flexibility. However, I recently switched to Cursor IDE—and this one is on another level. The way it blends chat, code, and navigation makes it feel like you’re working with an actual AI teammate. It’s super fluid and context-aware. The real standout? Advanced indexing. It “knows” your codebase and makes suggestions that just click. It’s smart in a way that feels… helpful, not intrusive. Yes, it’s a bit more expensive—but honestly, the productivity boost makes it well worth it. #CursorIDE #GitHubCopilot #Codium #VSCode #VisualStudio2022 #AIForDevelopers #CodeWithAI #DeveloperTools #ContextAwareCoding #ProductivityBoost

12

We faked a full-blown production incident with a customer to figure out who really owns the code.. 👇 Here’s what went down (and what we learned): This team had almost no documentation. Devs were constantly blocked. And as a result, incidents had spiked. And no one could confidently say who owned what. So we ran an experiment: 🔧 Worked with their CTO & simulated failures for every service in the stack 📞 Spun up a war room call ❓ Asked one question: “Who can fix this right now?” Whoever stepped up, that’s who actually owned it. We documented everything. The results? ⚡ 5 engineers were silently owning huge parts of the system, completely solo 🚨 Several services had zero clear owners It was a bold move, but it worked & in one afternoon, ownership across the codebase was finally visible Not the most scalable approach though, how have others uncovered who truly owns what?

555

257 commenti

"It's great working with an EM who cares so much about product," said Senior Product Manager Tanja Lembcke as my probation time at HelloBetter was ending. But I also could have flipped it onto her... 👀 Because "It's awesome working with a PM who cares so much about tech"; something at which she truly excels. Together, we're a strong force. Most of that relationship has happened quite naturally, but there are also things I've realised help us along in the process that I wanted to share with you all: product managers and engineering managers alike! 1. As a Team Lead or Engineering Manager, you need to act as the intersection of business goals, the engineers/team, and product. Not only should you be using your product, but you should also be critiquing it, actively asking questions about it, and constantly coming back to the "Why?". 🧐 2. As a Product Owner or Product Manager, you should be insisting on clear explanations of value for technical initiatives. That means forcing the engineers (or the EM) to explain to you, step-by-step, exactly what is happening and again... WHY. 👏 Don't let them get away with throwing tech terminology at you: get them to break it all down for you in a way you truly understand! 3. Come up with ways to build in technical initiatives: No tech stack is perfect, and no code is forever. Packages change, browsers and devices change, user needs change, and business needs change. You need to be structured in your planning, but leave significant space (I would say a minimum of 20%) for technical initiatives. And that's AFTER leaving buffer for bug fixes! 🐛 4. Constantly talk timing and priorities. Again, these can change at the drop of a hat, especially in an industry like healthcare and DTx where regulatory bodies can drop new requirements on you quite suddenly, or market opportunities suddenly appear. Every week, Tanja and I are discussing what's coming up, what's planned, what's changing, what needs to be bumped down. This is not just based on our own goals, but on those of the company at large. 🚀 5. You should both be absolutely upfront about what you don't know. EMs and PMs should be comparing notes on goals and priorities, but also on blockers and knowledge gaps. If you're still at the point of feeling like you have to pretend to "know it all" with your EM/PM, your partnership is not as strong as it should be. Be brave, and be the first to reveal your own weaknesses so you can bridge those gaps together. I promise it is much healthier and a much faster way to progress in your team's goals. 💪 --- What have I missed? What helps you to connect product and tech meaningfully in a team environment? #TechAndProduct #ProductEngineering #ProductManagement #EngineeringManagement

52

13 commenti

Blogged: Publishing NuGet packages from GitHub Actions the easy way with Trusted Publishing https://lnkd.in/emFPg-nV In this post I describe how you can use nuget's new Trusted Publishing feature to publish NuGet packages from a GitHub Actions workflow #dotnet #NuGet #GitHub

31

1 commento

On Thursday, Marvin Beckers and I will talk about Dynamic Multi-Cluster Controllers With Controller-runtime. Within sig-multicluster we are working on https://lnkd.in/dSnYsxxq, an extension of controller-runtime to write controllers that talk to many clusters. https://sched.co/1txFM

63

WaitGroup is leaving us 😞😞😞 With the new Go release, we might not require WaitGroup.Add and WaitGroup.Done. Earlier, to manage goroutines, we had to manually call wg.Add(1) before starting a goroutine and then signal completion with wg.Done(). Now, with the new wg.Go() feature, Go will handle all of that internally. Interestingly, this pattern has existed in the Uber Fx framework since day one 🫡🫡 Curious to hear your thoughts on this shift… Old method var wg sync.WaitGroup wg.Add(1) go func() { defer wg.Done() fmt.Println("go is awesome") }() wg.Add(1) go func() { defer wg.Done() fmt.Println("cats are cute") }() wg.Wait() fmt.Println("done") #golang #waitgroups

72

16 commenti

“Yet another bundler?” It’s a fair question. But Rolldown isn't just Rollup rewritten in Rust. It's a response to the real limitations teams face at scale. 💡 "We took inspiration from Rollup, ESBuild, and even Webpack, but what we needed just didn’t fit inside any one of them." On PodRocket, Alexander Lichter breaks down what motivated building Rolldown from scratch: 1️⃣ Rollup’s plugin ecosystem and friendly API set the standard, but can’t meet all modern demands. 2️⃣ ESBuild brings performance, but sacrifices flexibility. 3️⃣ Webpack’s approach to chunking and optimization still holds valuable lessons. The takeaway? Sometimes evolving the ecosystem means starting over. Listen to the full episode, where we discuss how Rolldown is trying to bridge the best of all worlds without adding more friction, by clicking one of the links down below. 🎧 YouTube: https://buff.ly/LD4mpo0 🎧 Spotify: https://buff.ly/yaIkWuA 🎧 Apple: https://buff.ly/CHaUZkH

18