211–220 of 286 posts
Earlier quoted context omitted.
Not sure why people are downvoting. We all have our hidden agendas, mine is the destruction of all macros.
Surely if you ensure people can't write macros in your language they'll just wrap the entire language in a pre-processing layer to enable macros which seems obviously worse ?
Earlier quoted context omitted.
Vlang started as a closed source project with a lot of lofty claims that fell apart quickly once the project was actually opened up. Combined with all the delays and broken delivery promises leading up to that, it gave people a poor impression of the project. With that said, I've heard the situation has improved since then.
Can you list any claims that fell apart? For example, one of the biggest claims has always been fast compilation. Here's V compiling itself in 0.3 seconds: https://www.youtube.com/watch?v=pvP6wmcl_Sc V was also self hosted (written in V) from the start, which says a lot about the maturity of the language. > Combined with all the delays There were no delays. The project was announced to be released in June, and it was…
How could that possibly be true? You need a V compiler to compile V but none would have existed "from the start".
You've also said multiple times on Discord that the original V compiler was written in Go.
Zig is a very interesting language. You are able to do thing that would require wizard level skills in C with simple plain language construct. Like serializing/deserializing an enum variants over the wire for example in the most efficient way (look at std.json.{parser, stringify} [0]). > soon we’ll also have a package manager This. If they succeed to do this (and I have my doubts) it will be a paradigm shift for low-…
> Let's hope this is not vaporware. I sincerely approve of the skepticism. I can assure you there is already a very large fire under my ass to get this shipped. To provide some more context, here is a snippet from the latest release notes[0]: > Having a package manager built into the Zig compiler is a long-anticipated feature. Zig 0.8.0 does not have this feature. > If the package manager works well, people will use…
Earlier quoted context omitted.
I wouldn't use the word "require", and perhaps you didn't mean it that strongly. Don't get me wrong: I could get by without and achieve what I needed to, but to be honest it didn't feel great. I was doing some pretty gnarly high-level filesystem work (transforming an unstructured tree of files/folders into a more structured tree following certain naming and categorization conventions -- a lot of parsing/building/conc…
Keep in mind that filesystem paths aren't strings. On Linux, they are raw bytes without any fixed encoding (but usually UTF-8 on UTF-8-based locales), and on Windows, they are sequences of 16-bit codepoints which are expected to be UTF-16 but not validated. Rust's OsStr is my favorite approach so far. It stores Linux's raw bytes as-is, and stores Windows's possibly-valid UTF-16 as WTF-8. This makes path management "j…
Earlier quoted context omitted.
I think that's correct with some overlap, yes. Zig's explicit goal - as stated by the creator - is to replace C. Nothing more, nothing less. I feel like Rust wants to replace C but it also wants to replace C++. And given the complexity difference between the two languages, that means that Rust will end up closer to C++ than to C. So there's some overlap based on how Rust positions itself, but not based on how Zig pos…
We already have c/c++ as low level bases, now zig/rust are coming for the throne, I really hope contenders dont keep spawning like rabbits. If everyone got behind a smaller # of initiatives the worlds codebase would be simpler going forward? I'm imaging some poor software engineer in 2065, having to maintain an enterprise legacy stack... levels of FORTRAN/COBOL->C->C++->ZIG->RUST->PERL->PYTHON.... all the way up....J…
Earlier quoted context omitted.
With ARC, Nim's memory management would be closer to Rust than to Go.
Automatic Reference Counting? I’m not sure. Swift spends a lot of its execution time doing reference counting.
> To improve our critical infrastructure we must improve the developer experience (DX) of systems programming, but rewriting everything is not the only answer. I like Kristoff from what I've read of him. He seems like a leader who will take responsibility and not shy away from hard decisions. On that quality alone, my money is on Zig winning systems programming over Rust in 10 years.
The article didn't tell me what Zig really was, so for other people in my boat: https://ziglang.org/ headline from that website: Zig is a general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
Zig is a system programming language, whereas when someone says general purpose programming language they mean java or python. And "robust, optimal, and reusable software" - this type of words are used by all projects these days that it sounds like MBA speak.
I also don't like the tendency of system language projects (zig, rust) to market as if they are application languages, perhaps in an attempt to drive adoption. Can't blame them for this, but it seems an influx of relatively young, inexperienced programmers from ruby rails / javascript crowds creates false impression of a strong ecosystem.
Earlier quoted context omitted.
"It's intentionally less safe! That's why you should use it!" Zig may strike a better balance than Rust does here, but it seems more like Rust stole its lunch. I don't know why I'd migrate from C/C++ to Zig instead of going all the way to Rust?
1. Rust doesnt let you safety-check bit-compressed stuff and instead relies on well-formed types during runtime (basically everything that union allows). 2. Graph memory patterns in Rust are completely unsafe. 3. Code might leak and you dont have tooling to check your dependencies. Trusting the test coverage does not help you there with Rust, because Rust tooling is infeasible for testing leaks. 4. CTFE is not easy t…
2. Wrap up the unsafety in a library like petgraph and use it. Or just use petgraph.
3. jemalloc's leak analysis works with Rust, as does Heaptrack.
4. With const generics it's trivial to pass a value through a const generic parameter to ensure it was evaluated at compile time. Right now that only works for scalars but that limitation will be relaxed later.
5. Most Rust code is safe code which is free from UB. Dynamic checks of all unsafe-code UB is infeasible. So what?
But anyway, none of these are reasons to use Zig.
Zig is a very interesting language. You are able to do thing that would require wizard level skills in C with simple plain language construct. Like serializing/deserializing an enum variants over the wire for example in the most efficient way (look at std.json.{parser, stringify} [0]). > soon we’ll also have a package manager This. If they succeed to do this (and I have my doubts) it will be a paradigm shift for low-…
I've been toying with Zig over the summer, and I'm really impressed by the build system, general ergonomics and the explicitness of the language. The only thing I've found being a pain point is C's biggest pain point: the lack of a proper string type. Even though I've worked for years in the past with C and C++, I still get tripped up, and in Zig I keep on being confused whether I should use raw byte arrays, or senti…
For a minimal std, maybe Zig can have a standard `str` type which is used for all functions that don't need to grow the string and the `String` type is provided by any 3rd party library which is expected to provide a conversion function from `String` to `str`.
These strings types could or could not have a requirement of being Utf-8. Maybe there is a builtin wrapper to convert them. So you can any dynamic byte array which can be converted to `str` (just a pointer and length, no validation) which can be later converted to `utf8` (str but validated). A `String` which guarantees Utf-8 could directly convert to `utf8` to save validation costs.