I do think they should have taken an approach similar to prettier and gofmt. very minimal settings and opinionated so all js/go codebases are effectively the same formatting

A lot of what Linus complained about is 100% valid though

Not necessarily. The program can be configured and they did not create a default configuration for all, to enforce a specific style. Linus can complain about the default settings, but that does not make sense if we look at all other tooling used in Linux. Are they using every application with default settings and then complain about it?

No, there are settings adapted for the Kernel and their workflow. And they did not do that with rustfmt. While the critique about the issue itself is valid, its not valid to complain about it about the program. He should have complained about those responsible for the default configuration in Linux.

https://doc.rust-lang.org/style-guide/index.html#small-items

We leave it to individual tools to decide on exactly what small means. In particular, tools are free to use different definitions in different circumstances.

What does this mean?

What does Linus when he says rustfmtcheck? cargo fmt check? A util I can't find with a simple search? Maybe they have makefile targets or sth for it?

The concerns raised by Linus make sense to me, but should be simple to solve. The small items description already mentions variance, and the need for tools to decide. So shouldn't it be a simple configuration change?

TBH for personal projects it's almost perfect already. It produces consistent readable code. But yeah it's often not very "mergeable", which is much more important for massive projects with thousands of active committers.

I'm really looking forward to Redox becoming a viable alternative for desktop.

Just wanted to get back to tell that I tried graph1 to mess around with non-linear projection, it seemed like an interesting crate but it felt like it's a bit too low level for doing a GUI with it.

I am in total agreement EXCEPT where I differ is that I believe no autogenerated docs should be committed to the repo without being proofread and improved. I see it like scaffolding.

IMHO generated docs (and yes, LLM spitting out stuff is generated docs) should not be committed to the repo. Something like this should happen on the cargo doc/docs.rs side (with opt-in from the user, of course). This has a couple major benefits, the main one being that the docs can improve as the LLM improves.

😂😂😭

Who's "Agent Spaghetti,' and what do they want?

no one has noticed

nice. this is a detail that i needed to know that would otherwise be a dealbreaker.

i am intrigued by the promises of better histories, since i’ve been reviewing and contributing to a bunch of repos at work.

a lot easier to use

see this is the issue. i don’t find git hard to use. and i’m not going to be one of those assholes that’s like “i never thought it was hard”; i’ve just genuinely been at this for over a decade now. and i run nushell so i’m not opposed to new niche things as long as it improves my workflow.

i’ll have to check it out again.

In the initial implementation, export groups have been added as an independent attribute. One attribute creates groups, and the other marks fields for exporting. So yes, this is not being auto-inferred right now, but it could probably be added.

jj is built on top of Git. If you use "colocated" repositories (which is now the default), your Git workflows will still work. In fact, all my Nvim setup with Git plugins didn't need any change. When your run jj commands, they will operate on the Git repo, and if you run Git commands, they will be imported by jj as needed. I've been using almost exclusively jj at work and in open-source contributions, and so far no one has noticed (why should they).

As to why you should use it, let's say that it encourages you to have a better development workflow, a cleaner Git history, and an easier time working on top of code that is being reviewed, by lowering the barrier. Rebase is easier to use, absorb and squash are a godsend for keeping a clean history, and a lot of design decisions that, when you think about it, just makes sense from a usability perspective.

I encourage you trying it out, I certainly don't regret it, it does feel a lot easier to use than bare Git.

Cool. Anyway FUCK Cloudflare

Hrm, the pre-commit issue is still open.

Like the others in that thread, I'm not married to pre-commit or the check happening before the commit as opposed to the push, I just want to have some easy-to-setup, standardized way of preventing myself from pushing stuff that will be rejected by CI.

i really want to get into jj cuz i like the pitch, but the real struggle isn’t new syntax or learning curve but the fact that my workflows at home and especially at work are built around git and GitOps. i tried briefly to integrate it into my dotfiles, but migrating such a large repository got a little hairy.

is there a doc about why a seasoned pro (at least don’t tell my manager otherwise) would switch to jj? are people using this in production effectively? is there a world where i can integrate jj into existing git based workflows that interact seemlessly with other contributors using plain ole git?

godot-rust v0.4

40% complete! /s

Looking at the example code of Export Groups, I don't understand why a #[export] is needed, if there is already a #[export_group(...)] or #[export_subgroup(...)] . Its surely possible in Rust to automatically invoke #[export] if one of the group-macros are invoked, right?

@turbohz oh hell yea. Godot is pretty cool. Honestly, I think it's the first of the more notable engines to actually have Rust integration. Unreal would be way better if you could use Rust. I tried the C# stuff for a while and I just disliked the language a lot (used it professionally for years too)

Im saving this comment for sure

Maybe one of these links helps:

• A collection of notable Rust blog posts
• Rust Design Patterns
• Introduction to Design Patterns in Rust

I’ve forgot slint. Same as QT

Currently I use WxWidgets and Cocoa for macOS.

The best would probably be pure native UI with static/dynamic library in Rust for logic. Sounds hard, but it’s the best option in my opinion.

My 2 cents is below. Your decision depends on your tasks, preferences and targets.

• GPU framework maybe fast, but accessibility at 0
• HTML backend is nice, but I can’t choice other than native, which limits me quite hard for target user base. And I don’t like JS if not strictly required (it’s a personal preference).
• GTK on macOS and windows is quite hard to install and I don’t like visuals
• QT is in grey zone if static (non-GPL project), and I haven’t found good way to bundle it if dynamic
• ImGUI is nice but I don’t know if they support HiDPI monitors and accessibility is not the highest
• fltk is nice, but 1) many things you’ll have to write by you own, rewriting sometimes from FLTK2 C++ code… and community could be more chill and friendly
• Windows Metro UI… probably no crates
• Win32 API GUI works perfect
• Swift… probably yes, but it’s very OS-dependent
• Cocoa — very nice for macOS.
• current stop is WxWidgets: small, embedded, look… ok for now.
• there’s some framework for iOS and Android, looks fine for me, but not my target ATM.

Hi. Please take a look at Graph1. It may potentially be what you're looking for: https://graph1.codument.com/

It is designed for (simple) animated graphics projects. A considerable improvement in displaying pixel fonts is planned to be rolled out in 2-3 weeks.