Content
@
https://opensea.io/collection/dev-21
0 reply
0 recast
2 reactions
Monteluna
@monteluna
I still can't find a reason to ever use Python server-side. I worked for multiple startups that did this and stood on the idea that OO design was the only religion that mattered. Today in the year 2025 of our lord Satoshi, when you get type safety with Typescript and plenty of other strongly typed languages, what's the point of using Python for anything beyond scripting and data?
3 replies
0 recast
5 reactions
xh3b4sd ↑
@xh3b4sd.eth
I had similar revelations recently too. Type safety is just one of many relevant aspects of software engineering. I cannot advocate for Typescript in the backend either, because the entire Javascript ecosystem is an unmitigated disaster, somehow by design. Certain architectural choices are made for you by the programming language and its environment. Javascript does not prevent you from doing the dumbest things on a daily basis. Package management is absolute garbage. You are somehow forced to use 17 different tools with 23 different config files just to get something up and running. And then you don't even get a build artifact that you can verify and replicate and distribute. Like, yeah it works, somehow. What I don't understand though is why anyone would want to settle with something like this medium to long term if there is real money on the line in the grand scheme of things.
1 reply
0 recast
0 reaction
Monteluna
@monteluna
I agree there but that's front end engineering. The browser sucks and is held together by a ton of different consortiums, so the library code is pretty much guaranteed to pass complexity to developers. As for backend deno does actually solve for some of these issues. I just don't think many people tried it. Engineering operations side though, some of the best teams I worked for did fullstack front to back and it makes a lot of management seamless. I wouldn't recommend Next.js but its not hard these days to run a backend with TS as well as just absorbing the nonsense that is front end.
1 reply
0 recast
0 reaction
xh3b4sd ↑
@xh3b4sd.eth
I never used Deno. My guess would be that this is all Javascript after all. And so the things that hurt me the most personally are just the same whatever the wrapper around them. And then it doesn't really matter whether this is frontend or backend or some CLI tool. This is all broken on a couple of fundamental levels in Javascript. I also don't believe in this seamless benefit between front and back. The complexity of integrating both isn't contingent on the same programming language in either place, because those are two separate components anyway. And then, what you should do in either case is to generate all relevant code for the network layer abstraction using a single source of truth for the API specification. Protocol Buffers have tooling for all major ecosystems and its just a bliss to get the client/server code generated automatically. I have this tooling setup for a couple of projects. Anyone interested just hit me up.
1 reply
0 recast
0 reaction
Monteluna
@monteluna
Scaling dev team. A major issue is many teams don't have the luxury of hiring both a python guy and a JS guy who knows what they're doing unless they are based in Brooklyn or SF.
0 reply
0 recast
0 reaction
