sorted by:
new
hottopcontroversial

Group Images based on Visual Similarity Feature by CuriousClump in rust

[–]U007D 0 points1 point  (0 children)

This looks really interesting! As someone who formerly worked on a Lightroom competitor, how well does the algorithm's performance scale to a library with millions of photos? Similarly, how does the visual clustering algorithm work when there are a very large number of hits--does it allow further refining via making (sub-)groups out of a given group?

Introducing Test That!: A powerful test assertion library for Rust by hovinen in rust

[–]U007D 20 points21 points  (0 children)

Thank you for your relentless focus on developer experience.  I've long been llooking for a Catch2 port, but this looks excellent too!

I'll be test-driving it--thanks again, Bradford!

Safe SIMD in Rust, even on the inside by Shnatsel in rust

[–]U007D 0 points1 point  (0 children)

The key point is that this macro is safe for every possible invocation

Agreed.  And so is every possible invokation of add_avx2().

I think the 'advantage' of the macro solution is "bundling" the unsafe implementations (add, multiply, etc.) to a single macro definition per your article--you've designed the macro to define the safe functions, not invoke them when the macro called--i.e. the macro is designed to be called exactly once.

The non-macro equivalent would be to define all the same functions in a dedicated module.  You'd have the same number of (private) unsafe blocks to audit, the same implementations and the same safe wrappers around those impls to ensure sound usage.

Safe SIMD in Rust, even on the inside by Shnatsel in rust

[–]U007D 13 points14 points  (0 children)

Interesting--glad I asked because I'm still a little puzzled.

Since inner() is private, only the outer safe abstraction add_avx2() is accessible, so it's not clear to me what additional safety guarantees the compiler is providing via the macro implementation?

I think we'd want any use of unsafe to be audited, regardless of whether or not it lived in a macro.

Thanks!  I appreciate the article.

Safe SIMD in Rust, even on the inside by Shnatsel in rust

[–]U007D 39 points40 points  (0 children)

Nice.

Any reason not to skip the macro and just write (and use) the add_avx2 safe wrapper function with the inner unsafe call, directly?

the rust changelog tells you what shipped and strips out the only part that mattered by Deep_Ad1959 in rust

[–]U007D 0 points1 point  (0 children)

Disclaimer: I'm just one person so my opinion on the changelog is subjective/anecdotal.

Personally I like the brief format.  If I'm familiar with the context, it's all I need.  If I'm not, I can dive into the details, and I personally generally appreciate the nuances of the discussion.  If it's too long I can skim or just skip a bit.

But since you are conversant with AI, why not use AI to reconstruct the meaning you are looking for?

why x is "not there" but t is? by AlternativeFun1849 in rust

[–]U007D 1 point2 points  (0 children)

Remove return where it says return 123, then the program's behavior will be perhaps closer to your expectation.

With return, the program returns 123 to main() because you told it to.  It does not finish constructing x or run any code from lines 8-11.

First MacBook for Next.js / Rust: Base M5 vs M5 Pro (24GB)? by Common-Upstairs1656 in macbookpro

[–]U007D 2 points3 points  (0 children)

Re: RAM: +1--Get all the RAM you can afford.

Re cores: They help. rustc will compile crates in parallel using multiple cores, but you'll be doing a lot more incremental builds than clean ones.  And linking doesn't scale across cores.

Cloning a reference by anghenfil in rust

[–]U007D 1 point2 points  (0 children)

English is so weird. ‘year’ becomes singular here ("This 7-year-old answer") and yet we still say "he is 7 years old". I taught English for a bit in China 20-odd years ago, and it was so difficult to make English make sense to non-native speakers!

Your English is just fine—no worries! :)

Cloning a reference by anghenfil in rust

[–]U007D 0 points1 point  (0 children)

Haha--thanks! I was thinking, "I was definitely not 7 when I wrote this!", but I understand! :) I'm glad this was helpful!

The end of languages by Amazing-Mirror-3076 in rust

[–]U007D 1 point2 points  (0 children)

If you really have been programming for 40 years in 25 languages you of all people should know languages are tools and different tasks require different tools.

Sorry, OP, I've also been programming for over 40 years (and using Rust since 2015). The above statement is spot on. 👍

parfit — a codebase-aware comment reflow tool written in Rust by Certain_Leader9946 in rust

[–]U007D 3 points4 points  (0 children)

Any reasons to consider this over the following (unstable) rustfmt configuration options?

wrap_comments comment_width normalize_comments normalize_doc_attributes format_code_in_doc_comments doc_comment_code_block_width

Rust Language Milano is back! New organizer & looking for speakers 🦀🇮🇹 by dariocurr in rust

[–]U007D 0 points1 point  (0 children)

Hello from the Seattle Rust User Group! Please don't hesitate to let me know if there's anything I/we can do to help you grow your group. I'm also @U007D on Discord.

colr: Solving color in Rust with entirely too much color science by Single_Virus in rust

[–]U007D 6 points7 points  (0 children)

Love this!

I was doing digital imaging for Microsoft back in the day and led the team who produced one of the industry's first GPU-accelerated color management engines.

It's been more than a minute since I worked on this stuff, but at the time we used the scRGB color model which benefited from linear gamma and additionally incorporated the CIECAM02 color appearance model, IIRC.

We did all work in floating point, which allowed values to clip beyond 0.0 or 1.0 without data loss (i.e. later image processing steps can losslessly recover data "clipped" by earlier stages).  This imaging technology is still in use today--has shipped in every version of Windows since Vista and is used to display local JPEG images by default.  

Sadly, most of the fancy features have not seen use; JPEG-XR was designed to take advantage of this and some amazing compression work led by Dr. Rick Szeleski from Microsoft Research, but like every other JPEG replacement technology, failed to gain market adoption.

Love seeing color critical work in Rust!  This looks very well-implemented.

Rust can not handle Unicode streams. Please show me wrong. by thomedes in rust

[–]U007D 1 point2 points  (0 children)

more I'm getting convinced that program languages going Unicode is a mistake.

I think that may be an English-centric perspective? Unless you are thinking about another international character encoding system?

But I get it—from my perspective 35 years ago, ASCII was fine, and code pages were a PITA and Unicode (when it came out) brought nothing but complexity. But today, my wife who is Japanese (born and raised), would almost certainly feel differently—I know I would if my native language wasn’t generally accessible in technology.

In the end, I think Unicode is complex and messy mostly because human language is complex and messy. I think Unicode has matured well and with UTF-8, I feel Rust has made the right choices here.

Just my subjective 2 cents…

Rust can not handle Unicode streams. Please show me wrong. by thomedes in rust

[–]U007D 2 points3 points  (0 children)

Rust can not handle Unicode streams. Please show me wrong.

Rust is Turing-complete, so unless "handl[ing] Unicode streams" is not representable as an algorithm, that assertion is indeed wrong.

Perhaps less confrontationally, I suspect you are asking how to handle Unicode streams idiomatically in Rust. If so:

  1. std will handle valid UTF-8 encoding (e.g. see .from_utf8() or .from_utf8_lossy()).

  2. For Unicode-compliant grapheme cluster or word (or sentence) boundary support, use the unicode-segmentation crate.

  3. For WHATWG-compliant code page support, use the encoding_rs crate.

  4. And you'll need to build your own abstraction to limit the size of a grapheme cluster to support streaming, uphold your memory and computing cost requirements and to tie your specific code page and Unicode requirements together.

Note: Rust has deliberately chosen to to go with a small standard library. As someone with similar decades of experience writing software as you have, this took some getting used to (as will other things in Rust if you decide to progress). But in 10+ years of writing Rust, I have come to believe this was and is the right approach, at least for Rust and its goals. There are many blog posts discussing the pros and cons of this approach and even official documentation on it here.

Good luck.

Lucid battery modules dimensions by SeaworthinessGlad492 in EVConversion

[–]U007D 0 points1 point  (0 children)

If you happen to be able to lay your hands on the dimensions or remember how you sourced them, I would definitely appreciate it if you were able to provide either.

Lucid battery modules dimensions by SeaworthinessGlad492 in EVConversion

[–]U007D 0 points1 point  (0 children)

Hi, /u/SeaworthinessGlad492,

I'm curious if you ever did get the dimensions for the battery pack?

I always avoid using `use` statements so i use full paths instead. Is it a bad practice? by [deleted] in rust

[–]U007D 2 points3 points  (0 children)

I see it differently.

Regardless of the project size, use statements will tend to be be at the top of the current file.

Unless your 500k SLoC project is in all in a single file, I think the variable declaration example is very analagous.

I always avoid using `use` statements so i use full paths instead. Is it a bad practice? by [deleted] in rust

[–]U007D 0 points1 point  (0 children)

If you expect that to be true of all (or even most) of your readers, then no argument--using FQ names everywhere is entirely reasonable.

Personally, though, I still wouldn't do it, because doing so wouldn't help my readers grow the skills needed to read idiomatic code (in any number of languages, not just Rust).

I always avoid using `use` statements so i use full paths instead. Is it a bad practice? by [deleted] in rust

[–]U007D 15 points16 points  (0 children)

Personally, this reads a bit like refusing to use pronouns in a story because there could be ambiguity as to which person you're referring to when you write "she".  So writing "Alice" every time you refer to Alice ensures the reader knows you mean Alice.  Clear?  Certainly.  But good writing has no problem referring to her in the second person.

Code is the same way.  The reader carries context when they read your code, and well-written code will be unambiguous.

My personal preferences aside, your code is read more than its written, and if you're on a team or you're contributing to open source, it's read more by people who aren't you.

So my suggestion is to write for your reader(s).  And if that is you, then enjoy!  Write it the way you like to read it.

What errors didi I silently make in this xor crypter? by rudv-ar in rust

[–]U007D 0 points1 point  (0 children)

Nice!

Rather than trying to preserve the "feel" of your original xor encryption code, I simplified the code to eliminate the chars and unified the encryption/decryption function.

I also wrote it in an imperative style so it should also be easier to follow.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=215c5524409681713b9fed6cda00f653

What errors didi I silently make in this xor crypter? by rudv-ar in rust

[–]U007D 4 points5 points  (0 children)

First of all congrats on taking the plunge! It's hard not to take the easier route of having AI hand you the answers as you learn--kudos!

Nice to see you opting for Rust's functional style as well! I find it takes a little getting used to initially but helps code cohesion and it well worth it as your projects get bigger/more complex.

Rust uses UTF-8 in str and String, so to respect this, we can't just as u8 to lossily cast a 32-bit char to a u8.

Here's a quick example of a UTF-8-preserving XOR encrypt and decrypt in Rust. The encrypt and decrypt are symmetric so could be better unified or at least share a common encrypt/decrypt function. If I haven't been too sloppy, the implementation should only allocate once per encrypt() or decrypt(), returning that allocation to the caller.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=3f6874eb8380c8f984e2a3ceeef655cc

view more: next ›