TehPers

Yep. This was the difference between a silent, recoverable error and a loud failure.

It seems like they’re planning to remove all potential panics based on the end of their article. This would be a good idea considering the scale of the service’s usage.

(Also, for anyone who’s not reading the article, the unwrap caused the service to crash, but wasn’t the source of the issues to begin with. It was just what toppled over first.)

monitoring how they are used is good to identify if people are actually more productive with it

Unfortunately, many jobs skipped this step. The marketing on AI tools should be illegal.

Far too many CEOs are promised that their employees will do more with less, so of course they give their employees more to do and make them use AI, then fire employees because the remaining ones are supposed to be more productive.

Some are. Many aren’t.

Like your comparison, the issue is that it’s not the right tool for every job, nor is it the right tool for everyone. (Whether it’s the right tool for anyone is another question of course, but some people feel more productive with it at times, so I’ll just leave it at that.)

Anyway, I’m fortunate enough to be in a position where AI is only strongly encouraged, but not forced. My friend was not though. Then he used it because he had to, despite it being useless to him. Then he, a chunk of his management chain, and half his department were fired. Nobody was hired to replace them.

There are plenty of companies that track metrics on AI usage. Big names like Amazon come up of course, but even some small companies require employees to use it.

So to answer your question: a lot of people, regardless of if they want to.

And no, they can’t all quit and get a new job.

Rust currently isn’t as performant as optimized C code, and I highly doubt that even unsafe rust can beat hand optimized assembly — C can’t, anyways.

A bit tangential, but to answer this question, nothing beats the most optimized assembly code. At best, programming languages can only hope to match the most optimized assembly.

Rust does have macros for inlining assembly into your program, but it’s horribly unsafe and not super easy to work with.

Rewriting ffmpeg in Rust is not a solution here (like you’re saying).

Wow genius response. Glad you actually addressed my comment.

ffmpeg devs can refuse the AI generated bugfixes for all we care.

This is a separate problem, but it’s still a problem. Many projects have seen a rise in slop PRs. curl is notorious for complaining about AI slop vulnerabilities and patch requests.

But I think we both agree that Google needs to be doing something more rather than putting the workload entirely on the ffmpeg devs.

I don’t understand how a bug is supposed to know whether it’s triggered inside or outside of a google service.

Who found the bug, and what triggered it? Does it affect all users, or does it only affect one specific service that uses it in one specific way due to a weird, obscure set of preconditions or extraordinarily uncommon environment configuration?

Most security vulnerabilities in projects this heavily used are hyper obscure.

If the bug is manifestly present in ffmpeg and it’s discovered at google, what are you saying is supposed to happen?

e) Report it with the usual 90 day disclosure rule, then fix the bug, or at least reduce the burden as much as possible on those who do need to fix it.

Google is the one with the vulnerable service. ffmpeg itself is a tool, but the vast majority of end users don’t use it directly, therefore the ffmpeg devs are not the ones directly (or possibly at all) affected by the bug.

There are a bunch of Rust zealots busily rewriting GNU Coreutils which in practice have been quite reliable and not that badly in need of rewriting. Maybe the zealots should turn their attention to ffmpeg (a bug minefield of long renown) instead.

This is weirdly offtopic, a gross misrepresentation of what they are doing, and horribly dismissive of the fact that every single person being discussed who is doing the real work is not being paid support fees by Google. Do not dictate what they should do with their time until you enter a contract with them. Until that point, what they do is none of your business.

Alternatively (or in addition), some effort should go into sandboxing ffmpeg so its bugs can be contained.

And who will do this effort?

Bug reports that apply only to Google’s services or which surface only because of them are bugs Google needs to fix. They can and do submit bug reports all they want. Nobody is obligated to fix them.

The other part of this is, of course, disclosure. Google’s disclosure of these bugs discredits ffmpeg developers and puts the blame on them if they fail to fix the vulnerabilities. They can acknowledge the project as being a volunteer, hobby project created by others if they want, and they can treat it like that. But if they’re doing that, they should not be putting responsibilities on them.

If Google wants to use ffmpeg, they can. But a bug in ffmpeg that affects Google’s services is a bug in Google’s service. It is not the responsibility of unpaid volunteers to maintain their services for them.

The issue is not whether security issues exist in ffmpeg. It’s clear that vulnerabilities need to be fixed.

The issue is with who actually fixes them. Your last sentence is the core of it. Google can submit as many bug reports as they want, but they better be willing to ensure the bugs get fixed too.

I think the last thing ffmpeg devs want is AI generated bugfixes to their assembly-heavy codebase. What they should do is dedicate time for experienced devs to fix the bugs instead.

Is this your first time here?

Your account is brand new and you’ve already posted now three posts related to JPlus in this community in one day. Please tell me you’re joking with this one.

This post is a GitHub link to the project. Cool, I love seeing new projects, especially when the goal is to make it harder to write buggy code.

The other post is an article that immediately links to the GitHub. The GitHub contains a link at the top to, what I can tell, the same exact article. Both the article and the GitHub README explain what JPlus is and how to use it.

Why is this two posts when they contain the same information and link to each other directly at the top?

This is a distinction without a difference. Both introduce and explain how to use the project.

How does this post differ from this one? Why make two posts for the same thing?

I bought a license many, many years ago and loved SmartGit. I just use the cli now, but if you’re looking for a GUI, it’s a great choice.

The conclusion of this experiment is objectively wrong when generalized. At work, to my disappointment, we have been trying for years to make this work, and it has been failure after failure (and I wish we’d just stop, but eventually we moved to more useful stuff like building tools adjacent to the problem, which is honestly the only reason I stuck around).

There are a couple reasons why this problem cannot succeed:

1. The outputs of LLMs are nondeterministic. Most problems require determinism. For example, REST API standards require idempotency from some kinds of requests, and a LLM without a fixed seed and a temperature of 0 will return different responses at least some of the time.
2. Most real-world problems are not simple input-output machines. When calling, let’s say for example, an API to post a message to Lemmy, that endpoint does a lot of work. It needs to store the message in the darabase, federate the message, and verify that the message is safe. It also needs to validate the user’s credential before all of this, and it needs to record telemetry for observability purposes. LLMs are not able to do all this. They might, if you’re really lucky, be able to generate code that does this, but a single LLM call can’t do it by itself.
3. Some real world problems operate on unbounded input sizes. Context sizes are constrained and as currently designed cannot handle unbounded inputs. See signal processing for an example of this, and for an example of a problem a LLM cannot solve because it cannot receive the input.
4. LLM outputs cannot be deterministically improved. You can make changes to prompts and so on but the output will not monotonically improve when doing this. Improving one result often means sacrificing another result.
5. The kinds of models you want to run are not in your control. Using Claude? K Anthropic updated the model and now your outputs all changed and you need to update your prompts again. This fucked us over many times.

The list keeps going on. My suggestion? Just don’t. You’ll spend less time implementing the thing than trying to get an LLM to do it. You’ll save operating expenses. You’ll be less of an asshole.

It sounded from the PSF article that the biggest reason they rejected it, aside from the ethical concerns, was that they could be asked to give the money back if they are found to be violating that term anywhere and at any time. Even if they didn’t care about the term regarding DEI, the risk of being liable for $1.5m to the US government all because an orange blob didn’t like the logo is too great of a risk.

I mean, I find TypeScript fun to write. The only thing I really dislike about it is configuring the tools (tsc, eslint, etc). It’s a great language when everything’s setup and you disallow all the ugly JSisms with your linter and tsc.

Used Claude 4 for something at work (not much of a choice here and that team said they generate all their code). It’s sycophantic af. Between “you’re absolutely right” and it confidently making stuff up, I’ve wasted 20 minutes and an unknown number of tokens on it generating a non-functional unit test and then failing to solve the type errors and eslint errors.

There are some times it was faster to use, sure, but only because I don’t have the time to learn the APIs myself due to having to deliver an entire feature in a week by myself (rest of the team doesn’t know frontend) and other shitty high level management decisions.

At the end of the day, I learned nothing by using it, the tests pass but I have no clue if they test the right edge cases, and I guess I get to merge my code and never work on this project again.

I was being ridiculed in the past and called a slop-generator

I can only imagine why. Surely it’s unrelated to this?

I’ve completely moved to codex cli as daily driver. I run between 3-8 in parallel in a 3x3 terminal grid

Nah, couldn’t be.

I got a simple approach to comments: do whatever makes the most sense to you and your team and anyone else who is expected to read or maintain the code.

All these hard rules around comments, where they should live, whether they should exist, etc. exist only to be broken by edge cases. Personally I agree with this post in the given example, but eventually an edge case will come up when this no longer works well.

I think far too many people focus on comments, especially related to Clean Code. At the end of the day, what I want to see is:

• Does the code work? How do you know?
• What does the code do? How do you know? How do I know?
• Can I easily add to your code without breaking it?

Whether you use comments at all, where you place them, whether they are full sentences, fragments, lowercase, sentence case, etc makes no difference to me as long as I know what the code does when I see it (assuming sufficient domain knowledge).