I feel sorry for you, but we’re talking Web here. That means we’re talking about a domain where Linux is above ~90% market share, and Windows probably not even registering a bleep on the radar. Maybe something like ~1% if they’re lucky.

Nice try to help, BUT: A Total & Absolute NO!

This might work with your ignorant & rich customers, Congrats!, but at the end of the day, call it by its name: F-R-A-U-D.
A favor: Stop misleading and misinforming the people on this forum, stop being a total disgrace to the Software Engineering world, and go back to your Fart based shitware building.

Some keywords in case you finally want to use your brain a little: Analysis, Design, Methodologies, Compatibility, Libraries, Reusability, Expertise, Dependencies, Limitations, Scope, Purpose, Extensibility...
Good luck making them fit to your fraud attempt.

I'm guessing a constructive dialogue is not what you are aiming for here. I'm not feeling inclined to pursue this further as I don't foresee this will evolve into any of kind rational discussion.

Best of luck.

If you really think you'd like it and are feeling tenacious in pursuing it. If you want to do it well, it is a big investment of time and effort.

While I know some of you just like to have your say about things that you have an opinion or interest in, I am wondering why you are all responding to something that is clearly an advert for Python ... SPAM by any other name.

Surely this thread should just be reported as such?

I'm not attacking any of you, even like some of you. It just all seems a bit weird to me.

How would you be responding if it was about taking out Life Insurance or the wonders of the Strapless Brassier.

Just saying. LOL

I think we're all aware of the spam (I even pointed out as such), but the simple fact of the matter is, being the time of year it is, with GOG's perpetual staff shortages already bad enough as is, I think we're all prepared to give these two weeks a miss in terms of support.

Here, have some light read:

unixsheikh.com/articles/so-called-modern-web-developers-are-the-culprits.html
(Published on 2021-12-17. Modified on 2021-12-19)

Thanks to your inexcusable example, incredibly sounds to me this phrase

"Some people argue that developer time is more costly than computing resources"

Which helps me to understand Why:
1) I never heard that atrocious idea before: It is a cancer coming from the Web development area, not on my court
2) You can repeat/express/sell that atrocious idea without any shame or realizing how it fully shits the Sw Eng. foundations

I really, really hope (and now aware, advocate for) that f*cking cancer of "trade-off between programmer time and CPU time" never infect the rest of the areas of Sw Eng (at least those I belong to)
Because there, we are doing our best (and are committed & forced to provide) serious work. Not just lazy lame excuses to deliver shit and later make-up with more shit. We must call shit the shit!

If you are really aiming for true & quality Sw development, please use critical thinking, get rid of that specific madness on yourself and help to stop it in general in your court.

Sw Engineering is still a young science in our time, it is our responsibility to make it right and clean the mess during the journey

Same, best of luck to you

And yet, in most problem domains, it is.

You haven't been paying attention then. Its not just the web.

Garbage-collected languages are all over the place.

One could even argue that C/C++ is itself an example of such a tradeoff. Assembly, afterall, offers the possibility of even more optimization.

Then again, there are plenty of atrocious buffer overflow exploits coming from C/C++ projects making the world less secure overall, so what is sh*t is a matter of perspective.

I'd rather make something that runs a little slower, but isn't riddled with atrocious security flaws.

It already has. You are just late to the party.

I'm automating operations in a genomic research center that handles government sponsored projects. You think what I'm doing is a joke?

You must be doing something REALLY important then. Lauching shuttles into space are you?

If you never had to deal with deadlines. I envy you. You must be very privileged (but also kind of out of touch with the reality most developers face).

I won't pretend that the software industry doesn't suffer from a wild west problem (it does).

However, part of the solution to that involves making it easier for people to write correct software and operate existing software correctly. Not dogmatically putting on additional layers of complexity to optimize in areas that are not relevant for a lot of the problems being solved.

First thing you said I wholeheartedly agree with. However, lets keep it real. A well designed piece of software is full of tradeoffs leading to a well designed solution for the problem the software is trying to solve.

Universally good software, irrespective of problem domains, doesn't exist. Its always contextual.

For example, micro-managing memory is necessary for some problems for performance reasons, but its also quite often a security & stability disaster waiting to happen. For software of significant complexity written by larger teams, it takes some iterations to get that right and in the interim, you got some fun memory-related security exploits on your hands to content with.

PS: Concerning your article. Yes, contemporary frontend web development that follows popular industry practices with the frameworks is a total mess of bloated complexity (its not even javascript anymore, "transpiling" another language into javascript is all the rage now, making the end result even harder to reason about). I bailed out of that some years ago (went from a fullstack developers to a backend/operations guy).

I don't particularly like bloated backend frameworks either, so again, preaching to the choir. I particularly dislike orms that come with some of those frameworks (databases are usually the performance bottleneck in most stacks, by all means, lets add an abstraction layer that will make most optimizations impossible without bypassing the layer).

(Omitted some language that really doesn't belong from this quote)

The trade-off is mainly an issue here because the code is running on a system not owned by the developers.

Server-side, this trade-off doesn't cause any issues, as the cost of CPU time is borne by the same ones who are saving by using less progammer time.

On the other hand, JavaScript in web sites is a different issue; here, the company developing the software is not the one that is bearing the coasts, which results in the "negative externality" problem.

Personally, I think that the capabilities of web sites should be more limited by default. In fact, I think it would improve the Web if there were some major web browser that shipped with JavaScript disabled by default. (Also, while we're at it, disable animations, video, and audio by default.)

On modern CPUs (that is, not something like the Z80 or 6502), C can be optimized by the compiler better than hand-written Assembly, at least not without a work by a master assembly language programmer. There's also portability issues; that x86 assembly code isn't going to work without emulation on a Raspberry Pi. (And if you're emulating, all the performance gain from using assembly language has gone out the window; emulation is slower than running code natively.)

These days, the main use of assembly language is to take advantage of CPU features that aren't exposed by the compiler. For example, there's an instruction that halts the CPU until an interrupt comes in; that instruction (most likely found in the kernel's idle task) is not something that C supports, because it's only rarely needed. Other examples might include the I/O ports on some CPU architectures (including x86; on the other hand, memory-mapped I/O can be done easily in C (or unsafe Rust)), or that shiny new SIMD instruction extension that's so new compilers don't support it yet.

Garbage-collected languages aren't suitable in embedded situations. In this case, CPU power and RAM are not as cheap or abundant as they are on more conventional machines. If you're mass producing a product, for example, and you can get it to run on a less expensive chip, you can get some significant savings by reducing your CPU/memory footprints. Also, you may have hard real-time constraints in some projects, where having the garbage collection trigger at a bad time could kill people. In this instance, you want a programming language that is predictable, and garbage-collection leads to unpredictability. (Note that C isn't as predictable as one would like in this space; I've heard about MISRA C, which are some C guidelines that are supposed to make C safer, but I'm thinking that this may be the space where something like Rust may end up being the best option in the future.)

Also, if you're launching shuttles into space:
* There's issues like cosmic radiation and limited power budgets that you don't have when writing server code.
* A mistake (or a bad garbage collection) can result in the destruction of spacecraft. (This sort of thing has happened; I believe that a space vehicle was lost due to code expecting one unit of measure but getting another, with no conversion being done. I've also heard about a case where the specification was written to use raw rather than smoothed data, and the programmer correctly implemented the incorrect specification, leading to loss as well.)

And yes, bad software can kill:
https://ethicsunwrapped.utexas.edu/case-study/therac-25
https://theinsurancenerd.com/therac-25-a-computer-bug-that-killed-many/

Yes, there are cases like real-time embedded systems, operating systems, AAA games and others where a low-level language makes sense. Context matters.

For a critical internet-facing server (read: Needs to be correct in its behaviour and secure) that doesn't need to do AI or crunch crypto-currency, a garbage-collected language makes a lot of sense though.

As for Rust, I've yet to delve into that language, but I'm definitely curious as to how they safely tackle low-level memory management (my experience with this coming from C/C++, it seems too good to be true, but I'll eventually see for myself).

They say the same thing about Java vs C/C++ (ie, that you need to know optimization details to write C/C++ code that runs faster). I'd argue that if you are not highly pro-efficient, you should stay clear of the lower degrees of details that a lower-level language entails to begin with.

When taking advantage of fine-grained lower level optimization, it is assumed to be performed by someone who is proefficient and knows how to optimize things.

You could just write a separate assembly implementation for each cpu architecture. Why don't we? Because... ding ding ding... it takes too much time. There we are: at the dreaded implementation time vs runtime tradeoff.

Rust uses borrow and lifetime checkers to catch many of the mistakes that would lead to undefined behavior in C.

For example. consider this C code:
int *bad_return() {
int return_me = 24;
return &return_me;
}

C code that compiles without any error (though a good compiler will give you a warning) (and, of course, assuming I didn't make a mistake here), but it doesn't do what you want. The returned pointer is a dangling pointer, so using it causes unpredictable results.

The Rust equivalent (after using the error messages to help fix the code a bit):
fn bad_return() -> &'static u32 {
let return_me : u32 = 24;
return &return_me;
}

Try it, and you get an error: (Formatting off because GOG doesn't support the code tag.)

The Rust compiler also enforcers there being no shared mutable state (so if you have multiple references to the same part of memory, they must all be immutable).

Another interesting thing is that, in Rust, variables are const by default. "let x = 2" makes x a constant that can't be changed; if you want to be able to change it, you need to do something like "let mut x = 2".

By the way, Rust's compiler errmr messages can be quite helpful.

You can try Rust in your browser:
https://play.rust-lang.org/

Ok, so it catches a greater range of deterministic errors that are inferable at compile-time.

But some memory errors in C/C++ are not tractable at compile-time (dynamic memory after-all is inferred at runtime, not compile time).

What do you do, for example, if you take a numerical input in your program, use it to create a dynamic array of that size, then have an increment loop that isn't deterministic at compile time (maybe something based on system time, its weird, but it illustrates my point) increment an index to access the array with a runtime value causing it to access out of bound?

I'm all for immutability (functional programming is a great tool to enforce program correctness, I use its teachings even in non-functional languages), but it has a performance penalty (negligible for most problem domains, but it has a cost).

If the shared mutable state is large, you'll pay a penalty on writes over simply using agreed-upon access conventions and some mutexes to ensure there is no conflict (a mechanism that is extremely tricky and error-prone to get right, but if you need optimal performance...).

I'm sure. The unhelpfulness of the C/C++ compiler (back when it was my bread & butter anyways) is hard to beat at times.

Golang and Python give way better feedback too.

I'll keep it in mind, though if I want to do Rust, I'll do it proper and either read a book and/or follow a course and peruse the official docs.

While I learn a lot due to the time I dedicate to it, I'm a bit conservative with technology at heart. I don't use a tool until I've understood it well (I don't need to read all the code for dependencies that are very large, though I do expect at the very least to get a lot of wisdom from people with a great deal of experience in the tool, usually indirectly via a book). It does create a hard limit on what I can use which I find healthy. It forces you to prioritize on what truly matters and it causes fewer failures in production.

(About Rust)

You don't do that in Rust; rather, you use a Vec instead.

Indexed accessing performs bound checking, and I believe will panic if you go out of bounds. Rust's for loop is more like a for_each loop, allowing for efficient safe access to the array. There's also an unsafe method of accessing the array by index without bounds checking, but it can only be used in an unsafe function or block.

Rust actually does have mutexes in the standard library, and they can be used if you need to access shared mutable state; the language and library won't let you do things unsafely in this instance. (I believe, however, that Rust has no inherent protection against deadlocks; in other words, Rust considers deadlocks safe. Then again, Rust considers memory leaks to be safe.)
You are going to want to test out snippets of code to see how they actually work while you are learning; the Rust playground is very good for that sort of thing. By running bits of code (or even just trying to get them to compile and looking at the error messages you get), you can learn a lot more than just looking at the docs. The playground isn't what you'd use for a major project, but it's great for just playing around and getting a feel for how the language works. (I believe it's also been used for bug reports.)

Anyway, if you're ready to learn Rust, there's a nice official page with some resources:
https://www.rust-lang.org/learn

There's still this example in Python:

Python 3.9.2 (default, Mar 12 2021, 04:06:34)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> if 0:
... 1
... 2
File "<stdin>", line 3
2
^
IndentationError: unindent does not match any outer indentation level

(You can't see it, but there's a tab before the "1" but a space before the "2". If done in the reverse order, the error message is better.)