Rust 1.24
blog.rust-lang.org
blog.rust-lang.org
> Historically, the compiler has compiled your entire project, no matter how little you’ve changed the code.
This isn't quite correct. When you change the code in a given library, it has historically recompiled that entire library, and all libraries that depend on that library. But the compiler has never recompiled any libraries that were deeper in the dependency chain: if you have crates foo and bar, and bar imports foo, and you change the code in bar, foo was not recompiled.
Looking towards the future, I'm most excited about the prospect of using SIMD on stable Rust, which looks to be coming this year: https://github.com/rust-lang/rfcs/pull/2325
EDIT: Also worth mentioning is that Rayon (an official Rust library providing easy data parallelism) just reached 1.0 today, which is an important milestone in Rust's march towards ecosystem stability: https://github.com/rayon-rs/rayon
IIRC, some group in mozilla has already has something working that works like ccache that works (or rewrote ccache to work) with compiling rust. (Which I think is what steveklabnik is alluding to in his neighboring comment.) Although I guess that might only work within a single code base, not sure about that.
Simple things like parsing the bytes into the binary representation go away. You can have more granularity of the cache because you don't need to worry about creating too many files. Not only from a performance perspective but also from a code perspective.
More nuanced things like cache locality can be improved with an embedded data store rather than creating files and hoping the OS understands they will always be used together.
More advanced things like retaining inverted indexes becomes possible and search performance is dramatically improved.
Most of the assumptions I'm making here are unverified, though, so take it with a large grain of salt.
Is there some algorithm in Rust which has a necessary big-O? There were compilers in the 90s which ran a million lines per second (on much slower computers). Incremental compilation feels like working around the problem rather than solving it, and I have to imagine the complexity and maintenance is much worse.
I'm sure some of the LLVM optimization passes are expensive, but those are used in clang++ too, and it's not terribly slow.
Those compilers performed nowhere near the level of optimization that modern compilers do.
> I'm sure some of the LLVM optimization passes are expensive, but those are used in clang++ too, and it's not terribly slow.
clang++ is sure slow if it has to rebuild an entire codebase from scratch.
The main reason that C++ compilers get away with not having partial compilation is that it forces programmers to do the division into code units manually through separate .h and .cpp files. Rust doesn't have this, except at the crate level, so it needs partial compilation instead. It turns out that partial compilation is better in the first place, because compilation units tend to be fairly coarse-grained: .cpp files frequently grow very large.
It's the cross-module optimizations that make the compiler slow. Those optimizations are in service of C++-inspired ideal of being able to use layers of abstraction to make your code cleaner, but having the compiler flatten them down so your program still runs fast.
It’s called incremental progress.
I'm simply pushing back on the idea that there's some obvious low-hanging fruit that clang did that rustc didn't. Compiler performance has more or less much been the #1 goal for well over a year now. The Rust compiler team (which hasn't included me for years, by the way) is fantastic. We'd all like for there to be some magic bullet that makes the compiler faster, but at this point I don't believe it exists. It's hard work from here on out.
I didn't suggest low hanging fruit or a magic bullet. If anything, incremental compilation is being promoted as that kind of thing, and I just wanted call it into question.
Not to mention the underlying insinuation, that the Rust compiler developers are dumb for not being able to get at the 80s compiler's level of speed -- since you don't seem to accept that this is a byproduct of the advanced optimizations and security guarantees they do.
Try to be scientific. If you've got a conjecture, test it and see if it holds water. One excuse was that C++ is only faster because people build C++ projects with separate compilation units. Well, you can compile a project in C++ with a single compilation unit, and it's not horribly slow. Now you need a new conjecture.
The type system is comparable to Standard ML from the 70s. The lifetime analysis is a solid improvement over mainstream languages, but I have a tough time believing it needs to be an order of magnitude slower than const correctness. The optimizations are on par with C++ and Fortran (mostly because they're leveraging the guts from an existing C++ compiler). SML, C++, and Fortran do not compile as slowly as Rust. There's probably another reason.
I don't think the Rust compiler developers are dumb, and I never said that. I think several of them are brilliant but young (and occasionally very arrogant).
Rust is so close to being a great replacement for C++. I read every one of these threads about new releases hoping they'll eventually fix the problems. Compilation speed and memory use are lesser issues, but they're still important, and things like incremental compilation dodge the issues instead of fixing them.
The type system of Rust goes significantly beyond that of Standard ML, because of traits/typeclasses among many other features. Also, Standard ML is usually not implemented with monomorphization, which affects compile time.
> Compilation speed and memory use are lesser issues, but they're still important, and things like incremental compilation dodge the issues instead of fixing them.
Incremental compilation is a way of addressing the compile time and memory usage issues. It's just not the way you seem to want them to be fixed. Nobody did incremental compilation for fun; it was done because without it we didn't believe we could reach our compiler performance goals.
Again, you're asking for a magic bullet, and I'm saying it's not likely that there is going to be one. If one existed, it probably would have been found already. There's lots of hard work that has been done, and lots of hard work ahead.
If I had to guess what the most important issue is, it's that idiomatic Rust generates a lot more LLVM IR than idiomatic C++ does, because it leans on abstractions for safety and developer ergonomics. Think about how many more closures Rust code uses, what for loops expand to, what pointer arithmetic compiles to (ptr::offset), etc...
> Incremental compilation is a way of addressing the compile time and memory usage issues. It's just not the way you seem to want them to be fixed. Nobody did incremental compilation for fun.
I'm well aware that my opinion doesn't matter, but I doubt incremental compilation will make any real strides towards making things as good as they could be. It sounds like the real problem is here:
> If I had to guess what the most important issue is, it's that idiomatic Rust generates a lot more LLVM IR than idiomatic C++ does
I suspect every single feature in idiomatic Rust has a one-to-one translation to some bit of C++ that isn't too horrible. You can do lambdas, iterators, generators, or whatever else it takes to do Rust style for loops and closures in C++, and it won't choke the compiler. So while I don't doubt rustc is generating a lot more IR, I doubt it needs to.
Maybe the MIR optimization pass will move in that direction.
I think this gets at Wirth's law a bit. Yes compilers perform lots of optimizations now, but in Rust's case it is at least partly because they need to in order to claw back the performance that the Rust gives up with its abstraction (as seen in debug builds).
I do much prefer Rust's safe abstractions to writing more direct code and hoping I get it right. I hope (and do believe) that the MIR effort will somewhat rein in the burden shunted over to LLVM, as it is super painful for some of us.
I think Proebsting's law is also relevant. Compilers did an impressive job of optimization in the 90s, and while yes there have been advancements in the last 18 years, it's foolish to over-estimate the progress.
Also, considering how much hardware changes have improved performance (speculative execution, register renaming, etc...), it wouldn't surprise me if many compiler optimizations have become less important with time. For instance, peep-hole instruction scheduling has to matter less than it once did.
It really does make a difference versus traditional UNIX compilers.
We have some hunches, but nothing super conclusive yet; basically, right now it's all about how much IR we generate.
Don't forget the differences in compilation model; C/C++'s compilation units are much smaller, so incremental isn't as big of a deal.
It's hard to say what exactly Jai does since it's not public yet.
Not everyone compiles C++ the same way. I prefer header-only libraries and a single compilation unit. Counting lines of code with "gcc -E" to get the headers, I just compiled 20,000 lines of C++ from scratch in .6 seconds with gcc and .4 seconds with clang. I don't have a comparable project in Rust.
(And in the case of uninstantiated templates, a C++ compiler doesn't even need to type check them…)
- Did you have optimizations enabled?
Not many. How many lines would a comparable Rust program have to instantiate? (should be the same)
All I was trying to do was make an apples to apples comparison by discrediting the implication that the clang++ and g++ compilers are only faster because people use separate compilation units.
I think it's fair to compare Rust and C++ this way, and if Rust is slower to compile, then it's fair to ask why.
> Did you have optimizations enabled?
Yes, -O3. Also -Wall -Wextra and -fwrapv if you're interested.
When you add generics, lifetimes, and type inference, the amount of work the compiler does grows significantly. It allows to check much more interesting invariants, leading to the "if it compiles, it runs correctly" effect.
Rust does have the opportunity to do more, and I suspect they are hoping to do more with MIR, but at the moment they rely on LLVM to optimize out all of the zero-cost abstractions that they introduce.
https://github.com/rust-lang-nursery/rust-forge/blob/master/... is how you're supposed to do this these days. It's a ton of work that I don't have time to do right now, but if you look at the example HTML output linked there, for a hello world, my broader point still stands, which is "translation 78.1%". That is, taking the MIR and turning it into machine code, first through LLVM IR, is the vast, vast majority of the compile time. Not the safety checks, not some un-optimized algorithm in them.
-------------------------------------
To make this concrete, here's a project I'm working on, with -Z time-passes: https://gist.github.com/steveklabnik/c2646b209debf1f66355343...
Some annotated bits of the larger passes:
time: 0.646; rss: 91MB expansion
time: 0.338; rss: 169MB coherence checking
time: 0.596; rss: 205MB item-bodies checking
time: 0.588; rss: 219MB borrow checking
time: 2.566; rss: 220MB MIR borrow checking
Then we get into a ton of LLVM passes. As you can see, most of them take basically no time. Ones that stick out are mostly codegen passes, which is what I was referring to with my comments above. But then we have:
time: 5.625; rss: 413MB translate to LLVM IR
time: 7.418; rss: 415MB LLVM passes
time: 9.437; rss: 414MB translation
Note that all of this is for an initial, clean build, so a lot of that stuff is setting up incremental builds. I deleted src, git checked it out, and then built again, and got this: https://gist.github.com/steveklabnik/1ed07751c563810b515db3f... way, way, way less work, and a faster build time overall: just five seconds.
So, anyway, yeah.
Right - my understanding is that Rust generates very large MIR and also LLVM IR because the "zero-cost abstractions" aren't yet zero-cost, and compiling them into zero-cost machine code is inherently expensive.
So it's not the safety checks per se, but it's things like "there are three wrapper objects here with various generic parameters where C/C++ would have started with just a pointer from the beginning". Those three wrapper objects couldn't have existed without the safety checks, and rustc very quickly identified that everything is in order, but then it monomorphized the generics into lots of tiny functions and LLVM has to optimize all of that into machine code that resembles what the (unsafe) pointer approach would have generated. (Which explains why it's not time taken in rustc proper, but also why we don't see LLVM being equally slow when compiling C/C++.)
Is that interpretation correct?
I might split out C++ from C here though; template-heavy C++ is known to be pretty slow to compile too, for what's basically similar reasons: you end up generating a bunch of code that needs to be crunched down.
There's also some possibly deeper reasons around heavy use of generics: if your code touches something that is generic, and you change the type, it's going to need to recompile that function too. And then anything generic it touches. Etc. Trait objects can help compile times for this reason, but they aren't considered idiomatic, so most Rust code tends to stress the compiler in this way.
Other languages with powerful generics and type inference like modern C# clearly manage just fine, too.
It is also the only deployment option on iDevices and Windows Store since Windows 8.
Also if you prefer other native examples, Ada, Eiffel, Sather, D come to mind.
They are actually, but only anecdotically (like PowerPoint is also Turing Complete).
AOT Java compilers certainly exist, but I don't recall Microsoft having one -- I fully admit my recollection of their Java dev environment is quite foggy at this point, though.
Regardless, the Java AOT compilers I've tried didn't seem particularly fast in relation to their level of optimization.
Sad that it is configurable, though. The biggest benefit of its predecessors such as gofmt is that they are not configurable, leading to a much more uniform formatting style and avoiding endless discussions about whitespace layout.
The defaults are what's considered the "official" style; we expect the vast majority of people to use it. Defaults are powerful.
To take a concrete example, adopting gofmt's choice to not have a line length limit would have been a nonstarter, because lots of code out there uses long expressions manually wrapped to be readable. A lot of the work in rustfmt has gone into playing nicely with community conventions like these.
To break lines, the formatter would have to refactor code, which is not desiderable.
The gofmt argument isn't the final word here. There's plenty of Go users who don't like gofmt's style, so they just don't use gofmt. It's easy to imagine other users who don't like gofmt's style, and don't like being pressured to use it, so they just don't use Go at all. How is that any better than just having a configurable tool with sane defaults? It's one thing for a tool to be opinionated; it's another thing entirely to be dictatorial and stubbornly inflexible.
Man, there's something cathartic in seeing your industry and self-identified group's ridiculousness aired for all the world to see.
Obviously the proliferation of coding formatting styles. It's not we didn't have "official styles" and formatting tools before for other languages.
The greatness of gofmt, and what people love it for, is how it killed all other options.
Programming causes me a lot of eye strain as it is, a configurable syntax formatter really does help.
I never see anyone discuss syntax the way you're describing. Not at work, not online. Actually the only place I see it is when discussing what the default is, so I think having a default is far more likely to cause those discussions as people will have more reason to complain.
To get the default formatting with rustfmt, you just run it. You can configure it via some file but I've never needed to. I don't even know what the options are.
https://www.techempower.com/benchmarks/#section=data-r15&hw=...
https://github.com/actix/actix-web
Rust is represented well!
Any suggestions of Opensource projects that use Actix?
here is irc bot (wip) https://github.com/DoumanAsh/roseline.rs
One reason why things are behind in some of the other scenarios is because our database driver stuff is synchronous at the moment, and that really hurts on these benchmarks. We'll get there!
[0]: https://benchmarksgame.alioth.debian.org/u64q/compare.php?la...
The syntax and ergonomics of rust futures ATM is insanely painful and slows down development 100x in some cases (not exaggerating) due to the current lack of async/await combined with hard typing requirements coupled with some very unreasonable design decisions (namely, each future generates as the result of a computation on a previous future has a different type, even if they resolve to the same types upon evaluation of the future - basically abusing the type system to store the futures chain. Combined with the very strongly typed nature of rust, even with experimental language features like “impl future<xxx>” the code becomes impossibly hard to reason about.
For example, the result of future.or returning a future bool is not the same type as the result of future.and similarly returning a future bool; and a two-level future evaluating to a future bool is not the same type as a one-level future also evaluating to a future bool.
async/await cannot come soon enough.
If syntax is all that matters, then sequential code is great, but there's more than that for many tasks.
(In any case, Go is adding layers of abstraction too: it is exposing a sequential interface over the OS's async APIs, whereas async/await is typically exposing them more directly.)
I think the main reasons people perfer one over the other are philosophical: basically, some people prefer managing the executors of concurrent code (goroutines/threads/whatever); others prefer managing the points of dispatch to executors.
You can do both in either paradigm, but those are what I see as the default modes of thinking. Neither is inherently better; it just depends on how you personally think about concurrency, and what concurrent tasks you need to model.
If you don't need the performance, you can get back to the dynamic-language world by boxing everything (.boxed()). The generics approach lets everything be compiled down to a single state machine, exactly like Iterator.
Wait, how is that safe? Aren't Rust strings UTF-8? Even if you search for a ASCII character, couldn't it conflict with the second byte of a different unicode codepoint?
TL;DR, it's not a naive straight `memchr`. `memchr` will generate false positives, then they use knowledge of UTF-8 to weed out the false positives.
The pathological case is worse, but the overwhelming majority of cases are better.
https://github.com/rust-lang/rust/blob/5cf55165fae5c8538db5c...
This does mean you have some somewhat pathological cases, but they're relatively rare because most strings come from only a couple unicode blocks, so all bytes other than the first will be from a really small set. A further optimization could be to fall back to the original find code if we realize we're hitting a pathological case.
(Also, FWIW, searching for an ASCII char can never cause this because of how UTF8's streaming property -- https://en.wikipedia.org/wiki/UTF-8#Description -- but given that we only search for the last byte, searching for a multibyte codepoint can lead to false positives with a shared last byte. We handle that.)
Or, searching for multibyte character ABB (like U+A041 YI SYLLABLE PA) and finding the first "B" instead of the second "B".
Sadly there's no memchr for consecutive sequences of characters. memchr2/memchr3 let you search for multiple needles in the haystack, not a bigger needle.
Or maybe memmem does something else clever for shorter needles. Dunno. Best to benchmark it. But it's not an obvious win a priori.
That would be pretty neat.
You can memchr for the last byte (either 0xxxxxxx for only byte or 10xxxxxx), then in the latter case go backwards to the MSB to see if the entire codepoint matches.
That said, development time in Python is much faster.
Honestly, it depends on what you're building.
Edit: The only big thing I can think of is the safety of compile-time type checking to ensure you won't end up with some kind of runtime error from mismatched types. Is there something I'm missing?
(I'd recommend using a language with garbage collection unless you really need to not though; OCaml is quite Rust-like but means you won't have to worry about the borrow checker)
Umm yeah, they've been a part of every ML-family language since the '70s, OCaml, Haskell and Rust included.
What I see from Rust is a lot of the really great things from functional languages (esp. strong typing) and beyond, but applying them to a language aiming as low as C. That's certainly interesting.
OTOH, Rust arguably has a better story for tooling (build system, dependency management, etc.), a more full-featured standard library, and better concurrency support. Depending on your priorities, some or all of these might be worth having to learn the borrow checker.
type Point(u32);
fn foo(p: Point) {...}
foo(0u32);
^^^^ expected Point, found u32It's this but designs in statically typed languages with more expressive type systems tend to push a lot of the logic into the type system so you can't use APIs incorrectly. This isn't exclusive to Rust but I do have a few examples:
The Glium OpenGL wrapper puts a lot of effort into moving errors to compile time. The overview[1] explains a bunch of them.
[1] https://github.com/glium/glium#why-should-i-use-glium-instea...
The Servo project uses the type system to tie rust code into the spidermonkey garbage collector so it can't be misused[2].
[2] https://research.mozilla.org/2014/08/26/javascript-servos-on...
More abstractly, one of the more unique features of Rust's type system (linear types) is the ability to be sure a reference is destroyed. This makes Rust particularly good at describing state machines that are compile-time checked. Using standard OOP terms, each state is a class and its methods are the valid transitions. You can't take an invalid transition because the method is missing. You can do this in any language, though it tends to be only done in statically typed languages and it's awkward in Python. What makes Rust unique is that calling the method will consume the instance so you can't accidentally make a transition twice. Trying to call the method again is a compile error. A concrete example of this is state_machine_future[3], which generates an asynchronous state machine using macros.
[3] https://github.com/fitzgen/state_machine_future#example
In a slightly different use of the type system, the Rocket framework has a concept called Request Guards that allow you to map from something in the Request to a parameter in the request handler function. The overview[4] has a simple example on the "Dynamic Params" tab that maps url pieces to a string and an int. This mapping, however, is extensible and you can map to anything. If your handler needs an AdminUser, you can have the request guard pull the user id off the request, connect to the db, retrieve the user, verify the user as an admin, and only enter the handler if all that is successful. This means you can move all the logic and error handling around this into a single place that can be reused just by putting an AdminUser parameter on a handler. I've seen this done with middleware in other frameworks but in Rocket it's on-demand per-handler. As a result, the handlers only have to implement the happy path, which keeps them more compact than I've seen in dynamic language frameworks.
[4] https://rocket.rs/overview/
So the general idea is to use the type system to help you use stuff right. As with anything, it's possible to overdo it and get crazy boilerplate heavy code where you have to convert/cast all over the place and unanticipated use cases can't be done but it tends to be helpful, particularly with autocomplete.
Unless you're talking about unsafe rust, that's wrong. And if you ARE talking about unsafe rust, well you can do the same in Python.
I do agree that python and rust are both "memory-safe" languages. I'm not sure about the other kind of safety rust provides though: thread-safety. That's really where Rust shines: you can write concurrent program and be statically guaranteed to have no data-races. I'm not sure how this transposes in python.
You could write parts of a network server or parts of an OS kernel in python. You could write nearly the entirety of it in rust.
I would say that you need not use rust if python works well for you, but rust is probably better than C for implementing libraries that might be called from python.
Just religiously use mypy. (Gradual typing!)
And profiling, and when something is reallly slow, bring out the Cython.
And when something is still not fast enough, well ...
Release the Rustacean!
+ Static typing (extra safety, robust refactoring, code completion etc.)
+ Much much faster and less memory use
+ Compiles to a relatively standalone binary (not as good as Go though)
+ No Python 2/3 nonsense to deal with
- Much more complicated. You have to deal with lifetimes and borrowing and so on. It's really very difficult and we still don't know how to write some types of programs nicely (e.g. GUIs)
- Slow compilation times
- Can get pretty verbose and full of type boilerplate
Honestly if I was coming from Python I think I would switch to Go first. It is still way faster than Python, has a very nice "batteries included" standard library, static typing, very fast compilation and makes nice static binaries. The downside compared to Python is that it isn't very expressive at all - you'll find yourself writing out loops where you might have used a one-line list comprehension or something in Python.
Whats the difference?
$ cat main.go
package main
import "fmt"
func main() {
fmt.Println("Hello, world!")
}
$ go build
$ ldd scratch
not a dynamic executable
$ cat main.go
package main
import (
"log"
"net/http"
)
func main() {
// Simple static webserver:
log.Fatal(http.ListenAndServe(":8080", http.FileServer(http.Dir("/usr/share/doc"))))
}
$ go build
$ ldd scratch
linux-vdso.so.1 (0x00007fff161f0000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f796b0e8000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007f796ad31000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f796b306000)
(To be clear, I am not criticizing Go here! There are good reasons why they link to libc by default when network stuff comes into the picture.)
It's a bit sad that this is still unsolved, probably due to the GNU people's hatred for closed-source distribution.
1. Refuse to do something properly because it will make it too easy... or something.
2. Wait until someone else gets fed up enough and makes a better version.
3. Fade into irrelevance.
See: GCC/Clang, glibc/musl, Bash/??? (someone please make something sane)
Instead you have the stable/nightly nonsense to deal with, like Clippy and Rocket only working on nightly for example.
Think about your domain problem, don't worry about CS and perf
Use the REPL to "touch data with your own hands"
Rustlang:
Fast, fast, fast
Everything bundled inside a single binary that you can just ship - no dependency hell for your users
Especially how Rust enums and structs make it easy to define new types to guide your programs are a highlight for me.
I don't think Rust is better than Python for every task. Python is a lot simpler if you can get something done with its built in types (dicts, sets and lists). Python's dynamic types are also a great benefit for some tasks, where Rust's dynamic dispatch support is very limiting.
Crazily, handling dependencies and building a project is way easier in pure-Rust than pure-Python since it's standardized.
In recent versions Python got some nice improvements in this area, with the new way of creating NamedTuples, Data Classes and the typing module. I wrote a stackoverflow answer recently that sums it up, if anyone is interested:
The main differences are found in tooling, library ecosystems, development speed and runtime overhead.
I didn't suggest Python is the optimal solution for low level coding, I just suggested it is an option.
> "You need "beefy" Cortex-M family to get similar performance that you can get with 8/16-uC with C."
In the case of MicroPython, people find it usable on platforms like the ESP8266, which is less powerful than a "beefy" Cortex-M. As before, I don't deny that there is a performance overhead compared to C, but it clearly has some traction in the embedded space.
Furthermore, most Python implementations are built using C, including the canonical one (CPython). It is possible to have performant Python implementations without using C, if that's what you're getting at.
Actually you seem to suggest that not even performance is of any hindrance to python. In which case I'm lost for words. You win.
I didn't think I'd have to spell things out so excessively, but... let's extend the description then... Any Turing complete language where you can write files to storage. To give an example of why the storage is relevant, let's look at Java. Java's sandboxed in the JVM right? However, if you think about it more broadly, as long as you can freely write files to disk you can write machine code to disk. In other words, as you can write a compiler in Java, you can break out of the sandbox.
As for Minecraft, I don't know enough about it, but if it's possible to write a compiler in Minecraft then that would have the same escape hatch too. It might not be a tool you choose to code a BIOS, but we're not looking at whether something is optimal, we're looking at whether something is possible.
> "I see you keep refering to Turing completeness in other replies"
> "Actually you seem to suggest that not even performance is of any hindrance to python. In which case I'm lost for words. You win."
Perhaps you overlooked the following quote as it didn't fit with what you decided you wanted to say...
"I didn't suggest Python is the optimal solution for low level coding, I just suggested it is an option."
That really isn't true in any practically meaningful sense. 'The main difference is everything is different' is not a very strong counter-argument.
That wasn't my counter argument, and I can't work out what you misinterpreted about what I said to get that impression.
My point was, unlike a Dremel and a plasma cutter, Rust and Python can be used for the same tasks. As they're both Turing-complete, anything you write in one can be written in another. The differences I suggested were to highlight the relative strengths, or in other words how much work you'd need to put in to get the desired result.
To be clear, if you hadn't tried to dismiss the GP who requested information about how Python and Rust compared to each other, I wouldn't have replied.
The moment you trot that out, you lose your 'but your analogy is terrible' privileges by default, however terrible my analogy is.
If you understand what it means, then you'd know that it means that all programming languages are comparable, from assembly to Haskell, in the sense they can all be used to do the same job. Therefore, requesting a comparison of the strengths and weaknesses of two programming languages is not a foolish request. The point of such a request is to find out where it makes sense to use a particular language. To give another example, let's say someone asks if it's a good idea to write a web server in assembly or in Go. It's certainly possible in either, but in order to explore what the best choice is then further discussion is required. Comparing a Dremel to a plasma cutter is an attempt to shut down this discussion, which doesn't help in furthering the knowledge of the participants.
I think this is where we strongly diverge and I resent, a bit, your implication that because I don't buy into this I somehow 'don't understand what it means'. I understand what it means. I just think it's plainly ridiculous.
You compared a Dremel to a plasma cutter as a way to explain the differences between Python and Rust, how is that any less ridiculous?
You're getting hung up on a minor detail. My main point was not about Turing completeness. My main point was that requesting a comparison of programming languages is a legitimate request. Turing completeness is just one angle by which to see this. As you seem to object to that suggestion, there are plenty of other ways to explain it.
For example, one way to compare languages is to look at the key libraries and frameworks that have been built up around them. So for example, Rocket vs Django, Diesel vs SQLAlchemy, etc... If we're comparing languages, we should compare what the languages makes it easy for us to do, and libraries are a big part of that.
Another way to look at this suggestion is that "writing performant code" is something that's easier in some languages than others, and the libraries built using those languages are likely to reflect that. However, performance is just one metric by which to compare languages/libraries/frameworks, which is another reason why these comparisons can help in building an understanding in when a language is likely to be the best one for the job.
Lastly, to make this as clear as possible, I'm not advocating for Python or for Rust, I am only advocating for language comparison as a helpful approach when building familiarity with programming language strengths and weaknesses. Both Python and Rust have niches they excel in, but there's also a large amount of overlap. As an example, game frameworks exist for both Python and Rust, and discussion can help others find what's best for them.
This especially shines through if you have to use code someone else wrote.
I can't. But I can try to sell you Nim [0] as a compiled/faster addition to your Python, from my own experience of using it in last few months and coming from Python.
It uses significant whitespace and the syntax will surely look familiar to any Pythonista, and the entry barrier is much lower (i.e. learning curve is much shallower) than Rust.
Speed improvements I experienced are in the range of 10-100x, while the code doesn't look that much different than Python. I have solved Advent of Code in both Nim and Python in parallel [1] so you can compare the solutions/syntax yourself.
After coding in Rust for several weeks I went back to C++ for my day-to-day work since I'm still more productive with it and the code I produce has no safety/security implications. The knowledge gained in those few weeks of Rust readily translated into C++ skill improvements, even though I already considered myself a solid C++ programmer before. Being forced to think about ownership, borrowing, move semantics, etc. constantly gets you into a mindset that is very helpful also outside of Rust.
https://blog.sentry.io/2016/10/19/fixing-python-performance-...
https://github.com/getsentry/milksnake/blob/master/README.md
I've taken a few apps from Python to C#/F# and seen speed increases around 50x. With Rust I could increase the speed from C#/F# by around a factor of 10x for string heavy applications processing large files. So the speed difference might be 500x between a Python and Rust application (depends HEAVILY on the problem you're solving though, a lot of the problems that can be vectorized easily work pretty fast in Python).
I'd say I'm faster at writing F# than at Python, because the type system helps me build more easily maintainable code, and the functional style is better for the way I think (I grew up with structural, learned OO in uni and thought most of it is bananas and more obfuscation than helping, and I'm happy the world is now slowly getting to something sensible again). It takes me a bit longer to write Rust programs though.
Cargo is the best build system of the 3 languages though, you can easily add crates (imports) and the build system handles everything, even unit testing. I gotta say on the project setup front Rust with Cargo is much better than any other language I know.
And I think once we get good IDEs with robust code completion and error detection, I can become quite fast at Rust as well.
Error detection, at least in VSCode is only displayed after compiling, that might be the plugin though.
Your analogy to Makefiles is right in a big-picture sense. In the small, it's different, but you've got the big idea correct.
# In the crystal-lang/crystal repo
$ find . -name '*.cr' -print0 | wc -l --files0-from=- | tail -n 1
252745 total
$ time bin/crystal tool format
Using compiled compiler at `.build/crystal'
bin/crystal tool format 0.62s user 0.04s system 106% cpu 0.625 total
Performance makes little practical difference as long as formatting a single file is fast enough to be on-save, but it does highlight the very interesting way that the crystal formatter is implemented. I'm not sure how rustfmt is implemented but crystal's formatter parses the file into the AST, and then does a single visitor pass of the file, in order, with a lexer in tow. It then basically reconstructs the entire file from scratch using the data both from the AST and the lexer (the AST visitor pass and lexer position have to be kept in sync). And surprisingly enough, this doesn't even make the formatter "too strict" in the way that it wipes out all existing style information as one would expect. It's a really cool - if a little messy - tool and one of I think my favorite parts of crystal (it doesn't have any config options either).
The bug where it _refuses to run_ if lines are > 100 chars is annoying
https://github.com/rust-lang-nursery/rustfmt/blob/master/Con...