And Java doesn't even have good (conceptual) support for concurrency. Compared with eg Erlang, Rust or even Haskell.
But Java was still better at it than C or C++ at the time.
One can make a solid argument that modern Java is adequate. But I don't buy you believe that of early Java?
Still way after Java was released I guess
When one really does need shared mutable state. Haskell supports transactional updates to mutable state (STM), with optimistic locking and rollbacks. It's awesome, but unfortunately just not practically possible in any language with rampant uncontrolled side-effects.
I would say that in some ways this is simply incomparable to java but I think this concurrency model is probably the easiest and simplest to work with of any concurrency model.
There are obviously drawbacks like with anything but for a lot of situations it's an excellent choice.
hint:
% cd /usr/include
% ag --no-color '[^A-Z]_REENTRANT'I suppose I could just dismiss the comment, but curiosity got the better part of me. I'm glad someone asked. I also had to search what "4GL" means. I'm assuming this top Wikipedia hit [1] is what the OP meant.
I don't know if it's reasonable to expect people to know these terms. But, the concise text is not saving anyone beyond the OP any appreciable amount of time, so what's its value?
[1] https://en.m.wikipedia.org/wiki/Fourth-generation_programmin...
Python was originally a teaching language, to replace BASIC and Pascal for kids and beginners.
(Yes, there once was a time when people took teaching programming seriously.)
> The letter “B” was chosen because it is the first letter of the word “beginner” and because the project was meant to become a language for teaching programming to absolute beginners.
[1] https://inference-review.com/article/the-origins-of-python
Yes, van Rossum was an implementer of ABC, which was a teaching language. Python drew on that experience, but also from Modula-2 and Modula-3, and the needs for writing an extension language for the Amoeba operating system.
From the initial release notes at https://www.tuhs.org/Usenet/alt.sources/1991-February/001749... :
[Python is] an extensible interpreted programming language that
combines remarkable power with very clear syntax.
This is version 0.9 (the first beta release), patchlevel 1.
Python can be used instead of shell, Awk or Perl scripts, to write
prototypes of real applications, or as an extension language of large
systems, you name it.
And between C++ and Rust coroutines, still not sure which one I like less.
I, myself, am not a Go guy, but I feel it has to be mentioned here. Go's approach might not be as universal as C++'s or Rust's but I think for a large number of use cases it makes sense.
There is a best practices guideline from one of the ASP.NET architects, https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/b...
During last year they researched adding Go/Java's approach to .NET, but now it is too late. See the ASP.NET Q&A session at BUILD 2023.
Aside from being to late (already having two models and not wanting to add a third) they also mention that the Go/Java approach adds a performance penalty when calling native APIs.
For example, you can't safely use print in a Python signal handler, because the entire I/O system is not reentrant [1], yet the documentation shows doing this in a "how to do it properly" example [2] while explaining that it's horribly unsafe to throw from a signal handler, which is the default for SIGINT. (And also the reason why the threading module doesn't expose PyThreadState_SetAsyncExc). So despite appearances to the contrary (since the Python signal handler is invoked by the VM, it doesn't actually run in a signal handler context; the signal module registers a C handler which simply sets a flag that is checked by the VM every instruction), you should probably only do in a Python signal handler what you would do in C, which is very little. Set a flag or write to a pipe. Don't go around and call library functions.
[1] E.g. https://bugs.python.org/issue24283 [2] https://docs.python.org/3/library/signal.html#note-on-signal...
Around that time, doing cross-platform C++, I got an early look at Java, with concurrency built in from the start, along with GC and various other nice features that were easier to use than C++, and I "knew" it was going to be huge. (But who knew that the MIS people would take over Java, when it seemed clearly targeted at non-MIS programmers, and now MIS people are stuck with the C++ syntax and verbosity, after coming from 4GLs, etc.)
Then mainstream programmers picked up Python, which, IIRC, originally was an embeddable extension language, which was why it was simple. And for which the GIL made more sense.