Earlier quoted context omitted.
Why does the staff allow this racist troll to continue to post?
Mind your language.
So you acknowledge being a racist troll.
Zig, the Small Language
371–380 of 429 posts
Re: Zig, the Small Language
#372Re: Zig, the Small Language
#373Earlier quoted context omitted.
That was not my experience. I still fought the borrow checker after a year of using Rust. And I found many situations while using Rust where I either needed to clone, or use unsafe where it's easier to make a mistake than in other languages because the syntax is extremely unergonomic and the memory semantics are much less clear.
> I still fought the borrow checker after a year of using Rust. That's interesting. How much Rust did you use during that year? And how level of proficiency did you reach? > And I found many situations while using Rust where I either needed to clone, or use unsafe That sounds like an uncommon trade-off. From my experience, the trade-off was usually “clone or put lifetime parameters everywhere”, which is annoying (and…
> How much Rust did you use during that year? And how level of proficiency did you reach?
What kind of answer do you expect to these questions?
Re: Zig, the Small Language
#374Earlier quoted context omitted.
If we look from the point of view of comptime and having a more curly friendly syntax for C folks, maybe.
Sure, comptime, comptime introspection, comptime type generation, incremental compilation, basically the most important things for low-level programming.
Many low level programming languages don't have them, including C, so while a nice feature, I don't see it as a killer feature, more like a nice to have.
Re: Zig, the Small Language
#375Earlier quoted context omitted.
Well, let's turn this around. Is C++ spatially memory safe? C++20 has slices (ranges). They're bounds checked, via the .at() method. You can get the integer overflow semantics of Zig with "-fsanitize=signed-integer-overflow -fsanitize=unsigned-integer-overflow -fsanitize=float-cast-overflow". You could write a checker that enforces that only these features are used (in fact, this checker basically exists--ISO Core C+…
Note that STL containers allow you to bounds check "[]" indexing even in release mode if you set the right preprocessor directives. The flag differs between compilers and stdlib implementations, though. For libstdc++ (default on linux), use _GLIBCXX_ASSERTIONS. For example, the following code aborts on release builds too: // g++ -O3 -D_GLIBCXX_ASSERTIONS=1 file.cpp #include #include int main() { std::vector vec{1, 2,…
Good to know, thanks!
Re: Zig, the Small Language
#376I don't know Zig, but aren't we missing a return here? fn count_nonzero(a: []const i32) i32 { var count: i32 = 0; for (items) |value| { // "for" works only on arrays and slices, use >"while" for generic loops. if (value == 0) { continue; } count += 1; // there is no increment operator, but there are shortcuts for +=, \*=, >>= etc. } }
I'm not super-great with Zig, but my understanding is that `count` should be the return value, post-increment.
When the return value is unspecified, Zig will default to an implicit return of the last-calculated rvalue. The same behavior is also found in Ruby, Lisp, and some other languages as well.
Re: Zig, the Small Language
#377Earlier quoted context omitted.
Well it would depend on context. For a FOSS software in domain where there are tons of other options, it is much easier to use what one likes and ignore what one doesn't. So calling it silencing the debate sounds too strong when software in question is not some controlling the world type. On the other hand in case cloud services like those provided Google/FB/Twitter/Cloudflare etc it is much more difficult to just go…
"Don't like it? Just fork it!" is a variant I see a lot in the FOSS world. It's equally pernicious in my view. Either you end up maintaining your own fork that nobody uses (and who wants to do that) or the fork is successful and half the community starts hating you for causing more fragmentation. Perhaps the most recent example of this I can think of is neovim, though in the language world python 2 vs 3 is so infamou…
I agree with a lot of this, in terms of the polarization and tribalism, which is often the result. Unfortunately, there is little that can be usually done, except use other programming languages (which are more agreeable) or fork/make your own.
Re: Zig, the Small Language
#378Why should I use Zig coming from Rust? It doesn't seem that Zig actually solves the memory problems that Rust does.
That's the wrong question to ask. Don't compare it to rust's memory safety as otherwise you're pretty much answering your own question with "you shouldn't".
Think of what zig has to offer instead and try it out to see how it works.
Re: Zig, the Small Language
#379Earlier quoted context omitted.
Chess was such a good example to use in this lame dichotomy that we are now pivoting to Bobby Fischer chess and completely different games.
Completely different in that everything is exactly the same except for minor variation to the starting position...
Fischer Chess is solidly outside the mainstream. Just let it go.
Re: Zig, the Small Language
#380Earlier quoted context omitted.
> Zig has full spatial memory safety, which is already a huge improvement over C. I don't believe this is true. Zig has pointers to unknown numbers of items, which don't seem bounds checked: https://ziglang.org/documentation/master/#Pointers They prefer slices idiomatically, but that's not "full spatial memory safety". C also prefers you to pass the length of every array whenever you pass a pointer to it, in that cor…
> They prefer slices idiomatically, but that's not "full spatial memory safety" [*] is a syntactically delineated unsafe feature. Rust has the same thing. It's like saying Rust prefers safety, but doesn't enforce it because it has unsafe features; same goes for Haskell. > I don't see much room for a new language that isn't memory-safe in 2022. That statement [1] is about about as silly as "I don't see much room for a…
Part of the issue is that Zig is in a near category to Rust, and its areas of focus are more restricted as opposed to other general purpose and convenient to use languages. Rust already has major corporate backers and much more established popularity in the media. It can easily be seen how it can just simply overwhelm Zig, and particularly by emphasizing safety. Even if those very knowledgeable about the subject can argue to what degree safety should be the issue or is relevant with a particular project, Rust already has the hype and reputation behind it as being "safer".
Zig has to make stronger and more compelling arguments as to why people should use it, instead of just reaching for Rust.