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?
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.
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.
Does Rust’s memory safety design improve memory safety? Yes, this is proven by experience (e.g. see Google’s blog posts).
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.
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:
Portability: It means you can change your hardware target and you only have to worry about re-certifying this, instead of an entire compiler.
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.
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.
Basic human decency, hopefully.
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.
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.
Freaking finally. (Well when it’s actually released anyway.) Kind of crazy how long this super obvious feature has been ignored by all the forges. (Except Tangled, but that has other issues.)
Also this is going to be a big differentiator compared to Gitlab or Forgejo.
See my other comment.
It wasn’t meant to be comparable. It was meant to be a simple counter example to disprove “free => no obligations”.
Wow. I wonder why nobody saw this before then? Op’s code doesn’t look unusual.
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”.