41–50 of 73 posts
Earlier quoted context omitted.
Erlang has had Hot-code swapping for decades
For every feature X, there is a programming language Y that has had it for decades. It's not a question of inventing it, but rather of making it mainstream popular.
Zig looks very promising, but there are a few nitpicks I have which keep me from deep diving into it. The most annoying thing I've found so far is treating unused variables as compiler errors. I understand this is something more and more languages are doing, but I can't get over it. It makes writing and prototyping code annoying and tedious, especially during the initial learning phase. Zig trusts the programmer to d…
If the 'unused variable'-handling is the only thing that holds you back: it's quite simple to build the zig compiler and patch it. See this post by ryuukk in the corresponding issue on github: https://github.com/ziglang/zig/issues/335#issuecomment-10138... and also https://github.com/ziglang/zig/issues/335#issuecomment-10184... I use this method to build a zig compiler to work with, and when I build a release build o…
That's nuts, both in a bad and a good way.
Earlier quoted context omitted.
It can seem like that on the surface, but a closer look reveals a lot of very interesting new features. Here's a few off the top of my head: * Comptime, which can serve the purpose of generics without a new sub-language [1] * Colorblind async-await, basically parameterizing async-ness to avoid the downsides of async's infectious nature [2] * Hot-code swapping proof-of-concept [3] (Edit: specifically, new to low-level…
Zig's async/await isn't actually colorblind. [1] It just seems that way at first. [1]: https://gavinhoward.com/2022/04/i-believe-zig-has-function-c...
The original color article is soo annoying, because it presents two things as one: a JS-specific limitation, and author's arbitrary opinion on how async syntax should (not) look like. Since then even languages that don't have JS's limitation still keep chasing the other point, because otherwise they're shamed for having "color".
Earlier quoted context omitted.
> I think the future is in languages that prioritize simplicity and developer velocity like Zig is doing. I kind of dont like Zig because of the syntax its just a little out of the norm from what I'm used to. I like D more if I want to go the C-like route, just hate that its not quite as popular as Go or Rust seem to be. Currently I'm diving into Nim more than anything though, it feels like the sweet spot for me.
I wish I had known about D like a decade ago. I swear it was just too ahead of its time.
Enjoy D now when it's more mature. The betterC switch is especially interesting.
Zig looks very promising, but there are a few nitpicks I have which keep me from deep diving into it. The most annoying thing I've found so far is treating unused variables as compiler errors. I understand this is something more and more languages are doing, but I can't get over it. It makes writing and prototyping code annoying and tedious, especially during the initial learning phase. Zig trusts the programmer to d…
But I think it is less annoying than trying to figure out why things aren’t working at runtime. It’s an interesting trade off, but I appreciate zig trying something different here.
Earlier quoted context omitted.
Zig's async/await isn't actually colorblind. [1] It just seems that way at first. [1]: https://gavinhoward.com/2022/04/i-believe-zig-has-function-c...
"Colorblind" is an arbitrary goalpost made to satisfy an imprecisely defined term of one blog post. The original color article is soo annoying, because it presents two things as one: a JS-specific limitation, and author's arbitrary opinion on how async syntax should (not) look like. Since then even languages that don't have JS's limitation still keep chasing the other point, because otherwise they're shamed for havin…
Earlier quoted context omitted.
"Colorblind" is an arbitrary goalpost made to satisfy an imprecisely defined term of one blog post. The original color article is soo annoying, because it presents two things as one: a JS-specific limitation, and author's arbitrary opinion on how async syntax should (not) look like. Since then even languages that don't have JS's limitation still keep chasing the other point, because otherwise they're shamed for havin…
Is it a JS-specific limitation? Python works quite similarly.
Earlier quoted context omitted.
If the 'unused variable'-handling is the only thing that holds you back: it's quite simple to build the zig compiler and patch it. See this post by ryuukk in the corresponding issue on github: https://github.com/ziglang/zig/issues/335#issuecomment-10138... and also https://github.com/ziglang/zig/issues/335#issuecomment-10184... I use this method to build a zig compiler to work with, and when I build a release build o…
Having to build your own version of the compiler to fix this annoyance is like using a sledgehammer to crack a nut. It should be a simple flag, whichever way the default, but it shouldn't require building a compiler. That's nuts, both in a bad and a good way.
I once said I would like arrays of 33 or more items to be Default and my resident Rustacean told me step 1 is to rebuild libcore after changing the appropriate macro :)
Earlier quoted context omitted.
Is it a JS-specific limitation? Python works quite similarly.
Make that JS+Python then. OTOH languages that can spawn threads and use synchronization primitives are able to bridge sync and async.
Not only do threads not really do the thing (in part because of the high cost of threads compared to alternatives), the alternative isn't only threads. Users of Lua, Greenlet, ucontext_t, libco, etc. have been able to write single-threaded code that's generic over the async-ness of its callees for decades. Recently there's a trend toward preferring needing to change 99 call sites and function signatures when adding a single piece of I/O to a single function though, needing to write two versions of each library, etc.
Earlier quoted context omitted.
Yes, why does that matter? It still shows that Zig's async/await is not colorblind.
It seemed like most of your post was about not being able to use the two functions through pointers of the same type, but you can use the two functions through pointers of the same type, so maybe now you can delete a majority of your post and submit a retraction to Hacker News or something. I'm not sure you are using the same notion of "colorblind" as most people. All that is claimed is that much application code can…