Seriously more effort and investment should be put into code scanners if we want a bright future to modern software development

I mean, if you want your prints to be asynchronous you’re looking for trouble to begin with.

The previous statement is a joke.

Damn, expected something like this to happen or, well, be detected after the big NPM attacks.

Both faster_log and async_println were purely malicious packages (not taken over and turned malicious).

I know faster_log is typosquatting / luring fast_log users but I’m not sure about about async_println (which was a clone of the malicious faster_log).

async_std::print is a thing so I guess trying to lure users who search crates before docs :shrug:

Thanks :)

async_println is a part of fast_log?

Both were impersonating fast_log.

What are the proper crates that the malicious ones were pretending to be? (I'm new to Rust)

As long as people are using Rust, it will necessarily attract this kind of action. This won't be the last attack we will see.

I think the team has handled it quite well.

Not again...

When I want to draw raw polygons, I use wgpu. When I want a GUI I used iced. And when I want both, I use wgpu+imgui.

Learning wgpu is quite steep, and it has tons of boilerplate. So unless you're certain that you will use it a lot. I would just use iced.

When I say wgpu I mean wgpu+winit. Though winit is quite simple and light. So the main part is wgpu.

I did fill out the survey. Turns out I don't have a usecase for any of this, and therefore I'm in the "don't care" realm really, since I'm also not really appreciative of corresponding features in other languages I know. I'd generally be critical of the cost vs. gain balance here though...

As an avid Helix user, thank you for linking this! I had no idea this was available, nor that I wanted it in the first place, but now I do.

The title seems a bit confusing. Do you want a game library, or a GUI library?

Assuming you're doing game dev, bevy is probably the furthest along, though there are a few alternatives. You can enable only the features and plugins you need to lower the memory footprint, though it's not clear to me how low of memory you're looking for.

As far as I know, everything uses winit. If you need the feature enabled, you can add it as a dependency directly (in Cargo.toml) and enable the feature.

If you're having a hard time, maybe consider a completed game engine. Have you looked at Godot? Does it need to be in Rust?

Personally I would start with plain SDL2 and then add GTK. Both of them are language-agnostic, so you are learning something that you can use in other projects too. And are widely used, so while the Rust binds might add some spiciness to the mix, it should be easier to search for clues

I tried to build simple UI with floem, slint, and iced.

1. slint seems to allow to do the most, it's GNU GPL, and it allows you to move boilerplate to separate *.slint files much like Qt, imo.
2. floem seemed the most flexible to me, but it requires attaching signals everywhere manually.
3. iced seemed the easiest to use, but not exactly too flexible. I think some looks of the already simple UI I wanted to create were not possible there.

You can check out my repo to see if it helps to answer your question. And yeah, I know the features shouldn't be mutually exclusive 🌚

Slint is a cross platform one.

Iced and egui are also an option.

GUI is just a mess. I think bevy is to-go though, it could be tuned a lot to turn down memory demand. Otherwise, use system level stuff, like web-based ui or Qt wrap.

At least that's what I ended up thinking after struggling with same question.

Not my area of expertise, but egui may suit your use-case better than the usual candidates.

The IRC client, Halloy uses iced.rs and that is a very beautiful client. Also, the upcoming Cosmic Desktop major version uses Iced as well. So that maybe a good indicator where efforts are heading.

By default, the message on the top-right refers to the location of the cursor in Helix. Though, I don't see a selected line or the cursor itself, so, I'm a bit confused, too.

From the bottom right, we know there is one selection and it's on 25:48, but lack of visual indication tripped me, too.

fwiw if you do a cargo build you should be able to see the error messages in the correct context. If I replicate line 25 in a little test project and run cargo build I get

error: expected one of `.`, `;`, `?`, `else`, or an operator, found `{`
 --> src/main.rs:4:43
  |
4 |     let guess: u32 = guess.trim().parse() {
  |                                           ^ expected one of `.`, `;`, `?`, `else`, or an operator

error: could not compile `unacceptable-rs` (bin "unacceptable-rs") due to 1 previous error

If I try this with a blank helix config I don't get any of the text output from rust-analyzer at all, just the three dots indicating there's a problem there, so it's unlikely it's a bad design choice on helix's part.

Inline diagnostics was implemented earlier this year, and is still not enabled by default (likely to prevent breaking existing configs). The changelog is from January of this year:

https://helix-editor.com/news/release-25-01-highlights/

You can set it up here, and is straightforward:

https://docs.helix-editor.com/editor.html#editorinline-diagnostics-section

Thank you're a lifesaver, IDK about the error message on the top didn't configure much except nord-night theme must be a bad design choice on helix's part

You are missing a match keyword in line 26