News for hackers. Stuff that matters.
Re:Python Shouldn't Be the Top Programming Language by toomuchtodo on Thursday April 28, 2022 @02:35PM (#31196417)
What languages do folks “graduate” to after Python?

(this was a genuine question as someone who primarily writes code in Python for fun, not professionally, and is looking to level up for fun)

Re:Python Shouldn't Be the Top Programming Language by cb321 on Thursday April 28, 2022 @02:48PM (#31196602)
It depends on what "graduate" means (I note your "scare quotes"). For some people, lexical styles matter a lot and it is easier to answer this question with that kind of constraint.

While its ecosystem is surely much smaller than even Julia's, Nim [1] has a lot of the concise, lexical feel of Python, but semantics more like Modula3/Ada and with Lisp-like syntax macros/metaprogramming to fill in other gaps.

Another possibility is Cython [2] which is basically a superset of Python with gradual typing..more targeted at writing new C-like Python modules/leveraging the Python runtime environment than "standing on its own".

[1] https://nim-lang.org/

[2] https://cython.org/

Re:Python Shouldn't Be the Top Programming Language by PaulHoule on Thursday April 28, 2022 @03:11PM (#31196889)
Python has PyPi and numba. PyPi is good for branchy things like RDF triple stores, business rules engines, etc.

CPython (and most other interpreters) has the big problem of the global interpreter lock which prevents it from taking advantage of threads... And that's a problem in a world where (1) 8-core laptops are common, (2) much bigger machines can be found in the server room and (3) many workloads can be parallelized over threads with just a little work.

Re:Python Shouldn't Be the Top Programming Language by cb321 on Thursday April 28, 2022 @03:38PM (#31197229)
Cython lets you do `with nogil`. That said, often processes with communication are enough to leverage multi-core with no global interpreter lock (GIL). CPython's pickling junk for its multiprocessing library can add a lot of overhead to that, though. A simpler pure binary version of multiprocessing could lower that overhead enough to make multiprocessing competitive with multithread unless inputs/outputs are really big (in which case tossing them in files and passing around pathnames is a not crazy fallback...). (EDIT: In the Linux kernel processes and threads are both just created by a system call named "clone" with various sharing flags. Threads are just processes with very unsafe settings - settings that many prog.langs think they can "tame well enough".)
Re:Python Shouldn't Be the Top Programming Language by jleyank on Thursday April 28, 2022 @02:40PM (#31196483)
In the ‘00s I found a python/C combination very effective. All control in python, compute in C and the class mechanism easily tied things together. I would recommend this for any new heavy cpu development as the needs for each portion are so different.
Re:Python Shouldn't Be the Top Programming Language by PaulHoule on Thursday April 28, 2022 @02:57PM (#31196711)
Right, that's one of the architectures for complex programs: use a scripting language for parts and a systems language for other parts.

Video games are a great example. You'd like a level designer to be able to edit scripts that control arbitrary things about the game play, but you also need a performance and GFX pro to program other parts.

Re:Python Shouldn't Be the Top Programming Language by spacemanmatt on Thursday April 28, 2022 @04:18PM (#31197685)
The way I hear it frequently is: declarative shell, imperative core.