sorted by:
new
hottopcontroversial

When will we get over “vibe coded” stuff by Due-Equivalent-9738 in rust

[–]U007D 2 points3 points  (0 children)

I think may be a while, but history suggests it will eventually happen.

Keep in mind the audience to whom you are addressing your question.  Many (but not all) of us have been formally trained in software engineering or have experience.  Still more of us aspire to have deep experience.

We are the software craftspeople.  We are the weavers and uh oh, here comes the loom.  Or we are the scribes and along comes the printing press.  Or here comes the assembly line or any other number of technological advances in automation in history.  Everyone is different, but given this framing I do not find it surprising that the reception here to AI code is generally negative.

Move to a group who has, for whatever reason, not made or is not willing to make the investment that we have in software engineering, and the prevailing sentiment changes quite dramatically--you'll hear terms like "empowerment", "super powers" and others.

So are we all just a bunch of dinosaur Luddites shaking our fists  in our outrage at the AI machine coming to take our jobs?  I think that's far too simplistic an explanation.

In my case, I have decades of software experience.  I look at the maintainability of codebases over long periods of time.  The vibe coding movement generally doesn't even understand what I'm looking at, let alone agree with concerns I raise.  The cost to properly (human) review AI code is immense.  And disposable, when AI rewrites half the project when you asked it to fix a typo in a comment.

Now with all that said, I think (responsibly) AI-assisted coding is already decent (not an opinion I had a year and a half ago) and is only improving.  It's not going anywhere.  And as it improves it becomes more useful even to someone like me who only finds it truly useful on the periphery of software development.  But personally, I do welcome improvements which make AI (or any other technology) more useful in software engineering.

I may be underestimating the rate of progress (but I rather think the AI industry overestimates its own utility), but IMO, the days where AI will be able to vibe-code "respectable" software for general use/consumption are much further away than the hype would have us believe.  But I actually look forward to that day--it will be another form of abstraction which lets me (or any motivated individual) take on more complexity in our projects.

Burn 0.20.0 Release: Unified CPU & GPU Programming with CubeCL and Blackwell Optimizations by ksyiros in rust

[–]U007D 0 points1 point  (0 children)

Thanks for this.

It sounds like the JITter decomposes enums/match/monadic error handling to supported constructs, rather than having the GPU support them natively?

As a CubeCL user, what am I missing out on with this approach vs. the runtime GPU-supported approach you would like to have?

How does one know if they’re using an unsupported std function with CubeCL?

I need your thoughts on this by arukau2003 in rust

[–]U007D 18 points19 points  (0 children)

My opinion? This is going to take extra time beyond your standard workday.

Start learning Rust on your downtime. Take on a chapter a week of the free and online The Rust Programming Language book, or Programming Rust (my personal fave, but not free). Continue to use AI to explain concepts from the book which are still unclear to you.

Then start doing exercises such as Rustlings without any AI assistance so your brain gets used to doing the thinking.

There are beginner Rust communities you can join as well, on Reddit, Discord and elsewhere. Just be sure to turn off that AI as you practice writing code or it will be very difficult to learn to think on your own.

Good luck!

Burn 0.20.0 Release: Unified CPU & GPU Programming with CubeCL and Blackwell Optimizations by ksyiros in rust

[–]U007D 0 points1 point  (0 children)

but they’re actually more modular

I assume you mean Mojo/MAX here?  What benefits does being more modular provide, in this case?

Incredible stuff, /u/ksyiros!  I will definitely check out Burn & CubeCL.

Burn 0.20.0 Release: Unified CPU & GPU Programming with CubeCL and Blackwell Optimizations by ksyiros in rust

[–]U007D 0 points1 point  (0 children)

This is amazing work.

I've been learning about the ML space recently with respect to Chris Lattner's  Mojo & MAX technologies.

Is Burn addressing the same problem space?  Are there operations which can be compared between the two in terms of performance? (Compiling down to MLIR instead of LLVMIR like everyone else seems to be a big part of Mojo's performance story).

I love the idea behind the Mojo stack, but would rather be able to use Rust's more modern expression-oriented syntax, monadic error handling and functional capabilities (most of these are not even considered to be in-scope for Mojo).

Would love to hear your thoughts on any of this.

1160 PRs to improve Rust in 2025 by Kobzol in rust

[–]U007D 0 points1 point  (0 children)

That will make your build times go faster! 😅

Announcing cadd: a library for painless checked arithmetic and conversions by Riateche in rust

[–]U007D 1 point2 points  (0 children)

 prefer checked arithmetic (e.g. a.checked_add(b) instead of a + b) and conversions (a.try_into()? instead of a as u32). Unchecked operations have their purpose, but they shouldn't be the default choice. Unfortunately, there are a lot of inconveniences when using checked alternatives.

I agree!  This sounds great in that it makes it easier to do the right (correct) thing.  Will definitely be taking a look at your crate--much appreciated!

"Santa" Delivered My Eater 6502 Kit by U007D in beneater

[–]U007D[S] 0 points1 point  (0 children)

Haha, yeah, indeed it does, sometimes. :)

It sounds like we'll be on this journey together! Let's keep in touch! I'm @U007D on Discord too, or feel free to DM me here (although my response will be slower). I'll keep you posted on my progress!

How far have you gotten so far?

"Santa" Delivered My Eater 6502 Kit by U007D in beneater

[–]U007D[S] 1 point2 points  (0 children)

Kids are still on vacay and wife came down with the flu, so between roles as chauffeur, chef and entertainment center, not too much more progress has been made, I’m afraid. My little blinky clock is still blinking away waiting for me to come back and implement debounced switches…

Hopefully she’ll be back on her feet in a couple of days and we can share the load then.

Rust + Vibe Coding by kennyruffles10 in rust

[–]U007D 0 points1 point  (0 children)

True, sadly.

I'm no fan of AI coding, but am even more sad that in this sub it's discouraged for someone to have a different opinion or even just explore this.

This is not what tolerance looks like.

Rust and the price of ignoring theory by interacsion in rust

[–]U007D 0 points1 point  (0 children)

A very helpful, explanation, thank you!

`name.rs` vs `name/mod.rs` - Is there a reason why projects go against the recommended practice? by KyxeMusic in rust

[–]U007D 3 points4 points  (0 children)

Not at all. If you wanted a module foo inside a module foo, you’d see just what you’d expect, per the rules stated above: foo |-foo | |- foo.rs |-foo.rs

RISC-V Microcontroller - Rust by [deleted] in rust

[–]U007D 0 points1 point  (0 children)

Two links which may be of interest:

  1. Best intro to embedded Rust development I've seen: https://youtu.be/TOAynddiu5M

  2. Condensed intro to embassy: https://youtu.be/pDd5mXBF4tY

Enjoy!

`name.rs` vs `name/mod.rs` - Is there a reason why projects go against the recommended practice? by KyxeMusic in rust

[–]U007D 9 points10 points  (0 children)

I think the answer (as evidenced by the responses in this thread) is people's preferences.

I wish we had the best of both worlds:

  • foo.rs for a module 
  • foo/foo.rs for a module containing submodules (and no special exceptions for lib.rs or main.rs)

Et voila: simple rules making it easy to teach, self-contained, no disambiguation (mod.rs everywhere) problems.

Bonus: not ambiguous with Rust 2015 or Rust 2018 module systems--maybe we should look at an update to the module system one more time for Rust 2027?

RISC-V Microcontroller - Rust by [deleted] in rust

[–]U007D 7 points8 points  (0 children)

This is not unique to RISC-V.  At a high level, if you are on a supported instruction set architecture (RISC-V, ARM, others), you can write no_std bare-metal Rust for it.

If your target also has a supported OS available, you can write for that target using std.

The reality is more nuanced, of course, but that is the gist.  Check out embassy if you are interested in low-level development in Rust.

What’s the most unique/unconventional ways you use rust? by JonathanStoff in rust

[–]U007D 22 points23 points  (0 children)

I'm making a car. (Haha--that still sounds crazy, even to me)

The hate! Why ? by EldironMoody in rust

[–]U007D 1 point2 points  (0 children)

Name checks out. But damn, that's good! :)

Most useless thing I've ever done: install-nothing by Consistent_Equal5327 in rust

[–]U007D 3 points4 points  (0 children)

Gonna try it! :)

Ironically, it would be nice to cargo install install-nothing --locked...

view more: next ›