11 ms·
Why we migrated from Python to Node.js
- inerte 1y agoLooks like last week was coding week, current one is marketing week.
- goalieca 1y agoIt sounds like they are just saying they should have used the tool they were most familiar with on day 1.
- pier25 1y agoThey did. That's why they used Django.
- y1426i 1y agoWe did the same for our app as well. I wrote a little library to make it as simple as FastAPI to generate swagger specs - you can try it out - https://github.com/sleeksky-dev/alt-swagger https://github.com/sleeksky-dev/alt-swagger .
- tempest_ 1y agoWe use fastapi for our newer stuff. Its nice but unless you really need async I think you can get further quicker with something like flask. I really wish the dev would extract the dependency injection portion of the project and flesh it out a bit. There are a lot of rough edges in there.
- adamnemecek 1y agoThis feels like an article from 2013.
- stackskipton 1y agoDjango is massive and ton of baggage to be carrying if you are only doing REST APIs. This sounds like standard case going with what developers know instead of evaluating tool for job.
- icedchai 1y agoI worked at a mid-size startup that was still running on Python 2.7 and Django for their REST APIs, as late as 2022. It was pretty meh and felt like traveling back in time 10 years.
- JimDabell 1y agoPython 2.7 was released in 2010. Of course using it in 2022 felt like travelling back in time ten years‽
- mywittyname 1y ago2.7 was end-of-life in 2020! And Python 3 outdates 2.7 by a few years. A company using 2.7 in 2022 is an indicator that the company as a whole doesn't really prioritize IT, or at least the project the OP worked on. By 2017 or so, it should have been clear that whatever dependencies they were waiting on originally were not going to receive updates to support python3 and alternative arrangements should be made.
- icedchai 1y agoYou captured the fundamental issues. There were mountains of technical debt. I recall encountering a dependency that had not been updated in over 10 years.
- Izkata 1y agoWe have VB deployments that haven't been changed at all in about that long. Finally got approval to do a rewrite last year, which is python 3.6 due to other dependencies we can't upgrade yet. It got this bad because the whole thing "just worked" in the background without issues. "Don't fix what isn't broken" was the business viewpoint.
- gjvc 1y agopython2 will have that effect tbh
- zzzeek 1y agoGood decision, judging by their general level of impatience with things they would have hated my ORM :). Also I think the node approach is probably still more performant than FastAPI but that's just a hunch. Hopefully they won't have security issues because someone hijacked the node package that sets the font color to blue or passes the butter or something.
- jgehrcke 1y agoThank you for that comment, Mike :-) I was looking for that type of response here :-). As expressed many times: thank you for your work.
- antod 1y agoPasses the butter is a euphemism for churn?
- zzzeek 1y agoit's from rick and morty that was referenced here last week with a post about robots that pass butter
- me2too 1y agoIs this 2015?
- morshu9001 1y agoPlenty of people are still using Python, Java, or even C++ for this sort of thing, even in new codebases, for no reason other than familiarity
- 802e65bc-e259 1y agoI am curious, what is the latest and greatest language/framework that they should have used from the start?
- JackSlateur 1y ago"Python async sucks", then rants about django "Python doesn't have native async file I/O." - like almost everybody, as "sane" file async IO on Linux is somehow new (io_uring) Anyway ..
- jitl 1y agolibuv has provided an async interface for io using a worker thread pool for a decade, no dependency on io_uring required. I guess the threadpool they mention that aiofiles uses is written in python, so it gives concurrency but retains the GIL, so no parallelism. Node's libuv async stuff moves all the work off the main thread into c/c++ land until results are ready, only when dealing with the completed data read event does it re-enter the NodeJS "GIL" JavaScript thread.
- hinkley 1y agoLibuv has had io_uring integration for almost 18 months if you’re not on an old kernel or old hardware. They claim about an 8x improvement in speed.
- jitl 1y agothat's great! just saying io_uring has never been a required dependency to write application logic that avoids blockage on reads.
- danudey 1y agoTo be clear: libuv has had the ability to offload (some?) I/O operators to io_uring since v1.45.0, from 2023, and that's the 8x speed improvement. 2024 is when node.js seemed to enable (or rather, stop disabling) io_uring by default in its own usage of libuv.
- hinkley 1y agoYeah if you look at the libuv release history there’s been a lot of adding and subtracting since then. It’s clearly not all settled but there are chunks.
- morshu9001 1y agoThat's good. Should've ditched the ORM too.
- resiros 1y agoTL;DR >I'll preface this by saying that neither of us has a lot of experience writing Python async code > I'm actually really interested in spending proper time in becoming more knowledgeable with Python async, but in our context you a) lose precious time that you need to use to ship as an early-stage startup and b) can shoot yourself in the foot very easily in the process. The best advice for a start-up is to use the tools that you know best. And sometimes that's not the best tool for the job. Let's say you need to build a CLI. It's very likely that Go is the best tool for the job, but if you're a great Python programmer, then just do it in Python. Here's a clearer case where the author was not very good with Python. Clearly, since they actually used Django instead of FastAPI, which should have been the right tool for the job. And then wrote a blog post about Python being bad, but actually it's about Django. So yeah, they should have started with Node from day one.
- kelvinjps10 1y agoThey were good but no experience with python async
- com2kid 1y agoActually after having written a complex CLI in Node, I think I would've been better off learning Go and writing in that. Sometimes tools are worth learning!
- morshu9001 1y agoI'd also rather write a CLI in Python than in Node
- com2kid 1y agoThe only issue with writing a CLI in Node is ecosystem. The CLI libraries for Node are (or were last time I checked) inspired by React. Not a paradigm that is fun to write in, and if I'm making a CLI tool it is because I am bored and want to make something for my own entertainment.
- pier25 1y agoI would have picked Hono and Drizzle. In part because of the great TS support but also Hono is much faster than Express and supports Zod for validation out of the box. This stack would also allow to use any other runtime (Deno, Bun, or Cloudflare Workers). Given they used TS and performance was a concern I would also question the decision to use Node. Deno or Bun have great TS support and better performance.
- adzm 1y agoI think it makes sense to start with node.js... it's the standard and widely supported. Eventually it should not be too difficult to switch to bun or deno if the need arises.
- jherdman 1y agoHave you tried Elysia (https://elysiajs.com/ https://elysiajs.com/)? Admittedly I'm not using it at scale, but it's quite pleasant.
- internetter 1y agoI've written 10s of thousands of lines of Elysia+Kysely and its a match made in heaven
- jherdman 1y agoI’m curious about your choice of Kysely. I’ve really only used Drizzle. It’s fine but it has some very rough edges around Bun and SQLite.
- internetter 1y agoI'd rather use SQL than an ORM. Kysely is basically a wrapper for the SQL query syntax inside typescript which has the benefit of composability and incredibly rich typescript support
- pier25 1y agoI checked it out and it looks good on paper but it only runs on Bun. Don't get me wrong, I use Bun and I'm happy with it, but it's still young. With Hono/Drizzle/Zod I can always switch back to Node or Deno if necessary.
- gjvc 1y agodjanko (sic) out fastapi in
- tschellenbach 1y agoIt is true that Python's typing and async support feels like someone adding extension to a house that was built 50 years ago.
- danudey 1y agoAfter having used it two weeks ago for the first time: it feels as though async support in Python is basically a completely parallel standard library that uses the same python syntax with extra keywords all over the place. It's like if building code compliance required your 50 year old house to be updated have a wider staircase with deeper steps but you wanted to do so without affecting the existing stairs, so now you just have two staircases which are a little bit different and it feels like it takes up space unnecessarily. I had to look for async versions of most of what I did (e.g. executing external binaries) and use those instead of existing functions or functionality, meaning it was a lot of googling "python subprocess async" or "python http request async". If there were going to be some kind of Python 4.x in the future, I'd want some sort of inherent, goroutine-esque way of throwing tasks into the ether and then waiting on them if you wanted to. Let people writing code mark functions as "async'able", have Python validate that async'able code isn't calling non-async'able code, and then if you're not in an async runloop then just block on everything instead (as normal). If I could take code like: def get_image(image): return_code = subprocess.check_call(["docker", "pull", image]) if return_code: raise RuntimeError("idk man it broke") result = get_image(imagename) print(result) And replace it with: def get_image(image): return_code = subprocess.check_call(["docker", "pull", image]) if return_code: raise RuntimeError("idk man it broke") result = async get_image(imagename) print(result) And just have the runtime automatically await the result when I try to access it if it's not complete yet then it would save me thousands of lines of code over the rest of my career trying to parallelize things in cumbersome explicit ways. Perhaps provide separate "async" runners that could handle things - if for example you do explicitly want things running in separate processes, threads, interpreters, etc., so you can set a default async runner, use a context manager, or explicitly threadpool.task(async get_image(imagename)). Man, what a world that would be.
- 1y ago
- jackblemming 1y agoWhen they start moving away from API calls to third parties to their own embeddings or AI they’re in for a bad time. What’s going to end up happening is they’ll then create another backend for AI stuff that uses python and then have to deal with multiple backend languages. They should have just bit the bullet and learned proper async in FastAPI like they mentioned. I won’t even get started on their love of ORMs.
- pphysch 1y agoWho is the audience for a post like this? Presumably HN, since the author invoked PG. But who is "we rewrote our stack on week 1 due to hypothetical scaling issues" supposed to impress? Not software professionals. Not savvy investors. Potential junior hires?
- rs186 1y agoProbably people who write too little code but read too many blog posts
- tracker1 1y agoI probably would have pushed for Hono as the underlying framework... That said, I've been a fan of Koa/Oak over Express for a very long time. For API usage, the swagger+zod integration is pretty decent, though it changes the typical patterns a bit. All-in, there's no single silver bullet to solving a given issue. Python has a lot of ecosystem around it in terms of integrations that you may or may not need that might be harder with JS. It really just depends. Glad your migration/switch went relatively smoothly all the same.
- davedx 1y agoIt depends on your use case. Exactly. If you’re building big data intensive pipelines with lots of array manipulation or matrix multiplications you know what will shine. Building user facing APIs, use something with types and solid async.
- tracker1 1y agoMatching your latter definition, I'd be inclined to go with Rust or C#... that said, you can go a long way with TS in Node/Deno/Bun/Cloudflare/Vercel, etc.
- megaman821 1y agoAs a long-time Django user, I would not use Django for this. Django async is probably never the right choice for a green-field project. I would still pick FastAPI/SQLAlchemy over Express and PostHog. There is no way 15 different Node ORMs are going to survive in the long run, plus Drizzle and Prisma seem to be the leaders for now.
- raverbashing 1y agoAgree Django is great but sometimes it seems it just tries to overdo things and make them harder Trying to async Django is like trying to do skateboard tricks with a shopping cart. Just don't
- liquidpele 1y agoAsync in Python in general really… The way they implemented it is basically a valley of footguns and broken dreams.
- morshu9001 1y agoI'd skip the ORM, Postgres is already designed for direct use on backends.
- mrits 1y agoI'd skip the ORM as well but your reasoning doesn't make any sense
- deleted 1y ago[deleted]
- remify 1y agoORMs are mostly useless they make easy queries easier et hard query a lot harder.
- eYrKEC2 1y agoMuch as Lisp'ers say, Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. If one says, "we don't use an ORM", you will incrementally create helper functions for pulling the data into your language to tweak the data or to build optional filters and thus will have an ad hoc, informally-specified, bug-ridden, slow implementation of half of an ORM. There is a time and place for direct SQL code and there is a time and place for an ORM. Normally I use an ORM that has a great escape hatch for raw SQL as needed.
- davedx 1y agoSame experience working on FastAPI projects. I don’t know how big production apps are maintained (and supported operationally) with the mess that is python+async+types. Conversely all the node+typescript projects, big and small, have been pretty great the last 10+ years or so. (And the C# .NET ones). I use python for real data projects, for APIs there are about half a dozen other tech stacks I’d reach for first. I’ll die on this hill these days.
- cjonas 1y ago100% same experience. If it were up to me, I'd started with typescript, but the client insisted on using a python stack (landed on FastMCP, FastAPI, PydanticAI). While, `PydanticAI` does the best it can with a limited type system, it just can't match the productivity of typescript. And I still can't believe what a mess async python is. The worst thing we've encountered was a bug from mixing anyio with asyncio which resulted in our ECS container getting it's CPU pinned to 100% [1]. And constantly running into issue with libraries not handling task cancellation properly. I get that python has captured the ML ecosystem, but these agent systems are just API calls and parsing json... [1](https://github.com/agronholm/anyio/issues/884 https://github.com/agronholm/anyio/issues/884)
- triyambakam 1y agoI don't really see how you're comparing Pydantic AI here to Typescript. I'm assuming you meant simply Pydantic.
- cjonas 1y agoJust comparing an agent framework written in python (with focus on being "typesafe") to one (any) written in typescript
- triyambakam 1y agoThat's a very poor comparison then and not very useful?
- Alir3z4 1y agoAsync and Django don't mix well and I honestly see the whole Django Async as wasted resources, all those "a" prefixed functions etc. To be honest, I never liked the way async is done in python at all. However, I love Django and Python in general. When I need "async" in a http cycle flow, I use celery and run it in background. If client side needs to be updated about the state of the background task, the best is to send the data to a websocket channel known to the client side. Either it's Chat response with LLM or importing a huge CSV file. Simple rule for me is, "don't waste HTTP time, process quick and return quick".
- robertlagrant 1y ago> If client side needs to be updated about the state of the background task, the best is to send the data to a websocket channel known to the client side. SSE is nice.
- revicon 1y agoRight up until your user opens your site in more than 6 tabs.
- robertlagrant 1y agoAnd then you need http2.
- Oxodao 1y ago(especially the Mercure protocol which makes stuff so simple)
- vb-8448 1y ago+1 but I still hope at some point they will manage to fix the devx with django/python and async
- bodhi_mind 1y agoThere’s also Django channels which is pretty sweet for certain tasks, especially websockets. I use a combination or channels and celery for a few projects and it’s works great.
- fnord77 1y agoDo we still need ORMs in the age of AI-assisted coding? I started ripping them out of a java system even before that.
- dionian 1y agoWe're on the same wavelength, i have decades of ORM experience. It was the first thing i woudl do in any project. Now it can just be vanilla JDBC with tons of duplicated boilerplate. AT least in the early stages.
- fnord77 1y agospring's JdbcTemplate has a nice query pattern that gets rid of a lot of boilerplate by passing each fetched row to a lambda
- euph0ria 1y ago"we almost quit multiple times" It was a three day small task?
- ehutch79 1y agoThis didn't make sense to me either? If it only took three days for a complete rewrite to another language, what's the problem? Did I read they were getting interrupted for user requests? felt weird.
- novoreorx 1y agoProbably because they have to deal with customer feedbacks and bugs on existing system. The stress would be huge, making a day like a week long, I guarantee
- djdjsjejb 1y agonodejs excels for me on flow control theres effectts if you need app level control theres caolan async if you need series and parallel controls theres rxjs if you need observables on web frameworks hono seems nice too. if you need performance, theres uwebsockets.js which beats all other web frameworks in http and websocket benchmarks. for typesafety aside from typescript, theres ark, zod, valibot, etc.
- travisgriggs 1y agoI do a lot of glueware and semi-embedded stuff with Python... but my goto these days for anything networky is Elixir (LiveView if ux). If I need an event loop, async that is more than a patched on keyword, it just rocks. It is amazing to me how much Elixir does not have, and yet how capably it solves so many problems that other languages have had to add support for to solve.
- xenator 1y agoSo basically you just rewrote boilerplate code with complexity of "hello world" and deploy scripts. Without any dependencies, data migrations, real user data and downtime SLA. And after that you had time to write quite long article. What honest reaction you expect from readers?
- oompydoompy74 1y agoI have no idea how you reached this conclusion from the article that I read.
- xenator 1y agoJust simple arithmetics.
- asa400 1y agoFolks, if you have problems doing async work, and most of your intense logic/algorithms is a network hop away (LLMs, etc.), do yourself a favor and write a spike in Elixir. Just give it a shot. The whole environment is built for async from the ground up. Thousands and thousands of hours put into creating a runtime and language specifically to make async programming feasible. The runtime handles async IO for you with preemptive scheduling. Ability to look at any runtime state on a production instance. Lovely community. More libraries than you might expect. Excellent language in Elixir. Give it a shot.
- doomspork 1y agoUsing a lot of Typescript and Python in my current role and I find myself missing that part of Elixir. Ecosystems are night and day though. For what we're doing we'd have to write far too many libraries ourselves in Elixir and don't have the time right now.
- metadata 1y agoA lovely language with an incredible web framework (Phoenix, LiveView). However, not easy to pick up for people with only imperative programming experience. I had to switch my project to .NET in the end because it was too hard to find/form a strong Elixir team. Still love Elixir. Indestructible, simple, and everything is easy once you wrap your head around the functional programming. It. Just. Works.
- mikepurvis 1y agoAs someone who has spent my whole career in somewhat niche things (ROS, OpenWRT, microcontrollers, Nix), I think the answer for how to hire for these is not to look for someone who already has that specific experience but rather look for someone curious, the kind of person who reads wikipedia for fun, an engineer who has good overall taste and is excited to connect the dots between other things they've learned about and experimented with. Obviously that's not going to give you the benefit of a person who has specifically worked in the ecosystem and knows where the missing stairs are, which does definitely have its own kind of value. But overall, I think a big benefit of working in something like Elixir, Clojure, Rust, etc is that it attracts the kind of senior level people who will jump at the opportunity to work with something different.
- danudey 1y agoI 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.
- pdhborges 1y agoWhy don't you post the original broken Python code.
- triyambakam 1y agoI mean I know it sounds snarky but it just sounds like you weren't awaiting the tasks properly
- neya 1y agoDo yourself a favor and use Elixir. Elixir has almost the same top libraries from Python you need to work with AI. As a matter of fact, the Elixir versions are far less fragile and more reliable in production use cases. I documented my journey of writing an AI app using Elixir and listed out the top libraries you can use, especially if you're coming from Python: https://medium.com/creativefoundry/i-tried-to-build-an-ai-product-with-langchain-vue-3-svelte-5-with-phoenix-liveview-so-you-dont-134930c78342 https://medium.com/creativefoundry/i-tried-to-build-an-ai-pr...
- 5dE63b6850e83 1y agoBRO 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?' });
- cryptomic22 1y agoThis is a lot more about Django than it is about Python.
- luxuryballs 1y agoI don’t know a ton about either but now I am curious if I should takeaway the idea that async with Python is problematic or if only async with Django is the issue.
- morshu9001 1y agoAsync with Python is problematic, but this article doesn't really explain that. Django async being bad is just one of many symptoms.
- fatih-erikli-cg 1y ago[dead]
- nurettin 1y agopython 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.
- srpablo 1y agoI'm really torn -- you and your engineers should be excited to work on your codebase. You should enter it and be like "yes, I've made good choices and this is a codebase I appreciate, and it has promise." If you have a set of storylines that make this migration appropriate, and its still early in the company that you can even do this in 3 days, then by all means, do it! And good luck. It'll never be cheaper to do it, and you are going to be "wearing" it for your company's lifetime. But a part of me is reading this and thinking "friend... if PostHog was able to do what they're doing on the stack you're abandoning, do you think that stack is actually going to limit your scalability in any way that matters?" Like, you have the counterexample right there! Other companies are making the "technically worse" choice but making it work. I love coding and I recognize that human beings are made of narratives, but this feels like 3 days you could have spent on customer needs or feature dev or marketing, and instead you rolled around in the code mud for a bit. It's fine to do that every now and then, and if this was a more radical jump (e.g. a BEAM language like Elixir or Gleam, or hell, even Golang, which has that preemptive scheduler + fast compiles/binary deploys + designed around a type system...) than I'd buy it more. And I'm not in your shoes so it's easy to armchair quarterback. But it smells a bit like getting in your head on technical narratives that are more fun to apply your creativity to, instead of the ones your company really needs.
- boredtofears 1y agoI have to spend 3 days working on someone else's "narratives that are more fun to apply their creativity to" all the time, even when my intuition and experience tells me it isn't a good idea. Sometimes my intuition is wrong. I've yet to meet a product manager that isn't doing this even when they claim to have all the data in the world to support their narrative. Personally I don't think there's anything wrong with scratching that itch, especially if its going to make you/your team more comfortable long term. 3 days is probably not make-or-break.
- TZubiri 1y ago>if PostHog was able to do what they're doing on the stack you're abandoning, do you think that stack is actually going to limit your scalability in any way that matters? Also, considering the project is an AI framework, do you think the language ChatGPT is built on is a worse choice than the language we use because it's in the browser?
- languagehacker 1y agoI don't see it mentioned enough in the comments here, but not considering Celery as an alternative to Django + async really is the missing puzzle piece here. Aside from application-level options that weren't explored, I'm wondering whether handling some of the file IO stuff with, for instance, nginx, might be a better fit for their use case. Once you're in the situation of supporting a production system with some of the limitations mentioned, you also owe it to yourself to truly evaluate all available options. A rewrite is rarely the right solution. From an engineering standpoint, assuming you knew the requirements pretty early on, painting yourself into a bad enough corner to scrap the whole thing and pick a new language gives me significant pause for thought. In all honesty I consider a lot of this blog post to be a real cause for concern -- the tone, the conflating arguments (if your tests were bad before, just revisit them), the premature concern around scaling. It really feels like they may have jumped to an expensive conclusion without adequate research. In an interview, I would not advance a candidate like this. If I had a report who exhibited this kind of reasoning, I'd be drilling them on fundamentals and double-checking their work through the entire engineering process.
- dzonga 1y ago[dead]
- Kwpolska 1y agoI tried to use Celery for something extremely trivial (granted, 5+ years ago). It was so badly documented and failed to do basic things I would expect from a task queue (like progress reporting) I have no idea why it was and still is popular.
- languagehacker 1y agoJust because you couldn't figure it out doesn't mean the capability wasn't there. More than ten years ago at this point I was running a massively scaled Celery + RabbitMQ + Redis deployment with excellent off-the-shelf reporting using Flower.
- 1y ago
- pspeter3 1y agoI'm curious about who else is using MikroORM. I see a lot of hype around Prisma, Drizzle, and Kysely but MikroORM has always looked interesting.
- sthuck 1y agoI'm using it for a hobby project, and pretty pleased. My personal maybe somewhat "stubborn old man" opinion is that no node.js orm is truly production quality, but if I were to consider one I think I would start with it. Be aware it has only one (very talented) maintainer as far as I recall.
- stephen 1y agoEveryone's definition of "production quality" is different :-), but Joist is a "mikro-ish" (more so ActiveRecord-ish) ORM that has a few killer features: https://joist-orm.io/ https://joist-orm.io/ Always happy to hear feedback/issues if anyone here would like to try it out. Thanks!
- coldtea 1y agoIf we ignore the ML/AI/array libs, where Python shines, the core development has really done nothing much for it since 3.0. Despite MS, Guido and co throwing their weight, still none of the somewhat promised 5x speedup across the board (more like 1.5x at best), the async story is still a mess (see TFA), the multiple-interpreters/GIL-less is too little, too late, the ecosystem still doesn't settled on a single dependency and venv manager (just make uv standard and be done with it), types are a ham-fisted experience, and so on, and so forth...
- dalberto 1y agoAsync django is not for the faint of heart, but it's definitely possible in 2025. I recently wrote about issues debugging this stack[1], but now I feel very comfortable operating async-first. [1] https://blendingbits.io/p/i-used-claude-code-to-debug-a-nightmare https://blendingbits.io/p/i-used-claude-code-to-debug-a-nigh...
- ZhiqiangWang 1y agoDo not rewrite in one shot, make small micro services in nodes and migrate from Django step by step.
- hintymad 1y ago> Python async sucks I always find this line of thought strange. It's as if the entire team hinges their technical decision on a single framework, when in reality it's relatively easy to overcome this level of difficulties. This reminds me of the Uber blunder - the same engineer/team switched Uber's database from MySQL to Postgres and then from Postgres to MySQL a few years later, both times claiming that the replaced DB "does not scale" or "sucks". In reality, though, both systems can work very well, and truth be told, Uber's scale was not large enough for either db to show the difference.
- TZubiri 1y agoThe grass is always greener, because of greenshift, a phenomenon where the light dilates due to the universe expansion dilation of spacetime.
- deleted 1y ago[deleted]
- robot-wrangler 1y agoDoing zero upfront research or planning and then bragging about it in public like this is pretty suspect, but I guess more to the point, glorifying "the pivot" like this is out of style anyway. You're now supposed to insist that whatever happened was the plan all along.
- sunkencity 1y agoimho it would make more sense to rewrite to golang with a stronger production ready standard library.
- pjmlp 1y agoIf scale really mattered they should have rewriten it in Go, Java, C#, Rust.... Or if feeling fancy, Erlang, Elixir.
- deleted 1y ago[deleted]
- 9rx 1y agoThey were looking to scale up their marketing reach. Would Go, Java, C#, or Rust have had the same effect? "Migrated from Python to Rust? That makes sense, I guess. Next". "Migrated from Python to Javascript? What? That's crazy! I'd better read this."
- connectsnk 1y agoDoes this problem exist with fastapi as well?
- submeta 1y agoI was about to migrate a legacy system written in Python/ Flask to FastAPI and React (frontend). But the sentiments here seem to suggest that FastAPI is not the best solution if I need async? So go with Next.js?
- oceansky 1y agoFastapi is perfectly fine for async. In fact, it's built with async in mind. I say that as someone who prefers JS promises: you likely won't face issues with either.
- jacquesm 1y agoFrom the proverbial frying pan into the fire. If you're going to go through all of the effort and cost to switch platforms and to retrain your developers, why on earth would you pick Node.js? Node.js is such an incredible mess. The ideas are usually ok but the implementation details, the insane dependencies (first time I tried to run a Node.js based project I thought there was something seriously wrong with my machine and that I'd been hacked), the lack of stability, the endless supply chain attacks, maintainers headaches and so on, there is very little to like about Node.js. C# before Node.js and I can't stand C#. Java Before C#. Yes, it's a language rant, but in the case of Node I am really sorry.
- tshaddox 1y agoSo you'd recommend they rewrote their Python project in Java (assuming the rewrite itself was a good idea)? I don't have any experience on a production web server written in Java or C#, but they both seem like a more difficult transition than JavaScript for rewriting a Python codebase.
- jacquesm 1y agoI've written code in all of these and I think that Python to Java or Go is easier than Python to Node, especially if you don't want to spend the next 24 months auditing all of the code you just imported.
- CharlieDigital 1y agoFor the uninformed, C# and TypeScript are very similar[0] In fact, JavaScript has borrowed a lot from C# including async/await, lambda expressions, and the syntax for disposables -- all influenced by and done first in C#. Of course, TypeScript and C# are from the same designer at Microsoft so there are even more similarities. Any team that's considering moving to TypeScript should also really give C# a look. [0] https://typescript-is-like-csharp.chrlschn.dev/pages/intro-and-motivation.html#inheriting-classes https://typescript-is-like-csharp.chrlschn.dev/pages/intro-a...
- pjmlp 1y ago
- fatih-erikli-cg 1y ago[dead]
- traverseda 1y ago>We did this so we can scale. >Python async sucks Python async may make certain types of IO-blocked tasks simpler, but it is not going to scale a web app. Now maybe this isn't a web app, I can't really tell. But this is not going to scale to a cluster of machines. You need to use a distributed task queue like celery.
- almosthere 1y agoWe should really be at a point where the application is a Yaml file and a something like Hugo for backends, and you can force it to use --java or --js or --rust or --python, etc...
- fakedang 1y agoI'm actually building an app on the side and went the other way around on this. Migrating from Typescript back to Python. Granted, my gripes were more with NextJS rather than Node or Typescript. Using Django was so intuitive although the nomenclature could do a bit better. But what took me days trying to battle it out on NextJS was literally done in an hour with Django (admin management on the backend). While Django still looks and feels a bit antiquated, at least it worked! Meanwhile I lost the entirety of the past weekend (or rather quite a bit of it), trying to fight my code and clean up things in NextJS because somehow the recommended approach for most things is mixing up your frontend and backend, and a complete disregard for separation of concerns. My new stack from now one will likely be NextJS for the frontend alone, Django for the CRUD and authentication backend, Supabase Edge functions for serverless and FastAPI if needed for intensive AI APIs. Open to suggestions, ideas and opinions though.
- andrewstuart 1y agoPython async doesn’t suck. Python async is awesome. But there’s giant red flags up if you’re trying to do async with Django, which is built as synchronous code.
- move-on-by 1y ago> At this point, some people are probably screaming at their screens going: "just use FastAPI!" -- and we did indeed consider it. Working with both sync Django and async FastAPI daily, it’s so easy to screw up async FastAPI and bring things to a halt. If async is such the huge key feature they seem to think it is for their product, then I would agree moving away from Python early while it’s still relatively easy is the right call. > and we had actually already written our background worker service in Node, Ok well that’s a little bizarre… why use Django to begin with if you are not going to use the huge ecosystem that comes with it. New Django has first-class support for background workers, not that Celery is difficult to get setup. It’s sounds like the engineering team just started building things in what they knew without any real technical planning and the async hiccup is more or less an excuse to get things in order after the fact.
- kurtis_reed 1y ago> it’s so easy to screw up async FastAPI and bring things to a halt For example?
- move-on-by 1y agoI think this stackoverflow answer does a good job explaining the nuances: https://stackoverflow.com/a/71517830 https://stackoverflow.com/a/71517830
- aprilfoo 1y agoPosts inviting language/frameworks flame wars are clickbaits... and i fell for it, again.
- oceansky 1y agoI, for one, love reading those.
- alberth 1y agoI often see people complain about how async is implemented in certain languages or frameworks - are there any examples where people actually like how async was designed or handled?
- scosman 1y agoGo
- gitprolinux 1y agoOld school solution effective, Python3 cgi, jquery, solid. Agree Python async sucks. It's about getting it done.
- hu3 1y agoI can vouch for Go. Took me a weekend to create a basic trading algo tester in Go that leveraged all computer cores. And I was new to Go and Llama didn't exist back then. These days it would have probably taken me a Sunday morning to do the same
- est 1y ago> You gotta write sync_to_async and async_to_sync everywhere. I have a a simple wrapper that allows you write once and works for both sync/async https://blog.est.im/2025/stdout-04 https://blog.est.im/2025/stdout-04
- ecshafer 1y agoWhy can Instagram scale on Python and Django but you can't?
- petr25102018 11mo agoPerhaps because Instagram uses their own Python and a heavily custom Django fork?
- rick1290 1y agoI like mikro orm - cool to see you use that. I do prefer django however. I see express as the backend. Why not nestjs? And are you using openapi at all for generating your frontend client? What i've discovered is - any backend + orm should expose an openapi spec'd backend... and your frontend can autogen your client for you. Allows you to move extremely quick with the help of ai.
- zeroq 1y ago"We've decided to fix our problem by using Perl. Now we have two problems."
- drnick1 1y agoI week from now you will be posted you rewrote your program in C++.
- simoncoulton 1y agoSeems like there was solid ROI attached to this initiative…
- hnidiots3 1y ago> We did this so we can scale. lol sounds more like a bunch of front end developers who don’t know what they are doing wanted to use a language they use on the front end on the backend.
- m463 1y agoI wonder about situations like this. I always wanted an emacs with python as the underlying language. Is emacs brilliant choosing lisp or outdated?
- romperstomper 1y agoThe author mentions that they considered FastAPI and this looks more sane decision as for me then rather radical jump into Node.js.
- amai 1y agoShould be "Why we migrated from Django to Node.js". Answer: Because Django doesn't support async by default.
- novoreorx 1y agoThis kinda resonates with me. I've been using Python for over a decade and the only async method I trusted was gevent, and since I moved to Go after 2016, I never want use Python async in production level project, even I came back to see how it goes almost every year. But since Python's LLM ecosystem is so well, I really appreciate the courage it takes to migrate to Node when writing a RAG system. I've tried similar things recently, working on a document analyzing project using React Router as the full-stack framework, while put some ETL related work on the Python side, use inngest to bridge Node and Python services. In this way, I got the benefit of Node for LLM chat, while stil able to facilitate Python's SOTA ETL libraries.
- m-a-r-c-e-l 1y ago3 days? Do it! It took our team 5 man-years (1 year of time) to upgrade from Laravel 4 to 5...
- ccanassa 1y agoSounds like a hammer-and-nail problem to me. Django works perfectly with green threads. It’s a superior model to async and avoids the whole function-coloring mess. I’ve seen Django setups outperform Go-based services running under similar conditions. JavaScript is a terrible language and should only be used when there’s absolutely no alternative, such as in browsers.