[srpablo]

I'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.

[xmprt]

The author addresses that in the article. Python can scale but then developers would have to work with unintuitive async code. You can think of it as a form of tech debt - every single decision they make will take longer because they have to learn something new and double check if they're doing it the right way.

[deanishe]

> The author addresses that in the article. Python can scale but then developers would have to work with unintuitive async code

Python didn't cause their problems, Django did. They wanted async, but chose a framework that doesn't really support it. And they weren't even running it on an async app server.

Python didn't work for them because every subsequent choice they made was wrong.

[xmprt]

I think you're saying the same thing that I am. Python didn't work for them because they didn't use it correct and so accelerated the amount of tech debt they created. Posthog is using Django and they've scaled so clearly they've figured something out with using Python/Django with async but it probably isn't intuitive because neither you nor the author know of a good way to support it.

[jaredklewis]

I’m surprised the article doesn’t make more of TypeScript.

From a technical perspective, I find both python and node.js to be pretty underwhelming. If I had to pick a shiny new thing it would probably be one of the usual suspects like Rust.

But last time I worked with Python (2022), types in python were pretty uninspiring. In 2022 typescript was already very powerful and it just keeps improving.

[never_inline]

Types in python are really good now.

It's the asyncio and all performance footguns which need to be fixed.

[mmcromp]

Whats "really good"? Pydantic? Mypy with dataclasses and built in typings? Is integration with Django okay? Genenily curious, not sarcastic. Im coming from from static typing and learning python ecosystem. Im still searching to make it work for me

[never_inline]

Pros:

Pydantic is good. Mypy and pyright are good enough for type checking real projects. I run mypy as pre commit. It takes time but it has saved me from real bugs.

The type system coupled with pydantic for validation is more expressive and ergonomic than java / go. But it's also lousy when working with people who don't have the type oriented thinking (especially juniors). You need to enforce people to type public signatures and enable strict linter settings.

Mixed:

Library wise, FastAPI ecosystem is type-first and works well. But old world ecosystems like django - I don't have first hand experience.

SQL alchemy seems to be getting better. But I wish something type-first similar to sqlc or room or Micronaut Data JDBC existed for python, where I could just use pydantic validated DTOs and use query builder, rather than dealing with SQLAlchemy's proxy objects. It's workable though. I would suggest keeping SQLA objects in only the layer that touches the DB and convert them to pydantic models at the boundary.

Library support is hit or miss. In common web dev, I get good typings as long as I stick to popular and "boring" libraries. Sometimes I have to look at docstring and use typing.cast to return types.

Cons:

new type checking solutions like pyrefly aren't there yet for my use cases. Ruff is good as linter and VSCode extension.

IDE extensions and mypy still miss some bugs which should never happen in typed languages. ESP with coroutines. (I wish there was a way to make it an error, to call coroutines without await, unless submitting them to a asyncio.run or gather etc.., dart has very good async linting in comparison).

Writing a: dict[tuple[str, str, str], int] = {} is no fun. But it guarantees if I use a wrong type of key down in the function, I will get a red squiggle.

[shirokuma]

It's insane to me how making the technically worse choice is okay to you because some company out there is "making it work"

Also what could you do in 3 mere days that would pay off more than having the code in a language that the team is much more efficient with, one which doesn't need hacks to "make it work"?

It would save you several days on features forever, compared to doing one thing for just 3 days.

[zelphirkalt]

Basically, you have said it: It is about what the team is knowledgeable about.

In my book Nodejs doesn't belong on the server, but that's the choice they made. Python at least is thought out as a backend language, but can also be criticized for many aspects. If a team is more knowledgeable about modern languages, of course there are many technically probably better choices than both Nodejs or Python.

[vips7L]

I don’t think I’ve ever worked in a codebase I’ve been excited about. I didn’t know those existed.

[riffraff]

They exist in the brief moment between a project start and when deadlines start to loom ;)

More seriously, I've worked on codebases I found ok, and some I deeply disliked, I guess there's a continuum from "exciting" to "frustrating".

[jay_kyburz]

I always like _my_ parts our code base. I never enjoy wading into my colleagues code. I'm sure they feel the same way.

[riffraff]

For sure, but I also get the same feeling about parts of the codebase I wrote but I had since forgotten.

The "what idiot wrote this? Oh, it was me" thing.

[fennecbutt]

Like tears in the rain.

[boredtofears]

I 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]

>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?

[pjmlp]

You mean C++, right?

Because language bindings isn't really what makes ChatGPT tick.

[TZubiri]

https://github.com/openai/gpt-oss/tree/main

Sure a project can be based on more than 1 language. But it seems to be mostly python.

[pjmlp]

You missed these trees on the Python forest,

https://github.com/openai/gpt-oss/blob/main/pyproject.toml

https://github.com/openai/gpt-oss/blob/main/CMakeLists.txt

[TZubiri]

You are right, they are using Docker, therefore it's written in C.

[philbo]

https://status.posthog.com/history

[progbits]

I was just thinking... "BugHog? The platform famously broken more often than not?"

We have a whole posthog interface layer to mask over their constant outages and slowness. (Why don't we ditch them entirely? I, too, often ask this, but the marketing people love it)

[zelphirkalt]

> Powered by Atlassian Statuspage

Is all I need to know.

[frez1]

It sounds like the author and their team were more comfortable with node.js than python. they acknowledge fastapi was a good alternative that could solve their issues and allow some code reuse, but decided not to because they just wanted to use node.

the gist of this blog post is this company knew and understood node better than python, so they migrated to what they knew.