[jiofih]

That’s a load of gibberish. JS as a language has nothing to do with browser APIs, why would you judge it based on that? Also, ES6 was ratified six years ago.

Seems like you had a bad experience with espruino / jerryscript or something and are projecting based on that?

Dynamic languages are easier to program in. That’s a fact, and why they are so popular.

[golergka]

Although I like Javascript (Typescript) a lot, I have to bite:

> Dynamic languages are easier to program in.

Only if you don't care about writing correct and maintainable programs. The only thing that dynamic languages make easier is writing code. Or, more specifically, the first couple of versions of it. That's not what typical programming as a process mostly consists of.

[jiofih]

By the definition of formally correct, yes, you’re right. But dynamic programming still allows programs to be functionally correct, and verified by testing, which is more often than not good enough.

[golergka]

Writing and maintaining a program in a statically typed language is significantly easier and faster than doing the same in a dynamic language while manually writing all the tests that would cover the same level of correctness that types give you out of the box.

[hootbootscoot]

gibberish? "JS as a language has nothing to do with browser APIs, why would you judge it based on that?" Excuse me? That is precisely what JS is based upon. Lemme give you a prime example: JS = a single threaded event loop, ON PURPOSE. That directly affected Node.js as an implementation.

Your browser has an embedded scripting engine. Embedded, meaning, the source code for your browser includes the scripting language engine, and JS can run on that and script various permitted things via the browser API.

ES6 may have been ratified six years ago, but it's not the target code your front-end build chain spits out, is it... browsers don't uniformly support it yet. fun facts.

Look, I've been programming JS since it was invented. I'm not impressed by "classes" that don't exist, arrow functions, async/await, futures, promises, fibers, and assorted hacks that don't mirror the actual CODE (what computers execute) a JS engine actually is based upon. I don't need these tools, why should I use something that I need to transpile when I can code directly for browsers as they are in 2021, including legacy browsers? I don't find ES6 "easier" in any way..

Regarding dynamic languages on microcontrollers: Dynamic languages cannot directly control memory allocation and manipulation, typically are heap based and have no concept of a stack frame, and are basically just a computer program written whose corresponding code instructions (machine code) and execution path is scripted by your high-level language. Read a JS engines source code, study embedded C, and get back to me as to how suitable you find it for timing deterministic embedded programming. LOL

Types are directly related to memory size allocations.

Study the recent crop of LLVM languages, including some very interesting ones like LuaJIT, which should be right up your alley, and note the role Garbage Collection (check the Boehm implementation, for example) plays in many of the object-oriented languages, as well as Go.

Look at the actual assembler instructions you require a computer to perform as a result of your high level specification.

I am NOT speaking gibberish.

I agree that dynamic languages are considered easier to program in.

When speaking of programming languages, they are not all on the same level. One cannot say "oh assembler is fine and all but i prefer lua", as it's like comparing apples and atoms.

there's a reason that you can implement a lisp in c, but that the contrary is not viable nor makes any sense. (although metaprogramming c with lisp makes a lot of sense :D)

[ljm]

And you boil all that down to 'JS is trash'?

> JS = a single threaded event loop, ON PURPOSE. That directly affected Node.js as an implementation.

That's not a criticism. It's not different to desktop app dev where you try to keep your processing away from the main thread, only it provides an easier interface through async programming. Synchronous = main thread; async = other thread.

Amazingly intuitive model.

> ES6 may have been ratified six years ago, but it's not the target code your front-end build chain spits out

C++14 may have been ratified 7 years ago but it's not the target code your build chain spits out

> Look, I've been programming JS since it was invented...

You're free to write pure assembly, and you don't.

> Regarding dynamic languages on microcontrollers

Python in particular has made this kind of programming mainstream

> Read a JS engines source code, study embedded C, and get back to me as to how suitable you find it for timing deterministic embedded programming. LOL

You're gatekeeping, and that's also your ego. You need to work on that.

> there's a reason that you can implement a lisp in c, but that the contrary is not viable nor makes any sense.

What!? I can build C in Lisp as much as I can build any other language. I parse the syntax, create machine code, and output a binary. How the hell do you think languages are built? How do you think C was built?

Just stop, man. It's not gibberish but it's bullshit.

[eyelovewe]

Hey so can I write a device driver in JavaScript and is it a good language for that? How about my dma controller and python? What am I reading here. Not a comp sci major eh? Pass me something by reference in JavaScript, please

[jiofih]

Anything is a “good language for that” if it meets your needs. If you can run the js VM in 128KB of RAM and have decent performance, why not? I guess you would be ok with a Lisp in a microcontroller even though it would also run a VM?

Do you think Arduino would have had any success at all if you had to write C or Assembly to use it?

[ljm]

What's your point, exactly? You can write a driver in practically any language.

> Not a comp sci major eh?

I guess you're a comp sci major.

[eyelovewe]

I was a comp sci major.

Do you know what a Pointer is?

Do you know what passing by reference means?

Do you know what a heap allocation is vs pushing something into the stack?

Do you know what code and bss segments are and what they are for?

This is not about being right or wrong, I just can’t stand to watch total nonsense go unchallenged.

No, you cannot write a hardware device driver in a dynamic language, which is not to preclude code generation approaches, but to point out what low level hardware programming actually consists of: manipulating memory, registers included

[hootbootscoot]

1) I did not originate this "is trash" phrase, but replied to a parent comment you had rather excoriate. I said that Javascript is fine for what it was designed for: a single threaded UI event loop in a web browser. It is NOT good as a high-volume web server, for example. Http has a request and response cycle and is deliberately stateless such that all data goes out of scope and the entire thing can be deconstructed and, poof, no memory overhead nor leaks. It was designed that way, as a protocol.

2) I saw your comment below. You cannot write device drivers in the language of your choice on any of todays popular operating systems, nor on any embedded devices. Device drivers must have low level access to things like memory locations and cpu registers. Such things are not exposed to Javascript and not available. This is not even speaking about performance and garbage collection etc.

Look, Javascript is someones computer program. It can be implemented in very little code: here's an example: https://github.com/cesanta/v7

Languages are not all equal nor do they all function in the same way, and that's not my opinion.

Javascript syntax itself is one thing, and you can certainly feel free to Javascriptify some C++ libraries and make it all look a certain way for specific tasks, while managing things behind the scenes, up to a point... but there is no getting around the fact that SOMEONE and some languages are needed to implement low level systems functionality.

the power of Cython or the Python C FFI is that it allows you to script/glue modular native code.

You then state "C++14 may have been ratified 7 years ago but it's not the target code your build chain spits out"

no, a C++ COMPILER spits out assembler code that then gets assembled and linked into an executable.

The C++ or C code corresponds directly to a given set of assembler instructions which correspond directly to CPU instructions.

You claim that Python programming of microcontrollers is mainstream, but this is not true nor possible. Python SCRIPTING of code modules (that cannot be written in Python) is certainly one way to assemble a system from pre-built legos.

If you refer to knowing what I'm talking about as gatekeeping and egoism, might I suggest that you insist less forcefully in the correctness of incorrect things you state? we could be done with this spat in short order if YOU would refrain from speaking falsehoods. lies.untrue things.

I look forward to your lisp c compiler. make sure that it's 100% lisp from the bottom up, or I'll consider you're having ceded my point. Consider that the lisp you author in has a garbage collection system that lisp cannot have written originally, nor has any semantics for the underlying memory structures of, but hey, I guess if one is committed to pretending that all languages are equal for all tasks, who am I to question ones self-identification with a given language.

[jiofih]

> It is NOT good as a high-volume web server, for example

You couldn’t have picked a worse example - your CS major seems to be needing a refresh. NodeJS came to be precisely because V8, single threaded and using an event loop, was GREAT at a high volume web servers. It massively reduced the overhead vs multi-process or thread based web servers and absolutely dominated performance benchmarks and concurrency. We started playing with 1M concurrent connections while you might barely get 100 on Apache a few years earlier. There were other async servers at the time (Tornado, Puma, Netty..) but the async-by-default ecosystem in node was a unique advantage.

Fast forward to today, it’s not an accident that the majority of high-performance web servers now are asynchronous and/or using cooperative multitasking (or even libuv directly, a spin-off of nodejs development): VertX, Actix, h2o, Jetty, go with goroutines, etc. It’s a much more efficient model.

[hootbootscoot]

1) you confuse me with a CS major on another thread. pick the right feud please.

2) "you couldn't have picked a worse example" HAAAA! You are wrong. wrong wrong. A) Do you even know what a memory leak IS and why/how it occurs? B) Did you understand what I said regarding stack allocation and out-of-scope equals "memory gone" and how that fundamentally differs from heap-based allocation as ALL JS OBJECTS ARE!??? you are wasting my time, friend.

you are straight up copying marketing lines from node.js with no apparent understand of what a single threaded event loop even is! (it is a gui system. almost all windows-style apps since 199whatever have an event loops as ONE of it's threads. Open X-code or Visual Studio and make a generic desktop app, and add a button and make it's click handler call a method of something or other. Check a moderately complex audio visual production application for clues on just how many threads one uses and for what purposes are they separate threads, etc.)

You then mention VERTX AND GOROUTINES RIGHT AFTER EXTOLLING THE VIRTUES OF A SINGLE THREADED EVENT LOOP. GO LOOK UP WHAT THOSE 2 SPECIFIC TECHNOLOGIES USE AND DO, VERSUS A SINGLE THREADED EVENT LOOP.

Do note why single core limits exist for single hardware thread execution worlds and stop saying that interleaving tasks on a single execution core is superior to architecting synchronized activity across all cores, and do note that you are primarily referring to CRUD web-dev while positing very erm controversial positions on programming language use-cases.

Node JS is a terrible high-volume web server as all of the alleged virtues you extol are workarounds from the single threaded execution model of what was never designed to be a server language. I will say it again: HTTP is a stateless protocol involving a request (method call) and response (what it returns) it then goes out of scope and disappears. no memory leaks. no heap memory allocation. no malloc. no new, etc. it's just poof gone. got it? this was done on purpose by smart computer people. If you want to run each request as a separate OS process, don't blame HTTP, but the primitives were designed for efficiency.

please DO look up what heap vs stack allocation is. please DO look up what a register vm vs a stack vm is. please DO not confuse scripting or glue code with machine code, as the machine code of your javascript program is precisely the javascript runtime with it's execution paths being puppeted by your script language. you are literally pushing someone elses buttons and calling it computer programming. no offense, that's why it's a high level language not a low one.

when you resort to reductio ad absurdum suggesting assembler as the tool for all programming, you are not engaging with anything I have said or written here, as tools have purposes, not everything is a hammer/nail

in a way, you are not wrong, as a macro-assembler, or C or C++ or Rust or Zig or Nim etc (non garbage collected compiled language capable of outputting machine code as the final target) is the next level up from asm.

Why do you suppose that Chrome is not written in JS but rather largely in C++?

[jiofih]

Wait, where do memory leaks come in and what the hell fo they have to do with the subject at hand? I was talking about it’s fit for web servers, not embedded development. I’m disputing very specific comments you have made. You completely ignored what I said, and now accuse me of “copying marketing lines” and not knowing what an event loop is? Really? Is this how you win arguments?

I don’t know what you’re excited about yelling in caps - VertX uses and event loop. Goroutines are cooperative scheduling. Yes, they can also coordinate over multiple threads (guess what, node can too) but the underlying architecture for processing requests is the same.

> Node JS is a terrible high-volume web server

Again, why would that be? Node was invented precisely to be a high performance server. It’s literally it’s purpose, and it delivers. Check out any benchmarks like TechEmpower and guess which platforms you’ll find near the top. I’m not saying it’s the best choice but just stating facts. Nothing else to say here - you obviously have strong opinions but zero hands-on knowledge on this area.

[jiofih]

> That directly affected Node.js as an implementation.

It didn’t “affect” node, it was the whole reason it came to exist: its cooperative multitasking was a good way to tackle concurrency (remember c10k), and V8 was available and easily embeddable. Without the event loop there would have been no reason to choose JS.

[lispm]

Though there are C compilers and also C code generators written in Lisp.