Posted by ksec 3 days ago
When I'm in my flow state, I find reaching for a pointing device is taking longer than typing something in, BTW. Keyboard driven interfaces and terminals are underrated.
I like IDEs for all the code insight they provide. Running a named tests by typing its name is not a nuisance by any measurable distance (for me).
You might not find point and click selection of tests valuable, but the world loves GUI for the same reason, people prefer to click rather than type long commands etc. Thats why finder and windows explorer exist, because enough people would rather use that UI rather than typing at the command line.
I'm just putting forward my perspective and choices, which are also not made of granite and subject to change to the scenario, needs and possibilities in any given moment.
I strongly advocate people work the way they feel comfortable happy. Because (even if slow), it's smooth, and smooth is fast.
items.iter().enumerate().filter(|(_, i)| cond(i)).map(|(idx, i)| Pointer::idx(i, path, idx)).collect()
while (i < cursors.len) {
if (actual_index < arr.items.len) { cursors[i] = .{...}; i += 1; }
else iteration.remove(i);
}
But then, saying while "let Some(item) = iter.next()" everytime is tedious, so they give you .iter() - for any type that is efficiently iterable.
Nothing stopping you using a manual loop that you need to update if you change the container type.
items.filter(|(i)| cond(i)).map(Pointer::idx).collect()
items is already an iteratible so you can do direct .filter on it as well
tl;dr if the code looks ugly you're probably not taking advantage of a language feature that allows it to look pretty.
I still don’t know that I find it more intuitive or readable than the simple loop, but it’s much less awful than before.
items.filter(cond).map(Pointer::idx)
Zig suffers from much of those, as does Nim. Rust OTOH appears well integrated and stable and I'm even seeing a lot of corporate use. I'd love to see V get to that level as well. But seems it's not even here in the present, let alone the future.
What's the pitch?
That was 7 years ago and since then the project has not delivered the grail, instead settling to be more of a mashup between go and C.
Bend is completely different it was just announced last week. It doesn’t have any users and has a weird ai integration so I done see how it’s relevant as a contender in the systems space at all.
> Here’s the actual difference, side by side
I realize the author put a disclaimer at the bottom that they used AI for styling, but having to wade through this stuff at work all day my brain now actively rejects Claude-isms in prose.
Why can't people just write shorter bullet pointed lists of things and post that? Just post what you put into the AI!
61% generated by AI 12% assisted by AI
"Holds up"
"not a toy, but not a sprawling project either, and ideally.."
"And that’s the trap"
ctrl F "real" -> 6 usages
ctrl F "genuine" -> 4 usages
"Rust: this exact shape can’t compile."
And even if LLMs didn’t exist (or had different idiosyncrasies), the article would still be exhibiting a repeatedly weird and stilted writing style.
> Disclaimer: styling and error handling throughout this article were cleaned up with the help of AI.
The implication seems to be "light editing", but the LLM styling really comes through, so I guess that tracks.
Is that what they said? If that's not what they said, why are you putting words in their mouth in an attempt to weaken their statement into some completely ridiculous stupid strawman that is obviously not actually what they said?
this isn't true and hasn't been true for a while
> I didn’t put words into anyones mouth
literally read your first sentence again, and notice the word "others"
In this case it feels AI generated with human polish, or vice versa. A couple tells are "One caveat worth stating up front..." and of course, "...the shape of the language itself...".
I actually think this might be a good thing? I'm way more aware of cliches and filler in my writing these days, and it almost always reads better when I just remove them and plainly say the thing.
What I found in practice: the borrow checker friction is real, but it also silently eliminates a whole class of concurrency bugs that Zig's safety checks can't catch. When you reach for Zig on a project where multiple threads touch the same arena, you end up hand-rolling the invariants Rust enforces by default. The question is whether the dev-time friction is worth the invariant guarantee.
For services where a memory safety bug = outage + data loss, I'll take Rust's friction every time. For CLI tools and one-off scripts where the worst case is a crash, Zig's lack of ceremony wins.
It would be nice if people would note that their posts are AI generated, and put that in the title here to make it easier to ignore
It's entirely possible I'm just getting worse and worse at picking out LLM writing these days too, who knows.
The real problem is that people are using C for the wrong reasons. C is for the development of operating systems and low-level code, not applications.
Zig is more modern but anything that does even one iota more of hand-holding or has anything that looks like a guardrail fails the test.
If you want to write applications use Pascal, Java, C#, Swift or Go.
i do agree that applications are probably best built in fast garbage collected language. but it also seems like go, java, C#, etc have other downsides that push people towards things like zig or rust even for apps. it also depends on what you mean by "apps". is a server an app? what about an actual native cross-platform desktop application? does go, c#, or java have a good paradigm for that? what if you want to use an oss language not tied to a big tech company? you start running out of suitable languages pretty dang fast.
you could name any application type and i could probably give you reasons why you might want to build it in a "systems" language instead of a high level one.
A lot of the “high level assembly” parts of C are actually compiler extensions and not from the C spec.
libc is even worse.
And most C library calls are actually Unix system calls. Malloc() is an operating system call and not a library call. Yes, they made it a library call later on to facilitate usage in other operating systems but it was originally an integral part of the Unix OS.
We're trying to solve a problem that shouldn't be solved. We're continuing and even confirming the usage of systems programming languages for application development.
Postgres and Nginx make sense in system programming languages; they’re extremely performance sensitive and that granular level of control offers them features. Interpreters are sort of the same, they interact with the OS a ton, it makes sense to work in the same language as the OS.
I do generally agree for the app tier of a web app. I wouldn’t build a CMS in Rust, but I also wouldn’t build a reverse proxy in Python.
EVERYTHING ELSE is invalid usage no matter how performance critical people claim their application is. These are just excuses for people to use a grossly unsafe language to get that last 2% of performance whilst costing the world trillions in lost productivity and security breaches.
C and C++ are a liability for many reasons since memory corruption is notoriously hard to detect, localize and fix. And multi-threading is even harder, almost a dark science to get right.
For those reasons alone Rust is a no-brainer.