22 minutes ago, RivieraKid said:

An important difference to note is that JavaScript is forced onto the largest subset of user-facing developers. If google/ms/apple could get their fingers out and agree on a common vm JavaScript would die off practically overnight. Unfortunately MS already have a perfectly capable sln that they are prevented from using because of political. Google / Apple don't want to go down that road - they would end up delivering something very similar to .net and they know it.

Server side JavaScript only exists because JavaScript is a must on front end. People want to share their code base and that is the only practical way to do that. No sane developer would have independently developed JavaScript for server side if it didn't already exist.

I chuckle a little bit whenever I see that the next big thing in the front-end world is something that existed 10, 15, 20, 30 years ago...  We keep reinventing Java applets, Flash, UI paradigms that are old enough to order a beer, and even makefiles.  But in Javascript!

Each language has different goals in mind. Use the right language for the right job.

• C 
  • Close to assembly code. Easy to expect what your code will be compiled into
  • Good for embedded devices
  • Good for high performance bursts
  • Good C can be practically as fast as assembler (If you are willing to read the map files and optimise your code)
• C++ 
  • First and foremost: A way to extend C to support some OOP syntax
    • C was popular, and C++ allows you to write OOP only where you want it
    • You can easily use C code and libraries
  • The fastest implementation of OOP principles
    • Fast because you can allocate objects on the stack
      • Memory management  (GC) in other languages can be the costliest thing in the program
    • Fast because you can allocate packed arrays of objects
• Java
  • Designed to be stable and maintainable
  • Very easy to control and analyse large projects written by large teams
  • If you want to write a stable buisness application, that will never crash, write it in Java
• Javascript
  • Designed to run everywhere (achieved this goal way better than java)
  • Designed to be forgiving:
    • The event based nature of HTML bindings means that if something fails, the program will keep running
      • There is no main function to be thrown out of...
    • Asynchronous I/O in combination with the limit to a single thread means you get easy paralilism without alot of complexity
• C#
  • Microsoft saying: We can do better than Java
  • Much more advanced and agile than Java
  • If you want to write *MS only* code that does not need low level memory management, look no furhter
    • Yes, I know about mono. But every time I wanted to use it for non trivial projects, I hit some brick wall with a missing library or feature.
• Scheme/Lisp/Prolog:
  • Languages designed for exploring programming language syntax.
  • Very good for academic work
  • Very good for solving small problems in creative ways. (as opposed to writing an OS or a large Webapp)
  • Very good for solving mathematical problems

Before looking at their syntax, you can see that each of these languages are designed and optimised for different goals.

You would be insane to write a complex business webapp in C. (It will crash every time a new dev alters something)

You would be ludicrous to write an embedded (16k) kernel in Javascript

You would be a laughingstock use java to calculate large amounts of particle physics.

If you write *large* enterprise apps in python (untyped, interperted, and whitespace based) then you will have a bad time. No amount of linting can compare to the forced expressiveness of Java/C# .

If you write small programs in Java using a notepad (instead of a syntax parsing IDE), then you should really look into Python.

etc...

6 hours ago, Oluseyi said:

JavaScript is routinely compiled these days, with various levels of optimization triggered by access frequency and invocation history. This has been a big part of the performance improvements of Google's V8 and Apple's Nitro, especially on mobile.

 

Your argument is poor, and takes a single socio-political position as justification to demean and dismiss the entirety of someone's technological contribution. Don't do that; that's zealotry, too.

I would not consider run time compilation as very different than interpretation. For me, the main advantage of compilation (and static typing) is that it helps find errors in large projects before you run them. C# and Java JIT is not the same, because the languages are precompiled into bytecode, and it's only the bytecode that goes through JIT.

With Javascript, Python, etc... You have a much murkier idea of the state of your code before you run it. From a maintainability perspective: There is little difference between just-in-time compilation and interpretation. The main question is not: "Can a language be compiled?". That's because every language can be compiled... If I gave you instructions in Spoken English, you could probably interpret them and compile them into assembler. There is also nothing preventing you  from interpreting C at runtime. 

The interesting questions are:

Is the language designed to be compiled?

What design advantages do you get from compiling it?

What design advantages do you get from interpreting it?

etc...

23 minutes ago, SillyCow said:

Javascript, Python, etc... You have a much murkier idea of the state of your code before you run it. From a maintainability perspective: There is little difference between just-in-time compilation and interpretation. The main question is not: "Can a language be compiled?". That's because every language can be compiled... If I gave you instructions in Spoken English, you could probably interpret them and compile them into assembler. There is also nothing preventing you  from interpreting C at runtime. 

The interesting questions are:

Is the language designed to be compiled?

Beyond compiled vs interpreted, this is really veering into the territory of dynamic vs static typing, and also the strength and expressiveness of the type system. Javacript and Python aren't a PITA for large systems because they are interpreted - although things like exec and self-modifying code and monkey-patching don't help - it's mostly because they've got dynamic type systems that are pretty weak. Static typing isn't necessarily a silver bullet; C is statically typed, but weakly, and you can do all sorts of evil stuff casting and poking at memory.

Haskell might be getting too far into the chains-and-whips masochist end of the spectrum, but it increasingly seems like evidence is piling up in favor of more strongly, statically typed languages. At least for anything that has to be supported and maintained and isn't quick-and-dirty throwaway code.

37 minutes ago, RivieraKid said:

3) Most languages have an asynchronous method for I/O. For a long time you couldn't do any significant processing in the front end because it would freeze the browser. You could ONLY response to events. It is still very painful to deal with a large volume of visual elements.

 

I challenge you to find an asynchronous I/O C++ 11 API  (or Java) that's as friendly as JavaScript's implementations. And while javascript uses multi-threading to do the actual I/O under the hood, the fact that all the processing happens on a single blocking thread makes it much easier to program (and slightly slower). With C++ and Java you would have to worry about synchronisation and deadlocks when doing multi-threaded asynchronous I/O. True, you could implement a single threaded message loop or a selector, but that's much more complicated to write and maintain. However, in Javascript, if you ever wanted to have mutlithreaded message*processing* you would have to work much harder than with C or Java.

That's why javascript is more beginner friendly. It takes the most common case ( that only the actual I/O takes time, and that processing is negligible), and gives you that out of the box. Requiring you to allocate new processing buffers for each request on the heap in the process.

That's why C is for more advanced use cases: You'd work 50 times as hard writing the code, but you can process requests in place on multiple threads.

And that's why Java is interesting: Because even though you'd still work 40 times as hard, you're huge code would be more maintainable if was part of a big project. (and it would run 50% as fast as C)

So if you're writing a small server side app with short bindings for javascript GUI code, use Node.js.

If you're writing a huge banking app, use Java.

If you need the extra performance because you are writing an HTTPS gateway (like NGINX) use C. 

If you try to write the banking app in C or Javascript, you are probably doing it wrong.

IF you write the massively loaded HTTPS gateway in javascript you are probably also doing it wrong...

I'm using the webapps as an example. Because with games, your choice of language usually just stems from the toolset you want to use: ( Unity = C# , Unreal = C++ , Browser=Javascript, Android = Java + C (NDK) , iPhone = ObjC, etc...)

1 hour ago, RivieraKid said:

(e.g. IE8) (all users must constantly upgrade to the latest edition or face poor performance), i actually stopped using firefox because for a long time it had aggressive hard barriers to upgrade every week. There are still differences between implementations.

I have rarely encountered a case where the  poor performance of a web page had anything to do with javascript performance. Most of the time it had to do with slow browser APIS, and slow implementations of Canvas and Vector art and Memory management, which are all implemented in C/C++.

As an early mobile HTML developer android allways had the fastest java-script engine, while apps allways ran faster on apple devices. This is because apple optimized their native browser code which was doing all the heavy lifting (decompressing jpegs, rendering canvasses, parsing CSS, etc...), while Android optimized javascript which usually does very little work on a webpage. Javascript usually just handled C-Parsed json coming from ajax calls, and fires DOM events like .show() which are then implemented in C (nobody draws an html button in javascript). So the whole "compiled javascript is so much faster" allways seemed irrelevant to me.

The same is true for game logic coding. The heavy lifting (physics, Spatial partitioning, rendering, and pathfinding)  are all implemented in C++ or shader code. What language you choose to call model.render() or player.pathfind() from is largely irrelevant from a performance point of view. In fact, if you choose to it in C you are probably working too hard.

To a large extent, it is even irrelevant what you call opengl.renderVBO from... I remember a long debate advocating the use of NDK over java in android to make openGLES calls. I decided to benchmark a switch to NDK over Java. The NDK calls were 17% faster than the java calls. Considering that opengl calls were only 40% of my execution time, that's a 7% increase in performance for a much more complicated code base in C. Hardly worth it...

Another point: Shader languages are one of the first cases of DSLs I can think of where the DSL was targeted directly at performance. They actually created a "weaker" language that was easier to parallelise, thus actually increasing performance by making things more abstract. This is the first wide spread example of a weaker language actually being faster than a powerful low level one.