Do not rewrite in one shot, make small micro services in nodes and migrate from Django step by step.

This feels like an article from 2013.

If scale really mattered they should have rewriten it in Go, Java, C#, Rust....

Or if feeling fancy, Erlang, Elixir.

Do we still need ORMs in the age of AI-assisted coding?

I started ripping them out of a java system even before that.

Seems like there was solid ROI attached to this initiative…

Does this problem exist with fastapi as well?

BRO WTF

import { Skald } from '@skald-labs/skald-node';

const skald = new Skald('your-api-key-here');

// Create a memo const result = await skald.createMemo({ title: 'Meeting Notes', content: 'Full content of the memo...' });

// Chat with the memo const result = await skald.chat({ query: 'What were the main points discussed in the Q1 meeting?' });

I week from now you will be posted you rewrote your program in C++.

I had a python script I was writing that basically just needed to the same shell command 40 times (to clone images from X to Y) and a lot of the time was spent making the request and waiting for the data to be generated so I figured I'd parallelize it.

Normally I do this either through multiprocessing or concurrent.futures, but I figured this was a pretty simple use case for async - a few simple functions, nothing complex, just an inner loop that I wanted to async and then wait for.

Turns out Python has a built in solution for this called a TaskGroup. You create a TaskGroup object, use it as a context manager, and pass it a bunch of async tasks. The TaskGroup context manager exits when all the tasks are complete, so it becomes a great way to spawn a bunch of arbitrary work and then wait for it all to complete.

It was a huge time saver right up until I realized that - surprise! - it wasn't waiting for them to complete in any way shape or form. It was starting the tasks and then immediately exiting the context manager. Despite (as far as I could tell) copying the example code exactly and the context manager doing exactly what I wanted to have happen, I then had to take the list of tasks I'd created and manually await them one by one anyway, then validate their results existed. Otherwise Python was spawning 40 external processes, processing the "results" (which was about three incomplete image downloads), and calling it a day.

I hate writing code in golang and I have to google every single thing I ever do in it, but with golang, goroutines, and a single WaitGroup, I could have had the same thing written in twenty minutes instead of the three hours it took me to write and debug the Python version.

So yeah, technically I got it working eventually but realistically it made concurrency ten times worse and more complicated than any other possible approach in Python or golang could have been. I cannot imagine recommending async Python to anyone after this just on the basis of this one gotcha that I still haven't figured out.

python async is just a phase you grow out of and go back to mpsc where you don't see color and stack starts to make sense again.