DeepSWE seems to strongly, strongly prefer ChatGPT models. There were also major flaws in its methodology pointed out recently, that overlap strongly with the flaws OpenAI pointed out in its SWE Verified report.
I use both ChatGPT and Claude for engineering work on a daily basis, touching performance critical code to application backends to frontend work, and I've found that DeepSWE scores don't reflect my reality when I assess high quality output from the models/harnesses.
Not that Opus always beats GPT 5.5., but that 5.5 is ahead of Opus on a general benchmark smells off to me.
On top of that, it has a more restrictive license than AmazonBrandFilter. Given this appears to be a very simple AI project, why not just reimplement any missing functionality from AmazonBrandFilter into something under a free license? The most difficult to duplicate component is MIT.
He's entitled to his political views and just as we're entitled to potentially use or not use his service because of them :)
Not sure why it's such an issue to discuss the political views of the beneficiaries of services we use. I understand it's mostly uninteresting as far as comment sections go, but it's always bizarre to see a defense of political association when often the impetus for sharing this type of information is for people/consumers to exercise their right to associate with business based on their political outlook.
Everyone gets to share but it's also completely within the forum rules to call out irrelevant anecdotes as uninteresting to the discussion.
I have no idea why you're making a comparison to a TV show; nothing that was described was anything akin to that. I just made examples out of insufferable and clueless forum comments, that very clearly detract from discussion more than they contribute to it.
I don't think you should assume that describing meaningless and unrelated anecdotes as "uninteresting" is equivalent to users calling for a forum ban, which is seemingly what you're doing when you point to forum rules when encountering a critique.
When performance isn't a concern, I largely agree! Not every financial system can use big decimal as their base, though, too. And HFT isn't the only place in the financial sector where this performance concern might pop up.
"10% of Americans are uninsured. A US state is pushing to insure all of their residents."
"I'm insured!"
"Open-source software projects are being spammed with LLM generated PRs. Contributions are becoming more restricted".
"I have a repo that isn't being spammed!"
Sometimes sharing a somewhat related experience is completely irrelevant to the topic at hand, and also completely uninteresting. It does not matter that somehow their "experience is valid".
Agree with this, working from HFT to payments to account management in the past.
You can have the blockchain team be an expert in converting integer cents, or the forex team be an expert in sub-cent conversions. You don't want to require _every team_ to have expertise in float math, by default.
Spam from a bot! I think there are automatic filters to prevent this so I'm surprised it wasn't banned before we all had to see it, maybe @dang can comment on how quickly these are supposed to be resolved
Unfortunately this is how export controls work. We don't let foreign researchers around national security parts of national labs, even if they work there, because it's simply the easiest security measure you can take. It doesn't mean it's a good outcome for researchers or research. It's insurance of US directed funds.
Methodology leaves a lot to be desired in terms of understanding the tasks you've used. Being detailed about why they're more meaningful tests than the long horizon and coding tests used by other rankings is important.
False positives and poorly defined tasks/acceptance criteria have let some models have insanely inflated scores on bad benchmarks.
And sure, you can say they're not disclosed to prevent gaming, but if you're the only one who can review them then the might as well be a random number generator display with an unreadable UI.
Pascal has a lot of influence on this, but Go as well! My PL friends often talk about Go's benefits and flaws when thinking about advancing other their own projects or improving the mainstream languages they work on.
Not working within the bounds of lifetimes, and more ecosystem that doesn't live in the world of lifetimes, gives Zig some of the wonderful dev ergonomics of Rust while making it easier to prototype.
For small, short game dev, or even smaller embedded projects, this ends up being a wonderful way to live as often times you're trying to eke out performance in ways that would require breaking out of whatever type abstractions or using unsafe.
For long-lived systems, for systems that need to have lots of people with various skill levels work on them, for a mature ecosystem, for a language/standard library with stability... You probably don't want to pick Zig right now. Some of these points will change over time with Zig becoming more mature, some won't. Zig will always be super cool to build things in.
As far as most low-level programmers not liking Rust like some other commenters say, lol, lmao even.