Based on @Lensflare saying not everyone should start low level.

My first language was C++. As much as anything I think it's better to start with higher level languages just because there's so much you need to get through before you can really run your first line of code. The likes of godbolt has made this so much easier, but I had to set up a compiler and build system before running anything. Legacy tooling... It's getting better, it's possible to write a bazel build system config that will download a compiler for you, only takes a dozen lines or so.

@Demolishun JS is not high level though. It‘s clown level.

@Lensflare Hear me out.
Build your own CPU in logisim, cobble together a basic instruction set, and try writing an emulator in C as well.

But since GUI programming sucks, and most people can't deal with a console window, you give up and decide to port your emulator to JS.

Then you go insane and write an assembler which spits out binaries for your CPU using Node.JS.

FYI, this is what I did. I actually went to therapy then.

@Ranchonyx you know, there are more languages than just C and JS ^^

And there are great languages that are more high level than JS and allow you to do low level stuff like you would with C, with high performance and low memory footprint, without GC, and multiple zero-cost abstractions and security features.
(And are also awesome for GUI development)

You don‘t have to pick between two different kinds of bad.

@Lensflare Tangent: zero-cost abstraction is a rather deceiving term. There is always an overhead -- one is merely given the guarantee that doing it by hand wouldn't be any better.

In my experience, begginers realizing zero-cost doesn't mean "no cost" without someone first explaining it is simply unheard of. Saying efficient abstraction, to imply workable cost instead of somehow none, is far more appropriate.

On topic, I have profound disrespect for the idea that high level concepts should be taught first: entirely skipping fundamentals for the supposed ease of a lecture is truly the most obscenely counter-productive approach to education.

But requiring an at least superficial understanding of C is still a necessity due to it's ubiquity; starting from there is an acceptable compromise. You can then teach assembly basics via analysis of compiler output, to later move on upwards. The attentive student wouldn't wind up being entirely clueless, not quite as often at least.

Oh boy... JS devs struggle with implementing logging in node apps, that doesn't relynon random scatterred console.log. And you're talking about low-level? Pointers, memory remapping, registers, L1-3 and stuff?

If every dev started low-level, I'm fairly confident they would stay there. We'd have 99.7% fewer js devs.

@Liebranca zero cost abstraction means that it doesn‘t need computation time or memory during runtime because it was already computed at compile time. So it IS literally no cost. It‘s not deceiving.

A colleague once thought that a bool was actually stored as a 1 bit value in memory.

This was when I realized that, when you start with c or even assembler, you automatically learn that this is not how it works.

On the other hand, is this info really relevant if you do web development all day? I would say no, it‘s not.
I‘m glad that I know how it works and I know that this is useful in some cases in programming, but most devs simply don‘t need to know to do their jobs.

It‘s similar to how not everyone is required to know how to reverse a binary tree.

I think many devs are being a bit elitist when they say that everybody should know.

@Lensflare No. It means the compiler, in an ideal circumstance, generates output that has comparable performance to what one would get if applying optimizations manually. If any of the operations involved cannot be solved at compile time, which for any non-trivial construct is virtually always the case, then you will pay for it. There always is an overhead. Even if you simplify an entire F into one constant, you still pay a cost for reading it. You are thinking of abstraction in terms other than practical; runtime cost means executing instructions, that is, work for the processor. Webdev or not, this should be nothing but self-evident.

There is indeed elitism and pedantry embedded into the stance, such as me right here, or when I'm being derogatory to every language utilizing annotations and Walrus, or you yourself being on an ongoing crusade against this 'clownery' you speak of. Either way, computation can be efficient or inefficient, but it can never be free. Hence, no zero-cost.

@Liebranca seems like we have a different definition of zero cost.

@Liebranca

Zero cost abstraction doesn't mean that computation is free. It's never free, that's evident.

Zero cost abstractions can be reduced to "don't pay for what you don't use". Meaning that you don't incur a runtime overhead for including and not using an abstraction.

And it also means that you couldn't, on normal scenarios, get better results by doing it by hand.

@Lensflare hahah word

@Lensflare was your colleague a c++ dev using bool vectors coz if so... They were right

@atheist no. Java or C#. I don’t remember anymore.
I know about c++ bool vector but that's an implementation detail of the vector and is an exception. Normal bool variables are sizeof(int).
And if we want to be technical, a single bool in a vector<bool> wouldn’t be stored as 1 bit. It would still require at least a few bytes. It’s just that subsequent values are being bit packed.

@Lensflare

Normal bool variables are one byte, not 4 (size of int).

@Lensflare Yes and no. I understand the distinction between there being no *additional* workload and eliminating the workload altogether. But the original point I made two comments ago is absolute begginers confuse one for the other when first hearing the term, and so this distinction has to be explained. Thus, I've concluded "zero cost" is unintuitive, and should be avoided.