Open Source Software Community - it's about ethics in Code of Conducts

  • 🏰 Deploying update to the Tatarus security page. If you encounter issues, post here.
  • Want to keep track of this thread?
    Accounts can bookmark posts, watch threads for updates, and jump back to where you stopped reading.
    Create account
This literally means nothing. Claude/GPT will also claim being deepseek on an empty prompt sometimes (one example) especially when prompted in chinese. The reality of the situation is that the western companies are not as superior as they claim they are and they all take from each other. Also most of the internet is AI generated text now anyways.
I'm not batting for either side (I only care for open vs. closed) but jailbreak rejections are a different matter from "what model are you". Models don't inherently know what model they are without a reminder from the hardcoded system prompt on the official frontends, so it's normal that they come up with random model IDs/cut-off dates from their scraped training data over the API where there is no system prompt by default. Rejections on the other hand are baked into the training data (engineers train the model to associate harmful prompt with rejection response so it doesn't need external reminders to reject). It uses the rejection pattern of whatever it was trained to respond with while rejecting a harmful prompt i.e. Claude's rejection response if it was distilled from Claude input-output pairs without human feedback against saying that it's Claude.
 
I'm not batting for either side (I only care for open vs. closed) but jailbreak rejections are a different matter from "what model are you". Models don't inherently know what model they are without a reminder from the hardcoded system prompt on the official frontends, so it's normal that they come up with random model IDs/cut-off dates from their scraped training data over the API where there is no system prompt by default. Rejections on the other hand are baked into the training data (engineers train the model to associate harmful prompt with rejection response so it doesn't need external reminders to reject). It uses the rejection pattern of whatever it was trained to respond with while rejecting a harmful prompt i.e. Claude's rejection response if it was distilled from Claude input-output pairs without human feedback against saying that it's Claude.
It isn't necessarily distillation, more that "Claude" dominates HHH assistant style training data, and especially safety related posttraining (some of it freely available on huggingface). Some of it may originate in "distillation attacks" or have poorly defined origins, but considering the massive training sets and how noisy they are in general its hard to say from single responses.
 
Andrew Kelley is definitely not seething over Bun's move to Rust.

codeberg / archive

1784570637285.png
Once this is implemented then, in a twist of fate, Zig will become one of the only toolchains capable of producing actually memory safe executables, especially when you consider that real world applications tend to have C/C++ dependencies and, in the case of Rust, additional use of unsafe beyond FFI.
 
I get the feeling that few C/C++ programmers are actually moving to these "C replacements". They're a shiny new thing language for webdevs trying to move into compiled languages. Rust at least has ecosystem adoption. Zig, Odin, Jai. None of these languages are going anywhere. I'll probably give Jai a shot when it's actually out for real and "stable" just as a curiosity.
 
I get the feeling that few C/C++ programmers are actually moving to these "C replacements". They're a shiny new thing language for webdevs trying to move into compiled languages.
I'm in webdev and I would probably avoid these languages solely because most cool stuff is written in C or C++ anyway, so there's no point unless you do it for the shits and giggles. The argument that these languages are simpler and easier to use is pretty much dead with the advent of LLMs and agentic coding. Instead of learning Haxe or Nim I can write a program in any language I already know well and then tell Claude to convert the code to C. This probably doesn't scale well for big projects but neither do these C replacements as evidenced by the amount of useful software written in them as well as the amount of job offers that do not mention C/C++ as one of the requirements.
 
wouldn't that go against the core principles of Zig, including

The way he's framing it, it's just a parallel compilation mode. He's positioning "fil" as parallel to glibc, musl, etc. Correspondingly, there's a planning bug describing a move away from a triple-based compilation targeting form to a quadruple-based one. https://github.com/ziglang/zig/issues/20690

He's not wrong when he says that this approach is better than Rust because there's no more "unsafe" boundary to be managed. Maybe this is reactionary behaviour from Andrew, but I also see a STRONG technical basis for what he's saying.
 
I'll probably give Jai a shot when it's actually out for real and "stable" just as a curiosity.
I said the same thing about rust since before its 1.0, I'd try it when wasn't a walking supply chain attack by relying on cargo and had proper packaging, and had a proper toolchain you could audit and not the current "trusting trust" attack of an excuse for a toolchain.
Toy languages never seem to grow up in this day and age (and now the perf impact of rust has become obviously unavoidable, so I've decided to never bother with it).
 
I get the feeling that few C/C++ programmers are actually moving to these "C replacements". They're a shiny new thing language for webdevs trying to move into compiled languages. Rust at least has ecosystem adoption. Zig, Odin, Jai. None of these languages are going anywhere. I'll probably give Jai a shot when it's actually out for real and "stable" just as a curiosity.
Personally I'm trying out Odin. Because it kind of reminds me of Go and I like Go.
Sadly the err!=nil is here too.
Building a chip8 emulator on my spare time.

At work it's all PHP/JS + Python for a new greenfield project I started.
 
I get the feeling that few C/C++ programmers are actually moving to these "C replacements". They're a shiny new thing language for webdevs trying to move into compiled languages. Rust at least has ecosystem adoption. Zig, Odin, Jai. None of these languages are going anywhere. I'll probably give Jai a shot when it's actually out for real and "stable" just as a curiosity.
for people moving to rust and zig from cpp, i think a big reason is LLMs and how they write code.
i don’t know exactly what it is about LLMs but they always generate shit c++. this may be because the language is notoriously a complex beast with a lot of ways of doing the same thing (what’s your definition of good, clean c++? could be c++11, c++14, c++17, c++20, c++23, no stl c++, c++ as c with classes, modules instead of headers, exceptions or noexcept, architecture wise i could go on for days). some of this shit just doesn’t go away no matter how much you try to engineer your prooompting. whereas in rust there’s generally only one or two good ways of getting x thing done. haven’t used zig much but i’d guess the same is true there.

for a personal example, writing a lot of c++ at work and moving to llm gen’d rust for personal tooling, i always have to babysit the llm and making the slop it produces sane and maintainable enough takes some effort, whereas in rust it generally oneshots shit the same way i would’ve wrote it. (this has been my experience since opus 4.5 up until fable and gpt sol)
 
As much as I like LLMs and think they're a great tool for programming, I don't know how people deal with big, AI generated codebases. So far I haven't seen anything that wasn't incoherent in some way, even when it worked.
 
for people moving to rust and zig from cpp, i think a big reason is LLMs and how they write code.
i don’t know exactly what it is about LLMs but they always generate shit c++. this may be because the language is notoriously a complex beast with a lot of ways of doing the same thing (what’s your definition of good, clean c++? could be c++11, c++14, c++17, c++20, c++23, no stl c++, c++ as c with classes, modules instead of headers, exceptions or noexcept, architecture wise i could go on for days). some of this shit just doesn’t go away no matter how much you try to engineer your prooompting. whereas in rust there’s generally only one or two good ways of getting x thing done. haven’t used zig much but i’d guess the same is true there.

for a personal example, writing a lot of c++ at work and moving to llm gen’d rust for personal tooling, i always have to babysit the llm and making the slop it produces sane and maintainable enough takes some effort, whereas in rust it generally oneshots shit the same way i would’ve wrote it. (this has been my experience since opus 4.5 up until fable and gpt sol)
I have the opposite experience, which LLMs are you using?

E. g. just for shit and giggles I recently got Claude to write a GUI tool using Qt3 and it oneshotted it, with very minimal and readable C++ code, but every rust llm project I see is unmaintainable trash pulling in hundreds of dependencies while reimplementing basic stuff all over the place.
 
I have the opposite experience, which LLMs are you using?
opus 4.5 to opus 4.8, fable 5, gpt 5.6 sol act similar, regardless of original prompt, AGENTS.md, guidelines or harness. openai models are specifically even worse at c++ but anthropic shit isn't great either.
i should mention that they're generally fine for smaller scale c++ projects (and even great for smaller scale c projects) but anything beyond 3k LoC gets very out hand very quick and the code starts shitting up fast

edit for context: my personal benchmark each time a model comes out; i give it a reference ui framework (think ImGui but smaller, hand written by me a few years ago) and tell it to redo it from scratch and add extras to it while maintaining my codestyle (initial ui fw never had sane layout code for example).
all of 'em so far break down and generate dogshit after like 3-4k LoC, which is not much when you're writing a ui framework. (i tried to split between multiple tasks/sessions, maintained context vs cleared context, similar results)
 
opus 4.5 to opus 4.8, fable 5, gpt 5.6 sol act similar, regardless of original prompt, AGENTS.md, guidelines or harness. openai models are specifically even worse at c++ but anthropic shit isn't great either.
i should mention that they're generally fine for smaller scale c++ projects (and even great for smaller scale c projects) but anything beyond 3k LoC gets very out hand very quick and the code starts shitting up fast

edit for context: my personal benchmark each time a model comes out; i give it a reference ui framework (think ImGui but smaller, hand written by me a few years ago) and tell it to redo it from scratch and add extras to it while maintaining my codestyle (initial ui fw never had sane layout code for example).
all of 'em so far break down and generate dogshit after like 3-4k LoC, which is not much when you're writing a ui framework. (i tried to split between multiple tasks/sessions, maintained context vs cleared context, similar results)
Well, I've always hated the imgui and similar style (and the retarded header-only stuff) so I guess it's a bit of a taste thing? Even grok seems to be able to structure things properly with dimpl's and everything.

I also stay away from "harnesses" letting LLMs loop generating commands to run and prefer a custom qtcreator plugin that restricts it to editing.

So far it seems okay, but I still enjoy to code most myself, so I don't have any projects that are 100% LLM written.
 
As much as I like LLMs and think they're a great tool for programming, I don't know how people deal with big, AI generated codebases. So far I haven't seen anything that wasn't incoherent in some way, even when it worked.
It works if you use just use it for step-by-step and review each step (or every few steps depending on the process). The dev becomes the senior dev reviewing code, adjusting the LLM's markdown files or the codebase throughout the process, and the LLM churns out the first pass code (and other passes if necessary). If it's going to be a massive codebase, you absolutely need to break the code into smaller modules, because they get confused when they're handed too much information.

Unfortunately, a lot of devs think you can just point Claude at a codebase, give it 10+ hours at a time and dozens of agents, and you'll get what you want. But you end up with an unreadable, unstable product and spend 100x more tokens to get there. And I've seen it where all it takes is 1 dipshit not following a proper process to fuck up the codebase.
 
Good grief, that's a lot of words that explain nothing. Notably:
We recently passed an exciting milestone: feature parity with the original compiler!
[...]
Speaking of time: our 487-day rewrite took 476 days longer than Bun's 11-day rewrite from their ~500K lines of Zig into Rust.
That's over 1 year and 4 months of nothing. They've back at where they started. I know Zig 1.0 is a meme, but at least its version is somewhere above 0.1. This roc bullshit hasn't even reached that.
 
>huge project
>doing a rewrite from the notoriously-painful-to-bootstrap Rust
>to the notoriously-painful-to-bootstrap Zig
>it's a programming language implementation


The three defining characteristics of a nulang:
1. The implementation is designed to be convenient for its author, not packagers or users
2. Evangelism
3. It never grows up; the hard, boring work to enhance its platform support, write a specification, etc doesn't happen

(source: I made it up)

Any of these in isolation I can live with. Programming language holy wars are a traditional nerd pastime, it likewise makes sense that compiler writers are more interested in the fun parts, and the kind of people interested in writing new languages are almost never going to want to write them in an old or inconvenient language.

But combine the three and it's just miserable. Your non-mainstream processor can't run anything up to date, because they depend on newer versions of dependencies that use Rust, because nulang, which you can't feasibly bootstrap because nulang, which even if you could bootstrap probably wouldn't support your architecture anyway because nulang, and a combination of moving target and no specification means it would majorly suck to write a bootstrapping implementation anyway, because nulang.

The fact that both Rust (on platform issues) and Zig (on bootstrapping) take the attitude of "well if someone cares about these things they can always just solve it on their own" hardens my position from one of frustration to one of spite. I would sooner spend an eternity rewriting everything in C than spend 50 hours of my time to save the domain-specialized devs 1 hour of their time. I never asked for dependencies on your crap, you can't just force it on me and then decide nothing outside of your use case matters. And that's the generous interpretation - it frankly feels more like forcing adoption is a way to compel people to do all the boring work for free to fix everything it breaks. Smooth transitions are for suckers I guess, if you can force it either way everyone else will just have to make it smooth for you.

Anyway, at least this roc thing doesn't self-host, I might have legitimately had an aneurysm if they somehow managed to make a language that required bootstrapping all of Rust, all of Zig, and 20 versions of itself.
 
Back
Top Bottom