If you asked a three-year-old a question that they proceeded to completely flub, would you then assume that all humans are incapable of answering questions correctly?

Nobody is arguing for the quality of the search overviews. The models that impress us are several orders of magnitude larger in scale, and are capable of doing things like assisting preeminent computer scientists (the topic of discussion) and mathematicians (https://github.com/teorth/erdosproblems/wiki/AI-contribution...).

I'm a Rust main, but this argument seems... incorrect? You would not need macros for Rust to remain a usable memory-safe language. They certainly make it easier, but they're not necessary. It would be perfectly possible to design a variant of Rust that gets you to 80-90% of Rust's usability, with the same safety, without macros.

Regular variable definition shadows. Macros expand to regular Rust code, they could always be replaced by the expanded body.

yes, but the code inside is unsafe. the pin macro is like a safe function.

I'm not sure what that has to do with anything. The macro isn't what makes it safe. The unsafe code being properly written is.

but without macros, how would you expose a safe interface?

  fn pin(x: T) -> Pin<&mut T> { ... }

would move the value

Your macroless variant of Rust would offer a safe builtin that does this. It doesn't need to be implemented with a macro.

Since macros just expand into code, how could you imagine that a macro is ever necessary?

the macro uses unsafe inside, so that's another instance of unsafe you'll need to check, whereas the pin macro is like a safe function

Excellent goalpost moving! Congratulations!

no, you just missed my point. expanding the implementation is not a safe abstraction. show me how you'd implement the functionality of the pin macro as a safe abstraction.

I didn't miss that you totally changed the subject and now you're attacking a strawman. See Steve Klabnick's response to your other comment where you did this. Of course macros are good for encapsulation and abstraction, but that's a different subject--and note that the discussion was about Zig vs. Rust, and Zig has no macros so there's unencapsulated unsafe code all over the place.

I won't respond further.

i was responding this claim

> It would be perfectly possible to design a variant of Rust that gets you to 80-90% of Rust's usability, with the same safety, without macros.

i then present an api that i think relies on macros to expose a safe api

> Of course macros are good for encapsulation and abstraction, but that's a different subject.

no it's not. exposing safe abstractions is pretty much rust's raison d'être

everything in zig is unsafe and needs to be checked like rust unsafe, so…

It is presented as a Wikipedia article from the future describing a subculture of tomorrow. See also https://qntm.org/mmacevedo for another example of this genre.

Functionality-wise, it's great, but it's a buggy mess, and it seems to be getting worse with each release.

I've been using deletated Claude agents in vscode and it crashes so much it's insane... I switched to copilot Claude local agents and it works much better.

Idk about this whole vibe coding thing though... Well see what happens

I’m a heavy user for about four months now, and it’s definitely getting better for me. How would you say it’s getting worse?

The human operator controls what gets built. If they want to build Redis 2, they can specify it and have it built. If you can't take my word for it, take those of the creator of Redis: https://antirez.com/news/159

I wish some taste had been used in the choice of font. Courier New is rather unpleasant to look at for prose.

Or any monospace font, really.

Interesting claim; have anything to back it up with?

I can recommend Ed Zitron's latest on Anthropic.

That is probably Composer-1, which is their in-house model (in so much a fine-tune of an open-weights model can be called in-house). It's competent at grunt work, but it doesn't compare to the best of Claude and Codex; give those a shot sometime.

The type system does not require that. You can just discard the result:

  let _ = do_thing();

Except that doesn’t work if you need to use the result…

At the risk of being that guy, I haven't had any issues onboarding people onto native projects written in Rust. rustup does a great job of fetching the required toolchains without issue. I'd imagine the same is also true of Go or Zig.

While Microsoft <3 Rust, there are still some quality tooling parity to reach versus Visual Studio abilities for .NET, Python and C++.

Incremental compilation, and linking, parallel builds, hot code reloading, REPL, graphical debugging optimised builds, GPU debugging....

Go is better left for devops stuff like Docker and Kubernetes, and Zig remains to be seen when it becomes industry relevant beyond HN and Reddit forums.

I'm pretty people who write and build C++ on Windows do it for good reasons, often reasons that are out of their control. Your comment is not going to make any difference.

Before rustup can run, the very first message rustup-init spits out is asking to install the visual studio tool chain.

You have to do this for certain rust things too. I can't remember which, but I inevitably run into a need to install the MSVC toolchain to compile rust. I think it might be related to FFI, or libs which use FFI? The same thing comes up in Linux, but the process to install it is different.

I got anxiety reading the article, describing exactly why it sucks. It's nice to know from the article and comments here there are ways around it, but the way I have been doing it was the "hope I check the right checkboxes and wait a few hours" plan. There is usually one "super checkbox" that will do the right things.

I have to do this once per OS [re]install generally.

It makes use of MSVC linking infrastructure, and import libraries.

You can't really use Rust in the real world without interfacing a lot of C/C++ libraries, so yes this is still relevant.