61–70 of 75 posts
Earlier quoted context omitted.
"interpreted language" and "compiled language" are category errors.
True, but since the same example can't be done with a Rust based bytecode interpreter, or a Python AOT compiler, due to lack of implementations to use for benchmarking purposes, the remark remains valid.
want to write fast rust? write your code in C or C++
you're getting downvoted because you said it in a weird way, but fundamentally I have to agree. Both C and C++, if written idiomatically, have less syntactic sugar and macros are less accepted, so that their code ends up hiding a lot less complexity than rust code. Fairly complex code like what the author showed turns out to use a bunch of different random things nobody expected.
the problem is that in a lot of applications nobody cares about safety or security. it is just that devs operate in evironments where that matters and they think therefore it matters everywhere all the time.
when a language does something for you you then typically don’t learn what it actually does under the hood which will come back to bite you later. i have some of that problem with the latest C++ features as well, btw, which is why my C++ tends to look like C with classes and here and there use of a modern feature.
> the point of this post isn’t to compare highly-optimized Python to highly-optimized Rust. The point is to compare “standard-Jupyter-notebook” Python to highly-optimized Rust. I guess the title gets clicks, but I'm curious how good python gets. I'm under the impression pandas is pretty fast despite it being python
as a rule of thumb, pure python code is often 1000x slower than naively written unoptimized native code. code in pandas can be very slow (standard pure-python speed) or "fast-for-python" depending on if you are going with or against the grain. a pandas dataframe is basically a bunch of numpy arrays, one array per column. if you do columnar calculations that can be reduced to numpy operations, like summing over a colu…
I think it's more like 50-200x in my experience. Which is still crazy slow, but not 1000x slow.
The Mojo PR team on their way to hire OP to publish these sort of articles at Modular.
I keep wondering if Mojo will take over the world or somehow become Betamax.
The problem is you're advertising performance and static typing to Python programmers, but pretty much anyone who is voluntarily choosing to use Python has already decided they don't care a jot about performance or static typing.
Everyone else who is forced to use Python doesn't have the option of introducing another language anyway.
Earlier quoted context omitted.
you're getting downvoted because you said it in a weird way, but fundamentally I have to agree. Both C and C++, if written idiomatically, have less syntactic sugar and macros are less accepted, so that their code ends up hiding a lot less complexity than rust code. Fairly complex code like what the author showed turns out to use a bunch of different random things nobody expected.
yep, i agree. most pro rust arguments are from a safety perspective or that rust does a lot for you. the problem is that in a lot of applications nobody cares about safety or security. it is just that devs operate in evironments where that matters and they think therefore it matters everywhere all the time. when a language does something for you you then typically don’t learn what it actually does under the hood whic…
Rust safety on the small scale is an enabler for stability in the large scale, giving the possibility to take more risky optimizations. This is exactly where C and C++ fall flat. You can write small scale stable software with them, but multy decade multi team 1000k+ lines of software turns in a CVE fest. A lot more effort in documenting interface details and validation need to be done,because the compiler can't do it for you
want to write fast rust? write your code in C or C++
you're getting downvoted because you said it in a weird way, but fundamentally I have to agree. Both C and C++, if written idiomatically, have less syntactic sugar and macros are less accepted, so that their code ends up hiding a lot less complexity than rust code. Fairly complex code like what the author showed turns out to use a bunch of different random things nobody expected.
Are you really saying this about C++? For real?
I quite like C++ but the idea that it doesn't hide complexity is hilarious. Something as simple as `a = b` can call constructors, copy constructors, assignment constructors, move constructors (depending on a lot of details), do implicit type conversion, throw exceptions, etc. etc.
In Rust it's just memcpy.
Maybe you're thinking of proc macros which can do a lot more than in C++, but they're just a more convenient way of doing codegen which you can equally do in C++ (e.g. to generate Protobuf code).
Earlier quoted context omitted.
yep, i agree. most pro rust arguments are from a safety perspective or that rust does a lot for you. the problem is that in a lot of applications nobody cares about safety or security. it is just that devs operate in evironments where that matters and they think therefore it matters everywhere all the time. when a language does something for you you then typically don’t learn what it actually does under the hood whic…
I disagree. There was an article somewhere about servo, mentioning advantages of rust vs C++ . One example was how less intermediate copies were made, as rust made it clear what data was immutable. Another was how rust made threading more easy, as it was more clear what data needed locks. Rust safety on the small scale is an enabler for stability in the large scale, giving the possibility to take more risky optimizat…