4 ms·
Sounds like a fun job, I’d love to do something like this in my 9 to 5. It’s also amazing how much work goes into making Python a decent platform because it’s
by kubb 1y ago
Sounds like a fun job, I’d love to do something like this in my 9 to 5.
It’s also amazing how much work goes into making Python a decent platform because it’s popular. Work that will never be finished and could have been avoided with better design.
Get users first, lock them in, fix problems later seems to be the lesson here.
- fastball 1y agoImo it is less about locking anyone in (in this case) and more about what Python actually enables: exceedingly fast prototyping and iteration. Turns out the ability to ship fast and iterate is actually more useful that performance, esp in a web context where the bottlenecks are frequently not program execution speed.
- procaryote 1y agoPython has compounding problems that make it extremely tricky though. If it was just slow because it was interpreted they could easily have added a good JIT or transpiler by now, but it's also extremely dynamic so anything can change at any time, and the type mess doesn't help. If it was just slow one could parallelise, but it has a GIL (although they're finally trying to fix it), so one needs multiple processes. If it just had a GIL but was somewhat fast, multiple processes would be OK, but as it is also terribly slow, any single process can easily hit its performance limit if one request or task is slow. If you make the code async to fix that you either get threads or extremely complex cooperative multitasking code that keeps breaking when there's some bit of slow performance or blocking you missed If the problem was just the GIL, but it was OK fast and had a good async model, you could run enough processes to cope, but it's slow so you need a ridiculous number, which has knock-on effects on needing a silly number of database/api connections I've tried very hard to make this work, but when you can replace 100 servers struggling to serve the load on python with 3 servers running Java (and you only have 3 because of redundancy as a single one can deal with the load), you kinda give up on using python for a web context If you want a dynamic web backend language that's fast to write, typescript is a much better option, if you can cope with the dependency mess If it's a tiny thing that won't need to scale or is easy to rewrite if it does, I guess python is ok
- johnisgood 1y agoOr Elixir / Erlang instead of Java / Kotlin, and Go instead of Python, for this use case.
- pjmlp 1y ago> If it was just slow because it was interpreted they could easily have added a good JIT or transpiler by now, but it's also extremely dynamic so anything can change at any time, and the type mess doesn't help. See Smalltalk, Common Lisp, Self. Their dynamism, image based development, break-edit-compile-redo. What to change everything in Smalltalk in a single call? a becomes: b Now every single instance of a in a Smalltalk image, has been replaced by b. Just one example, there is hardly anything that one can do in Python that those languages don't do as well. Smalltalk and Self are the genesis of JIT research that eventually gave birth to Hotspot and V8.
- mixmastamyk 1y agoPython is fast enough for everything I’ve used it for decades and Cython and Rust are there for when it isn’t. Your performance needs are not typical.
- procaryote 1y agoOh I use it too, just not for anything that needs to scale at all Cython is a bit of a non-starter for a web context as you're essentially writing C with extra sugar, and can get C style vulnerabilities.
- mixmastamyk 1y agoSecond paragraph is not really true, unless you’ve gone out of your way. Cython is used primarily for compute-bound problems, not processing user input.
- procaryote 1y agoSo as long as you're using it properly and diligently filter all user input before it hits your cython, and don't make any mistakes it's fine?
- kubb 1y agoI agree that fast iteration and the „easy to get something working” factor is a huge asset in Python, which contributed to its growth. A whole lot of things were done right from that point of view. An additional asset was the friendliness of the language to non-programmers, and features enabling libraries that are similarly friendly. Python is also unnecessarily slow - 50x slower than Java, 20x slower than Common Lisp and 10x slower than JavaScript. It’s iterative development is worse than Common Lisp’s. I’d say that the biggest factor is simply that American higher education adopted Python as the introductory learning language.
- beagle3 1y agoFor American higher education, It was Pascal ages ago, and then it was Java for quite a while. But Java is too bureaucratic to be an introductory language, especially for would-be-non-programmers. Python won on “intorudctoriness” merits - capable of getting everything done in every field (bio, chem, stat, humanities) while still being (relatively) friendly. I remember days it was frowned upon for being a “script language” (thus not a real language). But it won on merit.
- darkwater 1y ago> Get users first, lock them in, fix problems later seems to be the lesson here. Or with a less cynical spin: deliver something that's useful and solves a problem for your potential users, and iterate over that without dying in the process (and Python suffered a lot already in the 2 to 3 transition)
- kubb 1y ago2 to 3 was possibly precisely because of user lock-in and sunk cost. This kind of global update was unprecedented, and could have been totally avoided with better design.
- exe34 1y ago> could have been totally avoided with better design This is why taxi drivers should run the country!
- deleted 1y ago[deleted]
- mixmastamyk 1y agoLaughable. Let’s see you design one of the best languages for the year 2060.
- meindnoch 1y agoThe JS playbook.
- legends2k 1y agoIsn't this so common in computer science, haven't you heard of Worse is Better [1]? [1]: https://en.m.wikipedia.org/wiki/Worse_is_better https://en.m.wikipedia.org/wiki/Worse_is_better
- materielle 1y agoPython is about 35 years old at this point. It was the better language that had the better design and the fixed problems at some point in time. Sure, maybe a committee way back in 1990 could have shaved off of some the warts and oopsies that Guido committed. I’d imagine that said committee would have also shaved off some of the personality that made Python an enjoyable language to use in the first place. People adopted Python because it was way nicer to use compared to the alternatives in say, 2000
- deleted 1y ago[deleted]