Something like Pony[0] or Nim[1]? I'm not very familiar with either one, but Nim says it is inspired by Python, and on the surface Pony appears to be as well.
[0] https://bluishcoder.co.nz/2015/11/04/a-quick-look-at-pony.ht...
"Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to see it as a soap bubble?" -- Alan Perlis
There are several things I personally _hate_ about python, but there is a cost-benefit that comes from engineering new things. What new problems are we going to be able to solve by using a new language? If the answer is clear (e.g. imperative programming vs declarative/functional programming let you solve different kind of problems) then it makes sense to do. If certain constructs enable you to completely avoid a recurring mistake (e.g. garbage collection), then it may make sense.
But this?!?!? No man, you don't need a new language to fix this.
Top comment is proposing basically Erlang or an actor model.
As for immutability... well they have to either have it or manage mutable state.
That task of engineering is not something to scoff at and I think building a new language or using an existing language with those ability would help. Erlang is not a number crunching language. But there are others such as Pony.
Much of the Python's appeal is in its huge, colossal, powerful ecosystem, with modules for everything, and things like numpy or tensorflow using it as the high-level interface language. Not breaking this is probably more important for success than efficient in-process data sharing. (Yes, process pools, queues, and a shared DB cover most of my cases.)
In fact, other than "run lots of Javascript", I'm not sure I can name a single thing Node did before Python.
How web workers aren't threads? Browsers are more widely deployed than Node, even with the same V8 engine.
The initial implementation may need to assume single-threaded C interface support and take a global lock but it wouldn't be a stretch to have these things declare they are multithread aware and relax that restriction.
Forgive me but most of these objections seem like post-hoc rationalizations. The first step is deciding to support a GIL-less multithreaded mode. After that, solve the problems one step at a time.
It is amazing how many times accomplishing "magic" boils down to:
1. Decide we're going to solve this problem. 2. Iterate toward the solution in manageable steps.
#1 is by far the most difficult aspect :)
Python itself is just an implementation detail of the underlying VM.
I used to carry around a Perl program of my own on a printout to take to VLSI interviews. That way when I got the "Do you know Perl?" question I could bring it out and force the interviewer into MY stupid subset of Perl rather than being stuck in his stupid subset of Perl.
That's not a compliment to the language.
Why do I see Python programs that look like a weird mix of Lisp and Java? Surely it is because even with what Python enforce, there are many many ways to produce unclear code that really don't even has to do with the language used.
And why did my employer see the need for the comprehensive Python style guidelines manual... I guess Python bit just as hard as Perl.
Also now that Python is used more by newbies and non-programmers that is where more of the bad code end up (aka Perl late 90s, still pollutes the internet). The quality of Perl frameworks, libs, example code etc is actually increasing and getting easier to find.
I'll stick my neck out and say that personally I feel that Python is actually better in this regard. Perl pissed me off so much that I left Perl at the height of its popularity. I probably had least 5 years(probably closer to 10+, but my memory of dates is fuzzy--pretty sure I never used Perl 3, though ...) years of professional use of Perl under my belt at that point.
I still migrated to Python.
That's a pretty big indictment when someone is willing to go back to being a n00b rather than continue to put up with continuing grief.
> Why do I see Python programs that look like a weird mix of Lisp and Java? Surely it is because even with what Python enforce, there are many many ways to produce unclear code that really don't even has to do with the language used.
The difference, from my experience, is that newbies in Python don't write code that A) other newbies can't understand and B) requires excessive mental effort from experienced folks to understand. Neither of those were true in my experience for Perl. A newb in Perl would very quickly trip something that would boggle even your local Perl expert.
I remember when I was a beginner and posted a 15 line program to comp.lang.perl and watched several of the experts actually wondering what the correct interpretation of the grammar was. I don't think I ever managed to cause something like that in Python. Obviously, I threw that program out post haste.
Sure, people can make amazingly complicated things with generators, decorators, etc once they get the hang of the language. However, newbies don't normally do this in Python. As you point out, they normally write it like Java (for better and worse).
In Perl, newbies immediately had to grapple with things like list vs scalar context and god help you if you tripped over a corner case (although, to be fair, God, in the form Randall Schwartz, WOULD quite often help you if you asked on comp.lang.perl ...)
> And why did my employer see the need for the comprehensive Python style guidelines manual... I guess Python bit just as hard as Perl.
I would personally expect that any company writing a very large quantity of code would produce a style guide for any language they use.
> The quality of Perl frameworks, libs, example code etc is actually increasing and getting easier to find.
That's actually really cool.
Also, if you use .subst(‘y’, ’n’) instead of a regex it runs in under 9 seconds locally. Thats still much slower than perl 5 (which locally takes less than half a second) but they’re making great strides at improving performance.
time yes | head -n1000000 | perl6 --profile -e 'for $*IN.readchars { .subst("y", "n").print }’ > /dev/null
time echo "#include <stdio.h>
main(n){char*b,*s=n=0;getdelim(&s,&n,-1,stdin);for(b=s;*s;++s)*s=='y'&&*s='n';puts(b);}">s.c|yes|head -n1000000|tcc -w -run s.c>/dev/null
real 0m0.028s
user 0m0.023s
sys 0m0.019s
Hopefully more edge cases will be discovered and fixed as the implementation matures as well.