After cargo add I have to sometimes run the "restart rust-analyzer" command from the vscode command pallette (exact wording may be off, I'm on my phone as of writing this comment). Much faster than cargo build.
Consider using sccache to speed up rebuilds. It helps a lot, though uses a bit of disk space. But disk space is cheap nowadays (as long as you aren't stuck with a laptop with soldered SSD, in which case you know what not to buy next time).
Looks cool. Absolutely not my area of knowledge let alone expertise. But I thought digital colour stuff was all about ICC profiles (that basically describe how wrong a device handles colour and how to correct for it).
I don't see any mention of ICC profiles in the docs though? Or is this the lower building block which you would use to work with data from ICC profiles? Basically I think I'm asking: who would use this crate and for what? Image viewers/editors?
I don't feel like rust compile times are that bad, but I'm coming from C++ where the compile times are similar or even worse. (With gcc at work a full debug build takes 40 minutes, with clang it is down to about 17.)
Rust isn't an interpreted or byte code compiled language, and as such it is hard to compete with that. But that is comparing apples and oranges really. Better to compare with other languages that compile to machine code. C and C++ comes to mind, though there are of course others that I have less experience with (Fortran, Ada, Haskell, Go, Zig, ...). Rust is on par with or faster than C++ but much slower than C for sure. Both rust and C++ have way more features than C, so this is to be expected. And of course it also depends on what you do in your code (template heavy C++ is much slower to compile than C-like C++, similarly in Rust it depends on what you use).
That said: should we still strive to optimise the build times? Yes, of course. But please put the situation into the proper perspective and don't compare to Python (there was a quote by a python developer in the article).
It all depends on what part you want to work with. But some understanding of the close to hardware aspects of rust wouldn't hurt, comes in handy for debugging and optimising.
But I say that as somone who has a background (and job) in hard realtime c++ (writing control software for industrial vehicles). We recently did our first Rust project as a test at work though! I hope there will be more. But the question then becomes how to teach 200+ devs (over time, gradually presumably). For now it is just like 3 of us who know rust and are pushing for this and a few more that are interested.
I would indeed consider Go a bigger language, because I do indeed think in terms of the size of the runtime.
But your way of defining it also makes sense. Though in those terms I have no idea if Go is smaller or not (as I don't know Go).
But Rust is still a small language by this definition, compared to for example C++ (which my day job still involves to a large extent). It is also much smaller than Python (much smaller standard library to learn). Definitely smaller than Haskell. Smaller than C I would argue (since there are leas footguns to keep in mind), though C has a smaller standard library to learn.
What other languages do I know... Erlang, hm again the standard library is pretty big, so rust is smaller or similar size I would argue. Shell script? Well arguably all the Unix commands are the standard library, so that would make shell script pretty big.
So yeah, rust is still a pretty small language compared to all other languages I know. Unsafe rust probably isn't, but I have yet to need to write any (except one line to work around AsRawFd vs AsFd mismatch between two libraries).
can have a nontrivial (or “thick”) runtime and doesn’t need to limit itself to “zero-cost” abstractions.
Wouldn't that be a bigger rust rather than a smaller one?
Not an area I'm particularly interested in, given that I do embedded and hard realtime development. Rust is the best language for that now, I just which allocations were fallible as well. And storage/allocator API was stabilised.
I really don't see what niche it is trying to fill that isn't already occupied.
Rust is as successful as it is because it found a previously unoccupied niche: safe systems programming without garbage collector and with high level abstractions that (mostly) optimise away.
I don't think "better C" is a big enough niche to be of interest to enough people for it to gain a critical mass. I certainly have very little interest in it myself.
Seems to be a wrapper around implementing the "index into data store"-pattern (not sure if there is a better name), but without support for removal from said data store.
From a quick glance I don't really see what this gives you that wouldn't also be quite easy with a manual implementation. And then you avoid the proc macro compile time overhead as well.
Oh, this seems to be specific to the SQL framework you use after looking into it. I thought it was a general rust question about function parameters, sorry. Unfortunately I'm not familiar with that sql framework (or any other, I'm an embedded developer, not a web dev).
Hope you find someone who knows diesel, and sorry again I couldn't help you.
Unfortunately your code here in this post is unreadable with the buggy html escaping in it. Consider posting to the official rust playground and creating a shared link. And/or report a bug to lemmy about the broken quoting.
The code is hard to read since html escaping appears broken on Lemmy. Better file a bug about that and repaste the code to the rust playground with a link?
Be sure to treat state and configuration separately. It doesn't matter on Windows as far as I know (they go in the same location), but on Linux those are supposed to go in different places.
Many programs get this wrong, and it is quite annoying as I track my config files in git. I don't want a diff just because the list of recently opened files changed! Or even worse: the program stores the last window size and position in the config file... (looking at you KDE!)
Here are some libraries I found to help with this in a cross platform way:
https://lib.rs/crates/dirs
https://lib.rs/crates/directories
I haven't tried either, haven't written such a program yet.
As for how to store data, there are indeed many options, depending on your needs:
Plain text based formats (toml, yaml, JSON, ini, ...) can be good for configs and basic state. As a bonus it let's the user easily manage the file in version control if they are so inclined.
Databases (SQLite mostly)
Custom formats (binary files in a directory structure is often used for browser caches for example) .
Without knowing more it is hard to give specific advise.
·1 year ago
Two tips that work for me: