wow, somehow you jumped to some next level conspiracy garbage more extravagant than the rest of the comments. 20 million people participating in protests was not a “state sponsored attack”
These troll farms exploited genuine grievances in order to stoke as much chaos as possible.
I'm not trying to say this was the main cause, my comment "wokeness was state sponsored attack" was rhetorical in nature. While a state sponsored attack did happen (see above links...) it isn't the main explanation.
I was excited for Accelerator. All of the projects from last year[1] actually looked useful or I was already using them (htmx, dioxus, nuxt, datasette, trpc, strawberryql). Now it is a bunch of garbage LLM tools I will never use. Even their front page[2] looks infinitely worse than I remember and only says "Powering AI Advancements in the open." RIP GitHub Accelerator.
EDIT: they really did make the front page much worse[3]. The words on the original page actually sound like they were written by a human. No mention of uplifting the open source ecosystem anymore, not even pictures of OSS maintainers.
This post is rather unrelated. The linalg dialect can be lowered to LLVM IR, SPIR-V, or you could write your own pass to lower it to e.g. your custom chip.
This comment finally pushed me to try out Kagi and WOW. I did not realize how much I was missing out from a search engine - pinning & blocking websites on my search???? It seems so obvious now, but damn is that incredible.
Have any examples of syntax you find tasteless? Things in Zig that feel ergonomic to me: comptime params > separate generic args; ptr.* > *ptr; optional pointers > possibly null normal pointers; separate syntax for slices, arrays, & pointers > 1 syntax for ptr & arrays.
This for example doesn't work, you have to capture, many little things like that that stacks up and ends up creating a non-ergonomic syntax
No for loop, so you have to do multilines things like, and now you meet a new : construct, this pseudo for loop now looks confusing to look at
var i: i32 = 0;
while (i < 42) : (i+=1) {
}
Then constant casting between integers, and also floats.. also no operator overload for the math types etc..
Also not a fan of the pointer difference between [] * [:0], too much different nitpicking that makes iterating slow and painful, I understand the benefits, but the way it's done is not enjoyable, at least to me
That's just whats on the top of my head, it's been a while I haven't wrote Zig code so I may be remembering wrong
... wat? imperative; compiled to machine code, either static exe or dynamic libs; builtin RAII & polymorphism (parametric, subtyping); maps, vectors, trees, and other data structures in the stdlib; raw access to pointers; C ABI compat. there are some big differences, but "nothing like c++" is absolutely not true.
It looks like the Mojo compiler/runtime hooks into the CPython interpreter.
> We utilize CPython to run all existing Python3 code “out of the box” without modification and use its runtime, unmodified, for full compatibility with the entire ecosystem. Running code this way will get no benefit from Mojo, but the sheer existence and availability of this ecosystem will rapidly accelerate the bring-up of Mojo, and leverage the fact that Python is really great for high level programming already.
The goal is for the language to be a superset of Python
> Further, we decided that the right long-term goal for Mojo is to provide a superset of Python (i.e. be compatible with existing programs) and to embrace the CPython immediately for long-tail ecosystem enablement.
> 1. We utilize CPython to run all existing Python3 code “out of the box” without modification and use its runtime, unmodified, for full compatibility with the entire ecosystem.
> 2. We will provide a mechanical migrator that provides very good compatibility for people who want to move Python code to Mojo.
> Together, this allows Mojo to integrate well in a mostly-CPython world, but allows Mojo programmers to be able to progressively move code (a module or file at a time) to Mojo. This approach was used and proved by the Objective-C to Swift migration that Apple performed.
Maybe the long-term goal is to try to make it a true superset, but it sounds like the detailed plan is more practical, to basically provide a "Python-next" language, like Swift for Objective-C.
