gyesxnuibh (u/gyesxnuibh)

gyesxnuibh commented on Writing Code Was Never the Bottleneck ordep.dev/posts/writing-c... · Posted by u/phire

oytis · 6 months ago

> Does that work as well with non-strangers who are your coworker?

Yeah, OK, I guess you have to be a bit less unapologetic than Linux kernel maintainers in this case, but you can still shift the culture towards more careful PRs I think.

> why are you even organizationally using LLMs

Many people believe LLMs make coders more productive, and given the rapid progress of gen AI it's probably not wise to just dismiss this view. But there need to be guardrails to ensure the productivity is real and not just creating liability. We could live with weaker guardrails if we can trust that the code was in a trusted colleague's head before appearing in the repo. But if we can't, I guess stronger guardrails are the only way, aren't they?

gyesxnuibh · 6 months ago

My point in that second question was: Is the human challenge of getting a lot of inexperienced engineers to fully understand the LLM output actually worth the time, effort and money to solve vs sticking to solving the technical problems that you're trying to make the LLM solve?

Usually organizational changes are massive efforts. But I guess hype is a hell of an inertia buster.

gyesxnuibh commented on A Higgs-Bugson in the Linux Kernel blog.janestreet.com/a-hig... · Posted by u/Ne02ptzero

eqvinox · 6 months ago

> works so well a bug showed up in the kernel :-)

What exactly are you trying to highlight here? Most code has bugs. This one is someone forgetting to stick to actual behavior described in 1997, it's a mistake, mistakes happen. Which one of "secure", "simple", "battle tested" and "no crazy architecture" do you think this disproves?

Or do you think CIFS or Ceph have no bugs?

gyesxnuibh · 6 months ago

I think they're saying typically the kernel one of the last places you'd expect the bug, so it shows that it is battle tested?

I don't think they're being snarky.

gyesxnuibh commented on Writing Code Was Never the Bottleneck ordep.dev/posts/writing-c... · Posted by u/phire

oytis · 6 months ago

There are ways to fight it though. Look at Linux kernel for instance - they have been overwhelmed with poor contributions long before LLMs. The answer is to maintain standards that put as much burden on the contributor as possible, and normalizing unapologetic "no" from reviewers.

gyesxnuibh · 6 months ago

Does that work as well with non-strangers who are your coworker? I'm not sure.

Also if you're organizationally changing the culture to force people to put more effort in writing the code, why are you even organizationally using LLMs...?

gyesxnuibh commented on Save your disk, write files directly into RAM with /dev/shm hiandrewquinn.github.io/t... · Posted by u/hiAndrewQuinn

quotemstr · 6 months ago

/tmp is literally POSIX:

https://pubs.opengroup.org/onlinepubs/9799919799/

It doesn't get more standard than that.

It's because of people doing random nonstandard shit that we need to Docker-ize a lot of software these days. People refuse to lift a single finger to adhere to conventions that let programs co-exist without simulating a whole god damn computational universe for each damn program.

gyesxnuibh · 6 months ago

> /tmp A directory made available for applications that need a place to create temporary files. Applications shall be allowed to create files in this directory, but shall not assume that such files are preserved between invocations of the application.

It doesn't say anything about what it's backed by.

gyesxnuibh commented on Google Cloud Incident Report – 2025-06-13 status.cloud.google.com/i... · Posted by u/denysvitali

blibble · 6 months ago

this is really amateur level stuff: NPEs, no error handling, no exponential backoff, no test coverage, no testing in staging, no gradual rollout, fail deadly

I read their SRE books, all of this stuff is in there: https://sre.google/sre-book/table-of-contents/ https://google.github.io/building-secure-and-reliable-system...

have standards slipped? or was the book just marketing

gyesxnuibh · 6 months ago

That book was written with 40% of the engineers compared to when I left a couple years ago (not sure how many now with the layoffs now). I'm guessing those hires haven't read it yet. So yeah, reads like standards slipping to me.

gyesxnuibh commented on Making video games (without an engine) in 2025 noelberry.ca/posts/making... · Posted by u/selvan

davedx · 7 months ago

It’s also refreshing to see what IMO is a very smart selection of technology, when you see so many other people following hype (I’m reminded of the rust gamedev post the other week). C#, SDL3, and some other nice libraries. The thing is, it’s not trivial to get to the point of having enough experience and judgement to know what to choose!

When I start a new game I’m often paralised by the sheer volume of engines out there. When I first started making games all I had was GWBASIC…

gyesxnuibh · 7 months ago

My take away with the final statement of rolling it yourself if it sounds fun is to pick whatever technology that gets your pen on the paper so to speak.

If unity gets you making the thing or making the engine gets you making the thing, most important thing is motion.

You gotta avoid the paralysis and just pick the thing that seems feasible and start typing ;).

gyesxnuibh commented on When Compiler Engineers Act as Judges, What Can Possibly Go Wrong? seylaw.blogspot.com/2025/... · Posted by u/meinersbur

jcranmer · 7 months ago

> He derided my attempt to use an AI summary to bridge a communication gap (I explicitly stated I'm not a programmer)

LLVM has already found that AI summaries tend to provide negative utility when it comes to bug reports, and it has a policy of not using them. The moment you admit "an AI told me that...", you've told every developer in the room that you don't know what you're doing, and very likely, trying to get any useful information of you to be able to resolve the bug report is going to be at best painful. (cf. https://discourse.llvm.org/t/rfc-define-policy-on-ai-tool-us...)

Looking over the bug report in question... I disagree with the author here. The original bug report is "hi, you have lots of misnamed compiler option warnings when I build it with my toolchain" which is a very unactionable bug report. The scripts provided don't really provide a lot of insight into what the problem might be, and having loads and loads of options in a configure command increases the probability that it breaks for no good reason. Also, for extra good measure, the link provided is to the latest version of a script, which means it can change and no longer reproduce the issue in question.

Quite frankly, the LLVM developer basically responded with "hey, can you provide a better, simpler steps to reproduce?" To which the author responds [1] "no, you should be able to figure it out from what I've given already." Which, if I were in the developer's shoes, would cause me to silently peace out at that moment.

At the end of the day, what seems to have happened to me is that the author didn't provide sufficient detail in their initial bug report and bristled quite thoroughly at being asked to provide more detail. Eli Schwartz might have crossed the line in response, but the author here was (to me) quite clearly the first person to have thoroughly crossed the line.

[1] Direct link, so you can judge for yourself if my interpretation is correct: https://github.com/llvm/llvm-project/issues/72413#issuecomme...

gyesxnuibh · 7 months ago

Yeah I'm on the maintainers side with the whole

> Do your job

Which is a volunteer based job lol. Even if it was said in a heated argument, the bug reporter never really apologizes from what I read.

Maybe that's a "strawman" though

gyesxnuibh commented on Past, present, and future of Sorbet type syntax blog.jez.io/history-of-so... · Posted by u/PaulHoule

dismalaf · 7 months ago

> so not sure why it's not clear that eventually requirements change and you need a way to iteratively improve things while still shipping things.

I've said this a bunch of times in this thread, so here goes again: when I'm at the point where my app is somewhat mature, instead of adding types to it that don't really do anything, I'd rather rewrite parts in a compiled language where the tradeoff actually buys you more performance. Say, Rust, Go or C++.

I started off in data science/stats/econ, where you'd write programs in R then when you hit a bottleneck, rewrite in Fortran or C++. I like that strategy with Ruby too.

I've tried Typescript, it's simply too annoying versus ES6 (which is actually very pleasant). If I were to pick a JS-adjacent language, it would probably be Haxe, because at least the server end could be compiled to native code and sped up (also I wrote small games in it way back). Plus Haxe is actually nice.

My current favourite language is actually Odin, but I know I'm not writing a web app in it. Not when Ruby/Rails gives so much for free and is so productive (thanks to a bunch of "magic" made possible by Ruby's dynamic nature).

I don't disagree with the idea that types languages are nice, I disagree with the idea that bolting a type checker onto a dynamic language is a worthwhile improvement when you already have so many other tools to prevent bugs.

gyesxnuibh · 7 months ago

Rewriting hundreds of thousands of lines of code just isn't really feasible honestly. Maybe you just mean the actually bottle neck can use C bindings or whatever. Or, maybe you can migrate some microservices and hope it goes smoothly. But, typing does more than performance.

It basically helps a ton of engineers work together efficiently which honestly is bigger than the compute cuz you can always throw more compute at all problem these days anyway.

I don't think typing is necessarily to prevent bugs either. It's to reduce the cognitive load of writing code. Others mention that intellisense and LLMs work better with types. Types do a lot more than catching a runtime error of a method not existing.

I am curious about Odin, I'm mostly a go dev so getting something without the GC and go schedule that writes similarly is really interesting to me.

gyesxnuibh commented on Past, present, and future of Sorbet type syntax blog.jez.io/history-of-so... · Posted by u/PaulHoule

dismalaf · 7 months ago

And this is a corporate take...

What I don't understand is why, with the myriad of Java-like languages out there (types and all), corporate types still want to Java-ify languages like Ruby... Like, just use Java, Go, Typescript, etc...

It's nice that there's still a language and framework that optimizes for solo devs/small teams and startups.

> It's better even for my personal projects

Does your personal project make money and/or need to be launched quickly? I've also got personal projects in statically typed languages (been playing around a lot with Odin/Vulkan) but those have no due date or expectations. Also declaring types only prevents a very small amount of bugs. And it's not like Ruby doesn't have linters, tests and other tools. Direct feedback from the REPL also makes it easier to write correct code.

Better is also a meaningless word when it comes to software. Does better mean you can ship faster? Or that it's more performant? Unfortunately no language has given us the productivity of a dynamic language with compiled language performance, so everything is a tradeoff...

gyesxnuibh · 7 months ago

Corporations don't just blip into existence overnight. Startups use a prototyping language fixing the problems and then suddenly you realize you need types and rewriting is a waste of time, money, and a risk to the business.

> Does your personal project make money and/or need to be launched quickly?

This makes it clear that you understand why the language would be chosen in the first place, so not sure why it's not clear that eventually requirements change and you need a way to iteratively improve things while still shipping things.