All it takes is one internet search with the words “zig style guide” to find countless examples to pull from online.

“Countless”? You should be able to find, say three style guides that talk about how to prevent memory errors then right? Because my one search didn’t find any.

Well it seems a bit hollow for the Zig developers to say “there’s no problem - just use a style guide!” when they themselves don’t even use one and the only one they can point to just says “never dynamically allocate”.

To be honest I don’t see how a “style guide” is going to help. C++ has had all sorts of guidelines and style guides for decades and it helps a bit but… not really.

What does the Zig compiler’s own style guide say about avoiding memory errors? As far as I can see nothing?

Bun didn’t even try one

Is this style guide not a style guide?

Maybe in the 90s when Bill Gates was running the show. These days they’re mid tier evil. Barely even maintaining a monopoly.

If it was Oracle, or Broadcom, or Meta then sure, but Microsoft aren’t in their league any more.

It’s definitely better than C but I’m still unsold on the memory unsafety. Especially after the supposed answer to Bun’s memory bugs was “just never dynamically allocate”.

comptime is definitely neat and there are some other nice features but tbh it seems like the only true advantage it has over Rust is compile time, and only for incremental compilation. Is that enough? I would say probably not.

GitHub. You’re hosting public stuff so there’s no more risk of your data being sold on GitHub than anywhere else public. GitHub is what recruiters understand and expect.

I’ll get downvoted by extremists but this is the best option if you want a job and aren’t also an extremist.

I would consider Codeberg or maybe even Tangled for actual projects you’re working on, but for just showing stuff of there’s no advantage to not using GitHub.

Not exactly. It means that any of the code could lead to memory unsafety, but it’s still better than Zig or C because you still only have to read 5% of the code to debug/fix those issues, instead of 100%.

5% is clearly better than 100%. Whatever else you think about this port you can’t argue against that. In fact I can prove that it’s better.

1. Does Rust’s memory safety design improve memory safety? Yes, this is proven by experience (e.g. see Google’s blog posts).

2. Does “normal” (not slop) Rust code rely on some unsafe? Yes. All Rust code must use some unsafe because it’s used in the standard library, and even if you ignore that (there is an effort led by Amazon to formally verify it), it’s usual for Rust projects to use at least some unsafe. Let’s say 0.1% of lines.

3. So 0.1% unsafe is clearly better than 100%. Is it possible for 0.1% unsafe to be better than 100%, but somehow 5% isn’t? That would require things to be non-monotonic which is completely implausible.

Sure, but only 5% of the Rust code is unsafe, which is clearly an improvement. And their plan is to reduce that amount over time.

I’m no fan of AI slop but that point isn’t an issue.

He doesn’t appear to be using any features of Lisp that made it “the language of (70s) AI”. You could do all of this just as easily in many other languages.

His prof was still wrong.

I can think of a few potential advantages:

1. Portability: It means you can change your hardware target and you only have to worry about re-certifying this, instead of an entire compiler.

2. Testing: You can probably run your WASM code fully deterministically in a deterministic simulation much easier than native code. Also when developing you don’t need the actual hardware.

3. Isolation / compartmentalisation. If I were them I would be strongly considering using the WASM component model (in future).

It would be good if they put their actual motivation in the readme though.

It doesn’t mean you made the wrong decision. Changing the names has a potential cost - you break something (this is especially risky for environment variables which have insanely global scope, no static type checking, etc.).

Not changing the names has a potential cost too - causing confusion in future, wasted time, or even bugs due to the increased chance of mistakes.

I’m currently leaving a company where they almost never clean up their messes. Tons of old unused code is just left in the repo. Causes huge wastes of time.

Don’t underestimate the potential cost of not keeping things orderly. There was a famous case (Knight Capital) caused by not cleaning up an old unused CLI flag and it cost them $440m and destroyed the company.

It definitely is capable of it now, if you put some effort into guiding it, and you’re working in a popular domain/language. It couldn’t really do it a year ago though so you might just be a bit out of date.

This doesn’t explain why you’d want to use Lisp at all really, and it pretty much ignores the many disadvantages.

Yeah also people get into a mess and don’t understand the state of the repo. Like they’re organising files without ever running ls. If you ask these CLI fanatics for the solution they’ll say “you don’t need a GUI, just run git log --tree --oneline --decorate --all”… which is just a poor man’s GUI.

To be fair the days when a game was “released” and that was that are also pretty much long gone. Big studios now rely on being able to patch bugs after release.

Well I disagree. If you create a popular project, and then are a complete dick about reasonable requests, then that seems like an immoral thing to do to me.

Of course you’re allowed to say “sorry I don’t have time to work on this any more”, or “I don’t think this feature belongs in this project” or whatever. Totally fine. But there are still behaviours that IMO are not ok. For example if Homebrew decided to inject donation request code into every package it installs. Or if ffmpeg added code that detected porn and refused to decode it.

“BuT iTs FrEe! They can legally do what they like!” Sure, but it still makes them a dick.

That’s a lot of words. I think the reasons are pretty simple:

1. Some people just don’t care.
2. The Git CLI is poorly designed e.g. the many different ways to delete something.
3. Some Git concepts are very poorly named, e.g. the “index”, “ours/theirs”. This adds to the confusion.
4. There are many Git GUIs but only a very small number of actually decent ones (if you’re wondering: GitX, SourceGit, Git Extensions, and the Git Graph VSCode extension).
5. There are a lot of idiots out there telling people not to use Git GUIs, when they are clearly the best way to learn how to use Git. Its easy to get into a mess if you can’t see what you’re doing.
6. Git isn’t actually as simple as us pros would like to think. The underlying model and even the implementation isn’t too complex (I’ve written a Git client form scratch; not too hard apart from the lack of specs/docs). But you can easily get into a state where you’re pulling from a remote and someone else has pushed to the same branch so you need to resolve that (oh btw don’t do what Git tells you to!), and maybe it involves submodules too, and you basically need to fully understand Git’s model and be pretty good at the awful CLI too to resolve it.

What arbitrary line of popularity suddenly requires me to support every use-case, by never breaking something in a project nobody is paying me to build?

Not what I said at all.

FOSS maintainers owe you NOTHING. Nada. Zip.

Oh so it’s either “nothing. Nada. Zip.” or “support every use-case”. Nice false dichotomy you’ve got there.

I disagree. If you make a project, put it out there for.people to use, and it becomes popular, you have some moral obligation not to dick over people who have come to depend on you. I’m not saying you have a moral obligation to e.g. provide free support forever or work weekends or whatever.

You can think otherwise but IMO that makes you a bit of a dick.

I said morally, not legally.