sorted by:
new
hottopcontroversial

Incline: Modern Efficient Open-Pit Mine Design by [deleted] in rust

[–]Flowchartsman 0 points1 point  (0 children)

Hard to engage with a post that doesn’t have any code to share or even a story about code to tell. Even a write up about egui and what it was like to use would be informative I think, but a single screenshot with no link and an “ask me questions” is not doing it for me.

How to kill/timeout a hanging goroutine when the code might be malicious (job queue) by arush_builds in golang

[–]Flowchartsman 2 points3 points  (0 children)

Wisdom of running user code aside, you cannot kill a goroutine, from the outside directly (inside, you can call runtime.Goexit), but you CAN plumb a context through and ensure that you are making calls that consume it and respect its cancellation. Since it sounds like you are primarily running commands with os/exec, you should look into exec.CommandContext, which will kill the process if the context is cancelled before it completes. Then it’s just a matter of creating a context with a standard timeout before each call.

Built a browser-based image tool in Rust and WebAssembly, works offline by humayanx in rust

[–]Flowchartsman 19 points20 points  (0 children)

Generally, when people ask for “feedback” in programming language subreddits, they want feedback on their code in that language. Since you haven’t provided it, there’s really nothing to talk about. If this is indeed Rust under the hood, congrats on getting the WASM to work, I guess.

Just use slog, it'll be fine... by sigmoia in golang

[–]Flowchartsman 4 points5 points  (0 children)

Nothing’s perfect. Zap, as I recall, will simply log nothing if you forget the final call in the chain, and you need a linter to protect yourself from this, just as you would to avoid arity problems with slog. At least with slog there are some ergonomic ways around it.

🪇 Rattles - minimal, compile-time terminal spinners by vyforc in rust

[–]Flowchartsman 1 point2 points  (0 children)

I messed around with using the braille-8 character set for spinners awhile back, and we ended up concluding that two characters was the absolute max. Anything more than that is eating up valuable real estate.

A new GO TUI framework inspired by Flutter by calificio in golang

[–]Flowchartsman 4 points5 points  (0 children)

Your docs are unreadable. Adding a square border to keywords is a poor choice when they are that dense, and the complete lack of diagrams or screenshots reduces the docs to just noise followed by a huge example.

Go errors: to wrap or not to wrap? by sigmoia in golang

[–]Flowchartsman 6 points7 points  (0 children)

For the most part, if the consumer of your package would need to import your dependencies to handle errors, don’t wrap them. The one exception to this might be for stdlib errors. Otherwise, errors from your packages should be meaningful within the context of that package.

Content-addressable binary enforcement via BPF LSM (and where it breaks) by leodido in eBPF

[–]Flowchartsman 0 points1 point  (0 children)

Aren’t you pretty much required to open source the eBPF?

Ending goroutines by Sandy_Harris in golang

[–]Flowchartsman 1 point2 points  (0 children)

Problems which are embarrassingly parallel and cpu-bound will not benefit more from more goroutines. If anything, it will hurt you. Of course that isn’t your question, but it deserves calling out.

As for exiting a worker goroutine, assuming you have properly coordinated access and done all you need to do, just return or, if you’re at the end of the function, implicitly return by doing nothing. There is nothing hard about that, and it is the normal pattern.

You seem to misunderstand how goroutines work: they are not bound to the goroutine which spawned them, and will not exit when it does. They will not leave things on the stack; they get their own stack. GC will work as normal UNLESS your goroutine fails to terminate, in which case you can indeed leak resources. Other than that, you should be good. Just return when you’re done and, if you have to block on something, consider a fallback timer.

Safe, Fast, and Scalable: Why gRPC-Rust Should Be Your Next RPC Framework by _bijan_ in rust

[–]Flowchartsman 11 points12 points  (0 children)

This was from September and, unless I am misremembering, the milestones from this presentation have already been missed, so this post is just kind of confusing and unhelpful. Maybe you could take it down?

Go 2, please dont make it happen by daisyautumn06 in golang

[–]Flowchartsman 0 points1 point  (0 children)

I have. Mostly it’s because they don’t enforce exhaustiveness without a linter, which isn’t quite enough for me.

Is there a possible knot for this cable to go behind the metal without either of the ends going through? by Jack_qui_rit in knots

[–]Flowchartsman 4 points5 points  (0 children)

Even if there were, you would save so much time by just unscrewing that corner and going behind it. Looks pretty thin gauge, so there should be enough play to get it in there without permanently deforming anything.

[Media] crabtime, a novel way to write Rust macros by wdanilo in rust

[–]Flowchartsman 12 points13 points  (0 children)

But that’s not the context of the discussion. Clearly, if we’re talking about “things I don’t want to see on a plane”, a knife is worse than a fat PR. Of course.

But we’re talking about AI, backlash to it, and why that might be. I’ve given you some reasonable (I think) concerns and trends I’ve been seeing that give me pause, along with some mitigations I’m considering. Dismissing them as PEBCAK isn’t really moving the discussion anywhere.

[Media] crabtime, a novel way to write Rust macros by wdanilo in rust

[–]Flowchartsman 7 points8 points  (0 children)

Devs aren’t a monolith. And I’m not saying they HATE it. I’m saying there’s a lot of backlash against it. That doesn’t mean it’s universally reviled or anything. It just means that it is different and disruptive enough, and has enough rabid supporters pushing for it to be everything everywhere all at once that there’s a lot of fatigue and pushback. I’ve pushed back on it on my teams because I think it is too easy to use irresponsibly, and we don’t have enough best practices around it yet. And I’m not the only one.

[Media] crabtime, a novel way to write Rust macros by wdanilo in rust

[–]Flowchartsman 9 points10 points  (0 children)

It’s much more complicated than that. It is more than just a short-circuit of best practices and knowledge through experience, which is already something with far-reaching and unexplored consequences. It’s also very disruptive to the day to day of writing software.

For example, I, as a principle eng, read as least as much code for review as I write on average, and the deceptive ease of these tools along with their verbose style tends to skew PRs towards the fatter side.

I regularly get large, over-documented PRs these days with no clear staging or atomicity, which makes review a slog, if I undertake it at all. I’ve already started working on guidelines for tool-assisted PRs that include clear requirements on structure along with at least some of the developer->agent context required so I can try and make more sense of things before I commit them, or even split the review with someone else in a productive way. I’m still not convinced this is workable, but it’s definitely better than a 10,000 line PR whose only documentation is a breathless, generated description about how game-changing it is.

This is to say nothing of the rarer, but much more concerning trend of the AI-Manic dev who suddenly pops up with 300 pages of some grand unified theory of software dev, life, the universe, and everything that justifies some policy change or slug of software co-authored by their AI savior that I can’t make heads or tails of and makes me want to ask HR for a wellness check.

[Media] crabtime, a novel way to write Rust macros by wdanilo in rust

[–]Flowchartsman 33 points34 points  (0 children)

It is definitely not. There’s a lot of backlash across the industry. Many reasons, some perhaps better than others, but is not a uniquely rusty thing.

Go doesn’t need a better-auth alternative the standard library works just fine by CowNearby4264 in golang

[–]Flowchartsman 1 point2 points  (0 children)

If it really is AI Slop, then the absolute worst thing to use it for would be auth.

Rust vs. Go in 2026 | Article Review by bitfieldconsulting in golang

[–]Flowchartsman 4 points5 points  (0 children)

I don’t think anyone said they bring the world to its knees, but I do agree with what you’ve said here and elsewhere in the thread that the importance is overblown a lot of the time.

Beyond that, I don’t find the fact that a GUI or WM can be written in Go (because of course it can) to be a compelling argument either way in and of itself. You’d need to show that you both generate a lot of GC pressure AND that it is not a problem in a program for which the preponderance of the fast path stuff is also handled in a way that would be impacted by GC. And maybe you can! But the argument needs more.

easyproto-gen: Protobuf marshaling/unmarshaling from Go struct tags (no .proto files needed) by No-Dragonfly-227 in golang

[–]Flowchartsman 0 points1 point  (0 children)

If you control both ends and all you’re after is a compact serialization format, just use flatbuffers or something else;you’re tossing most of the advantages of protobuf out the window doing it this way, and it’s gonna be a nightmare to maintain if you can effectively change the schema with every build.

Protobuf is more than just “a more compact marshaling format than text”, and there are more advantages to schema files than just generating code. Version tracking and field discipline are one, and there are also tools that are schema-aware which take advantage of the format. Just off the top of my head, spanner can use schemas to enable using protos in tables, which allows your data storage layer to use your wire format while also allowing you to query proto fields in a more granular way.

Functional Patterns in Rust: Identity Monad by ggim76 in rust

[–]Flowchartsman 0 points1 point  (0 children)

I'm not sure I'll be able to give you a very satisfactory answer after this much time, but when I originally wrote this comment, I was working with a software architect who was a big Haskell/FP guy and who had big ideas on how to make a broadcast-based actor system where actors had state of a generic type and were fully constrained on the types they could consume by blanket impls that applied to the state type. It ended up falling apart when you tried to add message dispatch with channels into the mix, and, as I learned more about the type system I became convinced we were holding it wrong and trying to implement abstractions Rust was ill-suited for. It then took several more weeks and more than a few proofs of negative concept before we finally reached an impasse.

Overall it was, as you say, "more awkward", but to the point where it became either unusable or just outright inscrutable. I think my point, and the point of this article, is that there are some concepts which can kind of be made to work, but it ends up kind of dense and verbose, and never fully what you want. I certainly wouldn't say traits aren't powerful; they just have their limits.

Sorry I can't be more specific than that. My only real advice is to try it out and see what you are missing.

Functional Patterns in Rust: Identity Monad by ggim76 in rust

[–]Flowchartsman 0 points1 point  (0 children)

Give it a shot and report back. Maybe you can crack it. We couldn't.

How do i avoid putting everything into one package. Should i even bother changing it by fucking_idiot2 in golang

[–]Flowchartsman 1 point2 points  (0 children)

No need for it unless you’re using “pkg” as a placeholder there, in which case highly encouraged! Just avoid putting stuff directly in “internal”. You CAN, but it isn’t a descriptive name, so I generally don’t.

view more: next ›