Your comment came at a right moment, right after my lecture in ontology yesterday where the proffesor presented the inverted casuality of a controller feedback loop as an example of a 2 types of causes described by aristotle that are lost in modern materialistic thinking, the formal cause and the final cause.
Great examples with the tea and the opamp for how a final cause be in the "future" of the effect, I'll remember them for the exam :)
Yet I think of electrical engineering as the epitome of modern materialism, however mystical the jargon about imaginary current phasors and complex permittivity may seem to the uninitiated. Electrical engineers think of electrical fields as material things that exist in the universe and follow probabilistic but all-encompassing laws, not as supernatural spiritual entities. Could your professor be wrong?
He wasn't saying that the engineers believe that in ontological sense. Rather he was presenting the difference in how we usually think about complex systems (i.e. the thermostat "wants" to keep a stable temperature). We abstract away the materialism we believe in because it's not practical and in a way we come back to the causes that aristotle wrote about, just metodologically not ontologically.
With vibe coding, one could even say that you can believe in the computer's intent to write the code and the code working through that intent. You might not even know how the code looks after all.
Modern materialistic thinking is causally downstream from the erasure from language of the distinction between the 2 types of causes -- as exemplified by the following buffonade:
Arlecchino: does something stupid
Pierrot: smacks Arlecchino across the back of the head
Arlecchino: Ow! What for?
Pierrot: Not "what for", but "why", dumbass.
(Been a bacterium btw. Strong emotions all around, as there's nothing to temper them with. Do not recommend. An opamp is nicer - as long as they make sure to keep you within operating parameters, and not put you in a configuration experiencing infinite positive feedback, lmao)
Honestly I am not surprised. I imagine he wrote it quickly as this fun quirky look at the universe but then it got extremely popular, kurzgesatz video released and all. A lot of people based their personal beliefs off of the story.
Imagine you write a small story for fun but then it becomes nearly a religion. It must be a little frustrating for Andy.
Which is strange, because unlike his other works, this one actually has something a reader can introspect about instead of, you know, just reading "efficacy porn".
But rust absolutely does not have any C/C++ compatibilty besides arguably very good FFI. And that's where zig shines. They have a c/c++ compiler built into the zig compiler via zig cc, that's even easier to use than clang or GCC due to having the benefits of a buildscript and baked in libcs for different architectures, making crosscompilation a breeze.
In zig you _can_ actually start with a c codebase and rewrite it file by file in zig and you _can_ include c headers in your zig files verbatim. Both of these are not possible in rust.
This milestone is only gonna remove the c++ (and objective c/c++) compiler for now from zig cc. So while you could argue this will ostracize people rewriting their c++ codebases in zig, I don't imagine there's actually many people like that.
EDIT: I just looked at the discussion and there's actually a lot of people that use the c++ capapbilities.
> In zig you _can_ actually start with a c codebase and rewrite it file by file in zig and you _can_ include c headers in your zig files verbatim. Both of these are not possible in rust.
well, you can: i have done this, with Rust. but yes, it’s more the type of thing that well-resourced companies do rather than solo devs, because even with Bindgen and the like Rust really wants the atomic codegen unit to be the “library”, not C’s notion of a “compilation unit”. still, C FFI compatibility is exactly why porting from C to rust incrementally is feasible while C to, say Java, is probably a bigger leap.
You still need a separate compiler toolchain next to Rust in order to compile the C, C++ and ObjC dependencies which is a massive build system headache (especially across UNIX-oids and Windows).
In Zig that all "just works" with the standard Zig install.
(here's how the sokol headers are integrated into a Zig project, note that there is only a build.zig which builds everything: https://github.com/floooh/kc85.zig)
But it's not so much about build systems, but requiring a separate compiler toolchain to build any C++ or ObjC dependencies (Rust needs this, Zig currently does not - unless that controversial proposal is implemented).
(also even complex C++ libraries can be wrapped in a build.zig, so you don't require a separate build system like cmake for the C++ dependencies)
I still don't see why this is a problem. Single-header dependencies are cute but blow up compile times, and most of the world needs CMake/Meson/Autotools anyways so there's not an added cost to using it for your own projects.
Similarly I don't really understand why you want one toolchain for a multi-language project. It's not that useful or convenient since it's going to need to be orchestrated with a buildsystem somehow.
Like with Rust, you probably only have a build.rs file. It invokes a separate (possibly multiple) toolchains. Or with CMake. A simple project has a single CMakeLists.txt that can invoke any number of toolchains. I don't see why zig can't do that with a build.zig file, or why it matters.
> But rust absolutely does not have any C/C++ compatibilty besides [..]
> In zig you _can_ actually start with a c codebase and rewrite it file by file in zig and you _can_ include c headers in your zig files verbatim. Both of these are not possible in rust.
You can. Either via FFI and bindgen-ing headers, or by using c2rust. The latter is not just a toy ambitious project, but actually a very impressive piece of engineering and does produce a result where you can transpile a project or file and start rewriting file-by-file or function-by-function.
c2rust is definitely cool, but it also supports transpiling to a single architecture, which often misses a lot of architecture dependent code and specialisations in real world c code. Especially because it has to do macro expansion and you only get the expanded code.
It also doesn't supportal a good amount of more complicated c features.
It's a help for sure, but the few times I tried I ended up just doing the rewrite by hand instead to actually cover all the cases.
I've tried glider for some time but it had a very unpleasant tendency to freeze my phone completely. I've since switched to Hacki which is really responsive and has similar swipe controls.
You got me. I was too lazy to implement the return stack. But it should be fully possible. The hardest part was not implementing things in the trait system, but parsing any non-trivial syntax using the clunky macro_rules!. For this reason if/else/then are not a special syntax but words that block and unblock subsequent word execution.
The trait system and macros run at compile time and sadly there is no way to interact with the Rust compiler. However the macro is fully incremental (creating new words too). Which means in theory if it were possible to ask for input and pass it to the macro it would behave more like a VM:
// create a word
forth!(: inc 1 + ;);
// ask user for $input
type Stack = forth!($input inc return);
// if you keep the stack around it can be used again
forth!({ Stack } inc .);
// should print $input + 2
Beautiful. With such advances on the frontier of Trait exploitation, soon most of the Rust language will become obsolete and everything will be evaluated on compile-time! It is the ultimate optimization. Just embed the most expected output values in the binary and run time calculation becomes redundant.
Wow, that got out of hand quickly. Like in a matter of minutes.
At first I was thinking, "Oh, neat. A browser I know nothing about. Maybe I'll give it a try."
After reading how multiple Pale Moon people acted in that thread, I'll pass. I've worked with people like that in the past, and I don't want to support them in any way, or validate their work.
Wow, those guys sure know how to not make friends. Last I checked choice of bundled or system libraries is normally reserved for distro packagers, and one would really hope the system libs win out wherever possible!
