HN user

smashedtoatoms

179 karma
Posts0
Comments45
View on HN
No posts found.

I'm editing this to be nicer. I'm really trying to be nicer. Consider the possibility you're not the only one in the codebase and that the git history might provide the why to the code's what.

All that said, you .NET folks need to let your patterns die in a fire. Modern C# doesn't require any of this crap anymore. Use functions. They're great. The world of nouns is behind us.

I'd have written this exact comment two years ago. After two years using C# and .NET in anger, I'd pick it for almost any project. It's better than Python, Ruby, Go, Elixir, Typescript, Etc. and better than Rust unless you absolutely must squeeze every ounce of performance out of something, and even then, sometimes C# is better.

I know it's not cool, but I spend very little time on distracting stupid shit in C#. No other ecosystem does it as well as .NET. It seems like such a low bar, yet almost no one can get over it.

I sit down to program for what feels like 30 minutes in a moment of inspiration, and I look up and it's been 5 hours and I got more done than I was expecting. Every other language often has me dealing with some distraction having nothing to do with the actual problem I'm hoping to solve, and sometimes robbing me of the desire to solve the problem at all.

Other languages drive me to mess with my editor config, because it's more fun than trying to convince my environment that a business problem is more important to solve than why some dependency that was importing fine a week ago is now broken. Other languages have me trying to get AI to build me something I've built before without typing any code. C# wants me to ship something quickly that works and it wants to help me do it. It's a remarkable ecosystem, and it makes it really hard to put up with the hoops the others make me jump through. 5/5, would .NET again.

Yeah, .NET developers have been passing CancellationTokens around in the places where they have needed them for 15 years. The tokens are basically invisible until their existence emerges when someone decides they want to cancel a long-running API call or something. At that point, they are plumbed as deeply as seems fit for the problem at hand and then hardly thought about ever again. CancellationTokens are generally a delightful pattern, especially when the language allows sensible defaults.

"It's not exactly making me feel valued as a community member"

Neither is not getting paid for work/services. If one works hard on things and can't pay their bills, that's unsustainable. Why is developer time worth nothing to other developers? If you can write it and host it, do it. If you can't, and the folks that can charge for it, hand over your credit card so they can continue to do it. Or watch it die when they have to abandon it to make a living writing code for someone that will pay for it I guess.

No one owes us their time and effort for nothing.

I came here for the bad takes, and I have not been disappointed. Dynamo slays when you know your access patterns and need consistent performance and no operations requirements. Turns out, that's the case most of the time. Think about it as application state instead of a db. It's not key-value like Redis. GSIs with compound keys allow access to data across multiple dimensions on virtually unlimited data with consistent performance. Its weakness is querying data across dimensions you didn't plan on. If you need that regularly, it sucks. If you need that once in awhile, write a migration.

People act like managing lots of git repos is hard, then run into monorepo problems requiring them to fix esoteric bugs in C that have been in git for a decade, all while still arguing monorepos are easy and great and managing multiple repos is complicated and hard.

It's like hammering a nail through your hand, and then buying a different hammer with a softer handle to make it hurt less.

This article is the what, but it is missing the why. I'm supremely biased against scrum, so basically ignore what I am saying if you're a fan of it. Fundamentally, Kanban is pull-based, and Scrum is push-based. That's the difference.

Scrum spends time determining how long things will take, and then attempts push it into a schedule via story pointing and other ceremony where people pretend they're not guessing how long thing will take by using points and t-shirt sizes and anything other than time to guess how much they can get done in some arbitrary amount of time. Then devs do what they were going to do anyway, and everyone slaps each other on the back because they're measuring the success they're having. It's a dream for people who like to count things and build check lists and check them off. Its success has little to do with the process and much to do with the team's ability to gather requirements and do their job. It's ideal for contract gigs where it's as important to track how much time it takes you to do things as it is to actually do things.

In Kanban you put what you want to do in a list, and pull the things from the list in order as you complete them. If customers need things quicker, you change the order of things in the list while communicating to them what will slip and what will accelerate. They take as long as they take (because that's how the world works, yes, even in scrum), but with 100% less ceremony and pointless coordination. Kanban is about constantly managing constraints and eliminating waste. You don't need to strictly measure how long things are taking. You pay attention when things don't move off the board, and modify resourcing in whatever way will get things unstuck. It's less fun because you don't get to pretend you know how long something will take, but it's more fun because you get to be an adult professional instead of a servant to the processes of people who don't actually build things.

This is somewhat tongue-in-cheek, but in my career I've never seen switching to pull-based patterns make things worse, and I've often seen them make things better, including morale. It doesn't seem like it will work, but in practice there are so many efficiencies gained in pull-based processes that it usually ends up being faster and feeling better while doing it.

The clustering is what makes it feel so different, and what makes it such a compelling runtime for certain types of problems.

It's not an accident that large distributed chat programs or MQ systems are often written in erlang. From inside the code, writing a distributed system feels the same as working on one node.

With go, you can't do channels to a go process running on a different server without significantly changing the language. In erlang, you don't notice because that's just how it works.

Write an app that runs on two nodes and sends updates to all clients via websockets. In erlang, you just write it. In EVERY other language, you're loading a non-idiomatic library and probably running an MQ cluster or using an MQ service... probably written in erlang.

Because what we need is more of the what was done, with no regard to the why. Why provide any context as to why the change was made when you can fill it with an AI description of what one could accurately tell by looking at the code? I kinda can't believe this isn't a joke. Just squash it to the emoji that best captures the sentiment! Why use the tool to enhance you and your peers lives, when you can use AI to make it pointless!

SBCL 2.2.8 4 years ago

I made an asdf-vm installer for it that I've been keeping up to date: https://github.com/smashedtoatoms/asdf-sbcl

If you don't want to use it, it installs from source, so you might be able to look at the source to see an example of how to build it yourself. It works on intel and arm macs.

I have worked in FAANG and in 10 person startups and have paired in them all. VSCode is fine if you're all using VSCode and don't need to screen share anything outside of VSCode. If everyone is on mac though, there is nothing better than Tuple that I have used. If one party uses IntelliJ and another uses vim, and you need to have a db client or browser or something open as well, Tuple is fantastic.

You can use Common Lisp with VSCode pretty easily now with the Alive plugin. It uses SWANK under the hood, but you don't NEED emacs anymore for Common Lisp. You can also use Calva with Clojure and vscode. The emacs requirement is slowly going away. You get all the perks of hacking live running systems, no emacs required.