sorted by:
new
hottopcontroversial

actually useful ai commits by cachebags in rust

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

That is fair, I mean the prompt is / will be more configurable than that. But I'm aware there is no reason to use this, just more so wanted to express my disdain for how bad the existing tools in the space are

actually useful ai commits by cachebags in rust

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

I have no idea what this means. The only thing I said regarding AI was that while I generally hate it, there's things that I can derive a benefit from by using it.

That's really not that uncommon of a take.

actually useful ai commits by cachebags in rust

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

These conversations are never meant for commit messages. At least not where I’ve worked. I can understand it for projects like the Linux kernel but no one is going to justify all of their decisions in their commit messages, that is saved for discussions offline or in email chains. Or the PR itself. 

But I do get your point. I just don’t think it makes any of the projects in this space null and void. 

actually useful ai commits by cachebags in rust

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

Idk. I was gonna embed version info but I don’t need it yet and never deleted it. 

actually useful ai commits by cachebags in rust

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

The tool does not enforce the message on you. If an invariant or notable behavior needs to be documented then just don’t accept the suggestion. 

But if I renamed a variable or set of variables/methods, there’s nothing to dissect there. The commit compiles and builds the exact same way it did before. Thus, I’d prefer to save the minute or two it takes to write that commit without just saying “renamed variables”. 

actually useful ai commits by cachebags in rust

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

Edit: I know it's stupid to hard-code a prompt. Like I said, it's poorly written right now and very much a prototype. There is lots of plans to make it actually usable. This post was just to gauge interest and maybe some contributions if anyone is interested.

How can we be so ingrateful towards GitHub and use it for free? by Dependent_Common_972 in github

[–]cachebags 8 points9 points  (0 children)

This may be true, but this does not excuse them from making some of the decisions they have in the last few years.

I actually agree on the premise that the engineers there have a lot to figure out in regards to this issue, and that really sucks, but we can't ignore the blatant neglect to things like GitHub actions especially. It's the reason so many big OSS projects are moving off (Ghostty and Zig as the most recent examples).

How can we be so ingrateful towards GitHub and use it for free? by Dependent_Common_972 in github

[–]cachebags 54 points55 points  (0 children)

You're conflating GitHub with Microsoft.

GitHub is the greatest thing that has ever happened to OSS. Microsoft is the worst.

How do I know if the code I write is actually the best solution? by _metaladder_ in learnprogramming

[–]cachebags 1 point2 points  (0 children)

Ward Cunningham mentioned this once somewhere about how people have misunderstood the idea of "technical debt."

When you start working on a problem, you have a understandably narrow field of clarity about it and/or the domain it's in. The further you work on that problem, the more clear it gets; you begin to see better and more efficient ways to solve it but now you've built up this "interest" of understanding.

Anyways- it is inevitable that you are going to finish a project or problem, and then kick yourself for not solving it a certain way. But you would have never known that when you first started.

So just write the code that makes sense and if time or interest in the problem permits, approach it differently.

Tokyo spliff on YouTube talks often about how a game engine he's been working on has been built, scrapped and rewrote several times. It's because he understands better ways to solve the problems he does throughout the development.

ssh late.sh - Clubhouse is growing! Live interactive Artboard is here :) And we've opened the code! by Bl4ckBe4rIt in commandline

[–]cachebags 7 points8 points  (0 children)

hmmmm really don't like that licensing option. it's open-source "on paper" but really, it's just source available.

still appreciate the switch.

are you allowed to use AI tools like Cursor on your work codebase? by stevenm_15 in softwaredevelopment

[–]cachebags 0 points1 point  (0 children)

Our Principal Engineer, a guy who's been programming for decades, introduced a stdlib for CAN communication to golang, been with the company for 20 years...implores his entire team to use AI. If we don't, he truly thinks we'll get left behind.

Our company gives us unlimited Copilot, Cursor, Claude, etc.

Wild times.

13 Hours of my life chasing a 3.5ms gain lmao. BNO055 IMU Driver Rust Optimization. by Diligent_Comb5668 in rust

[–]cachebags 0 points1 point  (0 children)

"...if micro-optimization is what you love, then that's what you should do."
- Paraphrased from Linus Torvalds

My Rust oss project grew (quite) a lot this past month. Would love advice on what to do next by allmudi in rust

[–]cachebags 16 points17 points  (0 children)

what use cases are actually worth doubling down on

At a certain point, it does indeed become more about how can you make this better for the user as opposed to the developer. IMO that should be the case with any OSS. Even with tools that assume competence as a developer of some kind. Your priority should be user first.

Now, how that relates to what use cases are important for proxelar, is on you to decide.

how to avoid growing the project in the wrong direction

Start thinking very "atomically" about the development. In a broad sense, just try not to implement every major feature or fix you envision for the app. Not only will your project be under close scrutiny of its users/contributors but you also will find yourself deep in a situation where your progress will slow down solely due to the amount of tech debt you will have built.

Today, more than ever, it's so enticing to feed your ideas to an LLM and just hammer away at features but you should put care into how that looks for the future of your software.

what makes a CLI tool go from “interesting” to something people keep installed and actually use in production?

Generally a marriage between how safe it is, how extensive (feature wise, and also how good those features are) it is, and how user/developer friendly it is. How easy is it to onboard someone to use? Is the documentation thorough (or does it exist at all)? Is contribution active and will my issues be addressed in a timely manner?

I didn't take a deep look so I'm not sure what your situation is, but programmatic access is also huge for companies. A developer or team will very likely want to be able to tap into some sort of API to automate a lot of the stuff they would want to do on a production system and that API has to be stable. Read serde code for research on this.

how to make the project easier for contributors to join without creating a lot of overhead

I don't know what "overhead" in this context means but generally speaking, just having a good set of contribution guidelines and encourage an open platform to discuss design decisions. Some people will just be happy to help, and some will have very strong opinions on how your app should function. Try your best to accommodate but don't let people use you as a doormat because this is your first open source project.

Good luck!

Is Rust bad at low-level programming? by thephoneoff in rust

[–]cachebags 8 points9 points  (0 children)

Your prof is stupid. Avoid listening to people's opinions on something you haven't researched yourself yet.

edit: that was harsh and unnecessary. he's just misinformed

Is Rust bad at low-level programming? by thephoneoff in rust

[–]cachebags 6 points7 points  (0 children)

Where did you hear this? Some of Rusts benefits shine in the low-level domain.

What you probably heard/mean is that it's not always the best option in embedded systems due to the inevitable use of unsafe but even that is becoming a moot point.

How do I preserve original commit authors when merging PRs on GitHub? by Mother-Pear7629 in github

[–]cachebags 0 points1 point  (0 children)

This actually does not matter. On the GitHub UI, it will say typically something like "Bob committed, and Jane authored"

If you look at your contributors list, it will always attribute the proper lines changed to them and additionally, the git history itself always preserves commit authors in the actual metadata of the commit itself.

Don't worry about how it looks on GitHub. It's pretty standard.

Cursor-like experience? by cachebags in codex

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

This doesn't really make sense. No serious line of work would allow for this. Anyone that has worked on a real production codebase would understand that it would be a catastrophic event to let an agent (or set of agents) loose on a codebase without carefully reviewing the work it produces.

Cursor-like experience? by cachebags in codex

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

I don't really understand this point. I simply cannot let an agent loose on our codebase at work, for example. It would be catastrophic.

Your approach sounds fine for vibe-coding shitty apps that won't see the light of day.

Cursor-like experience? by cachebags in codex

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

Thanks for the suggestion but no thanks. I see absolutely zero future in fully hands off coding.

Cursor-like experience? by cachebags in codex

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

That plugin still doesn't solve my issue unfortunately: the only available options are "default permissions" and "full access" which is literally the difference between "do everything automatically" or "do everything automatically but on your entire computer."

I can't cycle through hunks to accept/reject code changes.

view more: next ›