Yeah well it's pretty obvious that you can write slow code in any language.

The interesting question is whether the code produced by the average programmer of that language is fast or not. And there language choice matters quite a bit, both because of language design (i.e. how easy is it to generate good machine code for that language) and because of the culture associated with that language (e.g. you can write extremely efficient Java, but typical Java programs chase a lot of pointers and generate a lot of garbage).

>whether the code produced by the average programmer of that language is fast or not

Not just this, but the ceiling of performance improvements matter a lot too.

Rust allows you to write high-level code, where you can "easily" jump into Rust coming from JavaScript. You performance might be on par in your initial versions while you are getting into the language.

It starts to matter a lot when you now have a working application, and you start using it. With JavaScript you will quickly reach a point where your idiomatic JavaScript is about as fast as it'll go.

With Rust, there usually keeps being tricks you can pull to squeeze more performance out of it, and you can do it just for the hot-paths of your code instead of rewriting the entire thing in a new language because you reached your limit.

A good example of this limit is something like the TypeScript compiler. It has huge performance issues with larger codebases, but unfortunately there's not much that can be done without rewriting the entire damn thing in e.g. Rust, because you've reached the limits of JavaScript.

>Not just this, but the ceiling of performance improvements matter a lot too.

But the floor can matter too. For someone trained to write high-performance JavaScript, JavaScript's performance floor is higher than Rust's, and they can write more JavaScript faster.

> A good example of this limit is something like the TypeScript compiler. It has huge performance issues with larger codebases, but unfortunately there's not much that can be done without rewriting the entire damn thing in e.g. Rust, because you've reached the limits of JavaScript.

Actually, you can fix it by rewriting it as a single-pass compiler to improve the algorithms.

>But the floor can matter too. For someone trained to write high-performance JavaScript, JavaScript's performance floor is higher than Rust's, and they can write more JavaScript faster.

I'm not sure what you mean by the floor here? Experience? The author of the article was experienced in JavaScript and was new to Rust for example.

>Actually, you can fix it by rewriting it as a single-pass compiler to improve the algorithms.

I'd say that's on the same scale of work as rewriting it in a new language.

And even then, this is most likely not a realistic solution, I can almost guarantee you there will be stuff they are currently doing that they cannot do in such an architecture.

The first problem with the words "single-pass" and "Javascript" that come to mind are the out-of-order variable declarations, i.e. var, which bubbles up.

There are a ton of other issues as well.

It's a really interesting and important question though; Do you measure a languages "performance"

1. by how fast it runs when written by a very experienced developer, or

2. by how fast programs run that are written by the "average" programmer, or

3. by how fast it runs when written by a bad or inexprienced programmer?

For each of these I can think of (at least) one language that would beat the performance of any other. There are languages that are "very difficult to use wrong", and there are languages that are difficult to use right. For the latter, C++ is a great example. You will copy and leak yourself out of memory before you terminate, if you dont know what you're doing.

Maybe we should stop comparing random languages from different domains by how fast they run.

My first take at an answer is, what sort of code do I anticipate writing in each language? And what sort of code do I expect to see from my peers?

Rust makes it surprisingly easy to write code that absolutely thrashes the memory allocator - using String/Box/Vec and adding .clone() everywhere makes a lot of tricky borrowing problems go away. Is that the kind of code I expect to be writing? Or running? And if so, we shouldn’t expect that kind of code to perform much better in most cases than javascript.

You're absolutely right, these are the kinds of questions any team should be asking

* Is language X that we all know suitable?" * Is there a language Y that we could all learn in an acceptable time optimal? * What does the tooling look like? * How would we bring in new people?

CPU runtime is just one aspect to consider

You measure it of course by how fast it runs when written by a very experienced developer. I don't see how you can argue any other way.

C, which is usually the fastest language in all benchmarks and the one others compare to is not inherently fast. In fact it is often considered faster than C++, which makes no sense since you can write C code in C++ (mostly) and the compiler usually has the same internals.

The biggest reason, I think, is that C encourages you to be memory efficient. Allocating memory is not trivial and you have to keep track of all your pointers. On the other hand, it makes it easy to modify things in place, where other languages favor immutability. But if you do a lot of allocations, create a makeshift garbage collector, and memcpy a lot, then your C code will be really slow, because you are basically doing what makes other languages slower, but worse because other languages are heavily optimized for that use cases and your code most likely isn't.

An illustration: the C++ solution takes a std::string by value, incurring an unintentional copy of the buffer. C++ makes it easy to make this mistake. C does not. But for the same reason C++ also makes it easy to use complicated objects and allocations when you need them for performance.

https://github.com/cesarvr/AOCRust/blob/590270ed268dcd4ff01b...

Wow, that's some horrible code. No std::vector::reserve, string by value, memset, "using namespace std", missing includes, c-header includes in c style, ...

Rarely see this kind of obscenity outside of beginner's university C++ classes.

    int hasz[200];
    memset(hasz, 0, 200);

yikes, that initializes the first 200 bytes to 0x00, or only the first 50 integers in the array. this code is... bad.

> only the first 50 integers

or the first 100 integers https://gcc.gnu.org/wiki/avr-gcc

For anyone who isn't well versed in C, int is most of the time 32 bits but it's architecture dependent with some machines being e.g. 16 bit. If you need the size to be exactly 32 bits then you can just use int32_t or similar and let the compiler make that happen regardless of the architecture it's compiling to. The original code should have specified 200 * sizeof(int) or better yet since it's a local variable just ditch the memset and change it to int hasz[200] = {}; which will do the same.

People keep saying C is fast. It’s not. You can’t write a reusable fast sort in C. C++’s std::sort will trounce qsort any day of the week because qsort uses function pointers that can’t be inlined. Without inlined generic algorithms, how can people claim C is performant?

Memory allocation is expensive. C++ pmr allocators provide powerful tools to manage memory.

It is not the case that Rust will tend to end up slower than javascript or python if you don’t know what you are doing. Yes that happened in this particular example but it isn’t a given or even normal

I think there are a few different definitions of "faster" that can all be useful in different situations:

1. faster when written and optimized by an expert, who writes the best blog on how to optimize X

2. faster when written and optimized by a competent-but-not-necessarily-expert programmer, who reads the best blog on how to optimize X

3. faster when written without speed in mind

It seems like C, C++, and Rust are all more or less tied at the head of the pack for #1 and #2. There's obviously a lot of room for debate here, but it seems like many other languages (Go? JavaScript running on V8?) can get pretty close for #1 but struggle for #2.

For #3, it seems like C is the king, because of the very low-level style that it forces on the programmer. Below that things get murky. I'm inclined to believe Rust does well here, because it doesn't usually allocate without being asked to, but I assume the same logic applies to other languages I'm less familiar with (D, Zig). How well C++ does probably depends on how you interpret the question. (Like does the programmer make even the slightest effort to avoid implicitly copying big data structures, to take things by reference, etc?)

I learned this back in uni, trying to optimize things with a friend who was an assembly language whiz. He could take one of my C(++) algorithms and hand code it to be 10x faster than I ever could... but sometimes I could come up with a new algorithm that was 100x faster. There's a reason we say algorithm optimisation >> cycle counting.

What I found is that the more you help the C++ compiler understand what you want the more optimized the code gets. Using std::fill_n instead of memset alone can cause good improvements, depending on the compiler.

> This is why no language is "just faster" than another.

No, that is not what this is. Rust IS faster than most languages on earth.

This is FACT.

Some tools ARE better than others. You only heard the "opposite" when a outlier happened or a user misunderstood how use the tool.

Also this apply to interpreted languages too!:

http://lambda-the-ultimate.org/node/5075

IF you hit their sweet spots.

PD: Just check the Rust reddit. Tons of case of naive newcomers with massive improvements on speed/performance just porting to Rust.

---

This kind of history is similar to "A virus happened on OS X/Linux!" Then say "No OS is more secure than others!" is a massive flaw. Some are more secure. Only this time is news precisely because is RARE!

Honestly the safety is a far bigger drawcard to me than the performance. C(++)'s UB just scares me these days because it's often so subtle.

If you have to work with C++, I recommend using -fsanitize=undefined so you get runtime-errors when your program runs into undefined behavior. Very handy!

It's really useful, but it's dynamic. You need tests that actually trigger the UB to make it useful.

UB means unsigned byte in this context?

Undefined Behavior.

It adds a runtime sanitizer to detect some (but not all) UB.

Oooh I'm gonna add that to everything. Thankyou!