Why are there so many programming languages? And why are there still being so many made? I would think you would try to perfect what you have instead of making new ones all the time. I understand you need new languages sometimes like quantumcomputing or some newer tech like that. But for pc you would think there would be some kind of universal language. I’m learning java btw. I like programming languages. But was just wondering.

    • mo_ztt ✅
      link
      fedilink
      English
      101 year ago

      It’s not a matter of better or worse (in this particular case – there is such a thing as languages that are just plain bad). In my opinion, it’s just what you’re trying to do:

      So Node uses a multiprocessing model where your program won’t be interrupted in unpredictable spots – there are very specific places where a function might pause waiting for something to happen, and give way to another function, but during ordinary (“synchronous”) operations you can be guaranteed that the program won’t be interrupted. That makes things hugely simpler because in general, you don’t have to mutex-protect your data structures, you don’t have as many weird subtle bugs that only crop up during certain thread interactions that are extremely difficult to debug. That’s the upside. The main downside is that because it’s a single-threaded model, which means (a) you can’t easily scale up your program to multiple CPUs and (b) if you have a long CPU-bound operation, it’ll happily block the whole rest of your program from executing no matter how many problems that causes. It’s excellent for network-I/O-bound workloads, because you’re probably not heavy on computation and it’s simpler to program and more robust than using multithreading in that case. Although, you do have to learn some new primitives and make sure to be careful with CPU-heavy operations. Then there are a lot of workloads where it’s awkward to try to use.

      Java tried to do multithreading all the way from the ground up, to make everything thread-safe (which is actually pretty unusual for a full-featured runtime environment, because it’s a lot to take on). The upside is that if you need that, it’s gold; you can write your normal application and then run it on a 64-core processor and all of a sudden (relatively speaking) everything just works, which is great for massive-within-a-single-process scalability. The downside is that (a) you will get people who disagree vehemently with you on whether within-a-single-process scalability is worth the complexity cost you pay, and (b) if you’re just trying to write some code where you don’t care about threads, guess what? You have to care about threads. You need mutexes, you have subtle bugs and deadlocks, you have lots of extra testing headaches, or else: You can sort of close your eyes and run your Java application single-threaded, which defeats some of the purpose, and also God help you if later on you ever want to try to make it multi-threaded.

      Neither one I would say is right or wrong. There’s a whole third way, which is actually what most environments do, which is that you say that a lot of things in the runtime aren’t thread-safe, and so if you want heavy scalability you do it with multiple processes, and if you need threads you need to take on the responsibility of tiptoeing around the non-thread-safe stuff. That’s sort of a mess, which is why both Java and Node take different more coherent approaches to it.

    • There isn’t one, java is excellent for async and multithreading and it does it properly unlike node that fakes it by running on a single clever event loop or stealthily launches a bunch of node instances in the background depending on implementation.

      • mo_ztt ✅
        link
        fedilink
        English
        41 year ago

        I talked up above about my feelings on it – I did Java and J2EE programming for years back in the day, so I’m well familiar with Java and its very real strengths and very real weaknesses. There’s good and bad to the many-threads-in-a-process approach, and to the one-process-per-task approach, and to the one-thread-with-async approach. If what you’re looking for is many-threads-in-a-process, then yes, Java does it right. But if you’re looking for something else, maybe it’s going to be wrong. It just depends.

        Also can you explain a little more about the implementation that stealthily launches a bunch of node instances in the background?

      • @TempestTiger@programming.dev
        link
        fedilink
        2
        edit-2
        1 year ago

        My bad, I was mostly curious about how it matched OP’s project better and why.

        When you say it does it properly, do you mean actually creating proper threads or something else?