391–400 of 429 posts
Earlier quoted context omitted.
Because Garbage Collection is basically a garbage feature that should be, at the very least, optional.
It is optional in nim
I’m in favor of big general purpose languages. Why? Not for their own sake. Just because it’s tedious to use multiple languages. - How do they communicate? Maybe Json if it’s just data. For more control you need FFI - And FFI is such a hassle that some languages seem to focus mostly on getting a nice C FFI - ... That lingua franca that proves that you can have all the simple languages that you want as long as its nam…
Zig can directly compile C and C++ code. It's probably one of the easiest languages for C/C++ interop.
Zig indeed is pretty nice, i just wish it had some more sweet to it - my math type with + - * / overloads - simpler way to fill an array, i can never remember the syntax, it doesn't feel natural `[_]u8{0} * 10;` - smarter type system, i am tired of casting everything twice A good language is not a language set in stone, a good language is a language that doesn't make me feel like i have to suffer because they made a…
> A good language is not a language set in stone, a good language is a language that doesn't make me feel like i have to suffer because they made a stupid decision years ago and they refuse to make it better It depends. Low level coding the like of which zig is tailored to tends to involve a lot "write and forget about it" infrastructure stuff. At least that's my use case. It sucks to painfully go over that cryptogra…
Earlier quoted context omitted.
You and me both, in fact I made my voice heard in the Github issue. What's damning is how much Stockholm Syndrome there is around this feature, with people saying it's no big deal and it helps catch bugs. It's more annoying than helpful, and it catches a very small amount of corner cases, while completely killing productivity. And you know what's the reasoning behind this? "Zig doesn't have warnings." As if it's a ma…
> And you know what's the reasoning behind this? "Zig doesn't have warnings." As if it's a massive undertaking to add warnings to a compiler. What a sorry excuse. Setting aside the unused variables issue for a moment, you might want to take a moment to ponder the fact that not having warning messages is an explicit design choice, not a missing feature.
Earlier quoted context omitted.
A dogmatic one, by the sounds of it.
Well if one never stops to think about its potential merits, it can surely only be perceived as dogmatic. One thing is evaluating a choice in its full context and not liking it, another is demanding to have your vision be understood and accepted without being willing to grant the same courtesy first.
Is it available somewhere? I can't think anything why that compiler patch[0] can't be upstream (of course not default, but under a flag/different build mode/config option).
[0]: https://github.com/ziglang/zig/issues/335#issuecomment-10138...
Earlier quoted context omitted.
There's no equivalent to a "direct line to andrewrk" because Rust does not have this one man setup. Culturally, there's more of a "pitch in to help" and less "ask before touching". So people are mostly looking for hand-holding, "How do I?" and "Is this correct?" rather than decisions and permission.
>There's no equivalent to a "direct line to andrewrk" because Rust does not have this one man setup. Nothing in my comment is about a "one man" setup. Core Rust devs hang out in the Discord server. They don't hang out in the IRC channel. >Culturally, there's more of a "pitch in to help" and less "ask before touching". So people are mostly looking for hand-holding, "How do I?" and "Is this correct?" rather than decisi…
Why should I use Zig coming from Rust? It doesn't seem that Zig actually solves the memory problems that Rust does.
Not fighting the borrow checker or making gratuitous copies of data to satisfy the borrow checker. Zig's scope is just to be a better C that's free to add modern features like optional types, compile time expressions instead of string-macros, source level modules, packages, a more expressive syntax for writing bit-packed structures, a standard testing framework, deferred function calls, and so on. You can also direct…
The thing about that though, is there are a number of better C languages (both old and new) that have various levels of C interop. Languages like: D, Odin, Nim, Vlang, etc...
Earlier quoted context omitted.
I wouldn't expect cryptography to need much unsafe. I've never worked in the area, but I expect code mostly falls into 3 domains: parsing, "business" logic (negotiating algorithms, checking certificates/signatures the right way, etc.), and actual crypto algorithms. I see great benefit for Rust in the first two domains. In the algo domain, I don't see how memory safety adds anything as memory issues are an insignifica…
> I don't see how memory safety adds anything [to algos in cryptography] as memory issues are an insignificant problem. I'm not terribly experienced in cryptography either, but I'm pretty sure that memory safety is a HUGE deal in cryptography as a whole. Heartbleed[0] was a memory safety issue. Python's cryptography package switched to Rust specifically because of memory safety [1]. [0] https://cve.mitre.org/cgi-bin/…
Earlier quoted context omitted.
Go look at herb sutter's guru of the week articles, and consider how many C++ programmers can actually solve them. Then consider c++ has gotten even more complex in the past 9 years since he last published a gotw. The main problem is that every c++ programmer has their favorite little bit of complexity in the language, and that favorite bit is different for everyone. So you end up with a codebase sprinkled with the f…
Since it is considered a begginers language, how complex do you imagine Python actually is, given that the language reference is 186 pages and the standard library 2159 pages, plus whatever has changed between versions?
Earlier quoted context omitted.
As far as I am concerned, the alleged "memory safety" benefits of Rust do not have much more value or weight than wishful thinking, this kind of claim can only gain strength by standing the test of time. Computer security is a real problem that must be fully addressed at every step of the design of a system, language and tooling can help, a bit, not much. Rust is not a "safe" language. It might be -safer- than C/C++,…
Here's a hypothesis I'd like to see Rust advocate attack: In any serious system written in Rust, significant portions of it will have to be written in "Unsafe Rust".
GhostCell is an interesting venture away from that idea. For the sorts of loopy data structures that upset the compiler, GhostCell provides a small, well-vetted, probably correct unsafe core and a safe API for accessing it that greatly reduces the amount of unsafe one should need. The core mechanism is just a higher order phantom (ghost) type parameter that gives the compiler enough information to vet that the thing you're handling was acquired properly.
The community has generally been pretty gung-ho about getting the most safe bang for your unsafe buck, and the compiler has enough bells and whistles to make many such ideas pretty seamless.