nixpulvis

I think it's worth understanding the technology so we can have informed strategies for how to best regulate it.

We don't solve the climate crisis by abandoning all the technological progress which has put such a strain on our ecosystem, we solve it by rethinking how we use this technology, and finding new technologies and policies to better meet our needs.

Haha, yes 100% I've had the same thought.

I recently learned the term "thought-terminating cliché" and it's so incredibly prevalent in society these days. Always has been I'm sure, but short form text based anonymous communication must be making it worse.

I'm so frustrated by both the zealous AI bulls and the blind AI opposition.

There's a lot of issues, ranging over technical, cultural, environmental, and moral problems. But there's also obvious value. To say otherwise tells me you haven't actually tried to make use of these tools.

It's one thing to get an AI google response and feel like it's dubious, it's another thing to know what you want and have an LLM find the APIs for a framework you're not familiar with yet and put the pieces together. The only way I use AI for programming still involves a large amount of rejecting the responses and a massive amount of reading and validating.

Am I able to write things faster with LLMs, yes. Am I missing out on the work involved in learning things I would be forced to otherwise, also yes. Are coworkers pushing stuff they don't understand more, surely.

It's a mixed bag, and we need more balanced takes in the discussion around this.

What makes you say that exactly?

It didn't have a good sync story when I checked last.

I swear I watched this Keynote before when they announced Apple Intelligence. Then proceeded to deliver nothing. Apple is so lost it makes me really sad.

Not at all.

I'm (slowly) working on a version controlled local-first password manager for exactly this reason.

Apple Passwords reliably updates passwords in its database before the password is confirmed to be actually changed. I've been locked out of accounts many times to this. They really need to focus on these basic UX issues.

Hey Edwin. Glad to see your post pop up. I remember doing a hackathon with you back in like 2012/2013.

I think the ability to get to a working prototype faster is very empowering, even if some will be tempted to ship these incomplete ideas. Design and UX needs benefits greatly from being able to play with it, and experience the actual flows beyond just a storyboard and wireframes.

Because this isn't about guarding against general vulnerabilities. This is about guarding against a class of supply chain attack where an attacker compromises the packaging system in a way that they slip in a malicious release.

It is true if everyone waits a cooldown (I don't like this name, but that's another thing) period, then it doesn't solve anything, but as others have pointed out, just because you don't build off the cooldown doesn't mean you and others aren't watching the releases.

Closing the window makes the burden of hiding the exploit higher, which is I think objectively an improvement of security posture.

The LLMs already do that themselves with `tail` all the time. There's a lot of room for improvement on top of that. Though they usually figure it out after a few tries. I often just paste manual runs errors myself anyway.

My agents often write themselves scripts. Isn't that effectively what you're asking for? Prompting for scripts can also be a useful time and accuracy tactic when you know it'll be a good fit for it.

I'm not sure how much overlap there is between this project and Tectonic [1], but that's what I use personally for local PDF generation, and it's also using a good bit of Rust.

Just thought I'd mention since it's related and I really like the project.

[1] https://github.com/tectonic-typesetting/tectonic

Auto-reply with the LICENSE.

I think about this a lot.

In some ways software is really fundamentally different from things like baking or plumbing. Many bakers love the craft but nobody expects free baked good (except maybe their family). Many plumbers are true craftsmen and take pride helping solve peoples problems, but we don't expect free plumbing. On the other hand, once you write the code, the logic is complete, its closeness to an equation makes it feel like selling algebra homework.

More importantly though, baked goods get eaten, and pipes aren't assumed to suddenly become load bearing. I think a lot of developers hesitate to sell software they aren't prepared to support professionally. Toy projects then sometimes gain a community and grow organically. It's at this stage I feel we need a better path to funding without a lot of the capture that can occur.

It would be cool if we could "farmers marketize" software though. Come together to taste some exotic and local varieties. Maybe meet the local shops, pay for some overpriced TUI gizmo or a hash function with a weird pattern.

Sorry went into fantasy land there. This is obviously not the solution to the broader OSS funding issue, but it's a cute dream where maybe some people make a buck.

I think the bigger solution would have more opportunities for people outside of academia to get small grants to work on their projects. More foundations supporting the core technology and development that the tech world depends on now, and prospectively in the future.

Imagine if they let us make and share apps too.

The amount of creativity and innovation the App Store has stifled is surely enormous and downright sad.

True, and failure to scale can also kill you. Everything needs a balance that works for you.

One of Rust's central design goals is to allow zero cost abstractions. Unifying the async model by basically treating all code as being possibly async would make that very challenging, if not impossible. Could be an interesting idea, but not currently tenable.

One problem I have with systems like gevent is that it can make it much harder to look at some code and figure out what execution model it's going to run with. Early Rust actually did have a N:M threading model as part of its runtime, but it was dropped.

I think one thing Rust could do to make async feel less like an MVP is to ship a default executor, much like it has a default allocator.

Security minded generalists exist. They might move slower than you expect of a MFBS (move fast break shit) engineer, but you might also end up with fewer issues later.

Surely we can give more informed answers to questions like this than to compare a technical decision to the craving for a sandwich.

Comments like this are apathetic and reduce the challenges of good software engineering to hopes and random chance.

I think it's partially accurate, and partially a consequence of how async fractures the design space, so it will always feel like a somewhat separate thing, or at least until we figure out how to make APIs agnostic to async-ness.

I hate them, but not for perhaps the normal reason. I also hate the way delivery has progressed. Delivery used to be relegated to a few types of food which were designed better for it. Remember when your pizza came hot in an insulated pizza sleeve, not dropped at your entrance cold and sad?

We're making it more and more normal to completely avoid interacting with each other and having service be something we cherish, I think this is hugely detrimental to society.

This is the right idea.

Lightning remains a better physical connection. So many USB-C connections I have are flimsy as hell.

Am I the only one who also finds it comical that rejecting cookies requires a cookie.

> These are noisy in test code where panicking on bad data is exactly what you want. The cleanest way to scope them to non-test code is to put #![cfg_attr(test, allow(clippy::unwrap_used, clippy::expect_used, clippy::panic, clippy::indexing_slicing, clippy::arithmetic_side_effects))] at the top of each crate root, or to gate #[allow(...)] on the individual #[cfg(test)] modules.

Surely there's a better way.

Alacritty doesn't accept donations.

Alacritty doesn't accept donations.