rust VS zig

Glad you like it 🙂 https://github.com/rust-lang/rust/pull/58530

It's directly responsible for Rust needing the "turbofish" syntax to pin down generic return types as in

let foo.iter().map(|x| x*2).collect::>()

If they'd used something like [T] for generics, then there'd be no collision with the < and > operators needing disambiguation in some contexts.

They even have a Book of Mozilla-esque entry in their test suite named "Bastion of the Turbofish" to pin down an example of the problem case, complete with

https://github.com/rust-lang/rust/blob/43192ca3d72ed0ca42ba9...

To my knowledge, this closure syntax was a direct Ruby influence mainly because this syntax was also supposed to work like Ruby blocks: `array.each |e| { ... }`. Originally owned and shared closures had a different syntax (`fn~() { ... }` or `[email protected]() { ... }`)---this was back when Rust had a built-in shared reference, roughly equivalent to `std::sync::Arc` in the modern Rust---and it was pointed out that they should be harmonized at some point [1]. It was that time when people realized that then-loop-only syntax can be generalized into any closures, and this semi-decision got stuck even after the "internal" iterator that accepts a closure has long gone.

[1] https://github.com/rust-lang/rust/issues/1864

I found only this issue https://github.com/rust-lang/rust/issues/87970 but has no details

Here's the discussion that lead to the implementation of those functions, from more recent to least recent,

* the tracking issue https://github.com/rust-lang/rust/issues/49048

* the RFC https://github.com/rust-lang/rfcs/pull/2169

* the internals discussion https://internals.rust-lang.org/t/mathematical-modulo-operat...

It's baffling that Rust got this wrong..

If rust has no runtime, maybe you could enlighten us as to what this is: https://github.com/rust-lang/rust/blob/master/library/std/src/rt.rs

I don't want to list specific contributors here. We often have no information on why people left the project - there might be all sorts of personal factors. I will say that my broader sentiment - that Rust's momentum has slowed, that it's not delivering on its commitments in a timely way, that there are concerns about it's ability to deliver in future - has been expressed publicly by high profile past core contributors:

https://github.com/rust-lang/rust/pull/96709#issuecomment-11...

I don't think Rust should tackle any ambitious project to rewrite the compiler while these basic concerns remain.

Ah fair. You're right that the linked graph is over one year, but then I switched tabs to look at https://github.com/rust-lang/rust/graphs/contributors which has a longer time period

Commit counts regularly fluctuate: https://github.com/rust-lang/rust/graphs/contributors

Potentially it is due to this layout optimization and a missing repr(C) somewhere in your code or a dependency. For example, here is an is a related issue in luminance.

I'm more interested in Zig right now, it looks like a great way to incrementally improve an existing C or C++ code base. I haven't toyed with it yet, but I'd be eager to try it in a project.

correction: zig does not have a built-in, special hash table. Both ArrayHashMap and HashMap are implemented in the standard library.

I'm currently getting into zig and I am trying to make a flake for a test application and i need a zig library mach-glfw for windowing support. Zig is in the process of getting a package manager so for now an idiomatic way of working with 3rd party libraries seems to be to add them as a git submodule in a folder called libs in the project root directory and link them from build.zig

Depends on what you mean by embedded? Microcontrollers (AVG/Arduino)? System-on-a-Chip (SoC)? Embedded Linux system (Raspberry Pi, ARM/MIPS, etc)? There is mrubyc which has been put onto various embedded systems. However, if you want raw performance and minimal memory usage, C is probably still the best option; although it is notoriously difficult to write secure code in C, which is why Rust and Zig are becoming popular for embedded development.

Take a look at the implementation of ArrayList. It allocates a buffer of .capacity sizeof(T) and maintain a slice (.items) that fits exactly the currently used capacity. myList.capacity is the capacity, and myList.items.len is the used-capacity. Not the same name.

This is a simplified BoundedArray struct from the standard library.

A better option would be Zig language https://ziglang.org/

Yes: https://github.com/ziglang/zig/issues/2301 for safety features and https://github.com/ziglang/zig/issues/6396 for assumptions that Zig makes.