61–70 of 85 posts
Earlier quoted context omitted.
Indeed, using "nix" as a (Rust) library name is a very bad choice, given the increasing popularity of the Nix package manager.
I think we're now at the point where it is very difficult for any name not to clash with the name of something else. So I no longer worry about it.
I was very confused. I thought this had something to do with Rust and nix[1]. [1]: https://nixos.org/nix/
Same here. I thought "A match made in heaven" But it will probably never happen, because Cargo is too good, haha
It's worse than just reinventing the wheel because it's actively harming everyone by requiring them to have a million package managers installed and know how to use them all. And often times these language specific package managers are insecure and lack many features. If we had just a few big package managers like nix and guix people could just package for those and we could have everything in one place. Projects like node, perl, python, rust etc. don't need to be the only people in control of their package managers. They could just host language specific repos or something.
I always find it a bit unfair when I see sloppy C programs used for shock value. What if the Rust developer uses fork().unwrap_or(default_value) in a hurry, or writes if let Some(child) = fork() { do_only_child_stuff(); } else { do_only_parent_stuff(); } or if let Some(ForkResult::Child) = fork() { do_only_child_stuff(); } else { do_only_parent_stuff(); } Now, if you're about to tell me that the examples above are to…
Earlier quoted context omitted.
> What if the Rust developer uses fork().unwrap_or(default_value) in a hurry The point here is that the language's tools and APIs can significantly better drive the developer towards the safe/right solution, that's a large point of type theory and static type systems after all. In this case rust's type system is used to split out the various "result cases" and notify the developer upfront of the various cases to hand…
This has been proven to be wrong over and over again with the many variations of languages that came after C. Newer "safer" languages don't improve bugs
The evidence is on our side that well-design language significantly reduces number of defects in production code if other variables are equal.
Earlier quoted context omitted.
> What if the Rust developer uses fork().unwrap_or(default_value) in a hurry The point here is that the language's tools and APIs can significantly better drive the developer towards the safe/right solution, that's a large point of type theory and static type systems after all. In this case rust's type system is used to split out the various "result cases" and notify the developer upfront of the various cases to hand…
This has been proven to be wrong over and over again with the many variations of languages that came after C. Newer "safer" languages don't improve bugs
Earlier quoted context omitted.
It's not even clear to me that there's any overhead to the Rust version. Checking error codes that should be checked isn't overhead. Checking them inefficiently would be overhead, but the Rust version looks like it should compile down to something pretty similar to what the equivalent C switch blocks would produce.
> It's not even clear to me that there's any overhead to the Rust version. There is a slight bit of stack overhead: Option is at least {tag:u8, {tag:u8, pid:i32}}, and due to alignment constraints it's actually {tag: u32, {tag: u32, pid: i32 }}). A nonzero wrapper[0] would allow folding either ForkResult or Option into a 0-valued pid_t and remove one level of tagging: http://is.gd/yxStW1 Beyond that you'd need genera…
Earlier quoted context omitted.
Then you are missing the whole point of Rust. The point of Rust IS to allow you to be close to the machine but while you maintain much higher level of safety. Rust is designed to do this with little overhead. In this day and age with big software packages, security being an increased concern it really is high time programming languages do more to help us avoid bugs which expose us to hackers and crackers. I do have a…
The proposition that Rust is offering is not new. In the 90s Modula-2 was touted as "a better, safer way" of doing system programming than C. It failed to get traction outside of education because it failed to offer a compelling reason for people to migrate. Those that do not study history are doomed to repeat its mistakes. In the example given it's possible to write a similar library in C to protect against unwanted…
Rust offers one major thing that Modula-2 never did: eliminating memory management problems (also concurrency problems) with zero overhead. In the '80s and '90s it was not known just how dangerous memory management problems could be (use-after-free was thought to be a harmless annoyance). Not now in 2016, with every single browser engine falling to remote code execution via UAF in Pwn2Own.
Earlier quoted context omitted.
> Well pids should be pid_t not int. pid_t isn't a newtype, it's just a typedef, so that doesn't really make a difference. > System calls should really return two values, return value and errno, but C doesn't handle that very well either. Most system calls want to return either , not both. And C doesn't handle that at all.
Appropriate tangent: Remember that part where null terminated strings save at most three-bytes per string? And if the allocator is long word aligned it saves none-bytes. The first to arrive sets a disproportionate amount of the direction.
str len: c-str bytes: size-prefix bytes: difference:
1 1+1 (4) 4+1 (8) 4
2 2+1 (4) 4+2 (8) 4
3 3+1 (4) 4+3 (8) 4
4 4+1 (8) 4+4 (8) 0
5 5+1 (8) 4+5 (12) 4
6 6+1 (8) 4+6 (12) 4
7 7+1 (8) 4+7 (12) 4
8 8+1 (12) 4+8 (12) 0
The only time the size-prefixed variant doesn't require more memory is when the string length is a multiple of 4. So the length-prefixed version requires an additional 3 bytes on average.
Earlier quoted context omitted.
Appropriate tangent: Remember that part where null terminated strings save at most three-bytes per string? And if the allocator is long word aligned it saves none-bytes. The first to arrive sets a disproportionate amount of the direction.
Not sure how you get that. Let's assume that memory is allocated in sizes that are multiples of 4, and length-prefixed strings have a 4 byte length prefix. str len: c-str bytes: size-prefix bytes: difference: 1 1+1 (4) 4+1 (8) 4 2 2+1 (4) 4+2 (8) 4 3 3+1 (4) 4+3 (8) 4 4 4+1 (8) 4+4 (8) 0 5 5+1 (8) 4+5 (12) 4 6 6+1 (8) 4+6 (12) 4 7 7+1 (8) 4+7 (12) 4 8 8+1 (12) 4+8 (12) 0 So, for example: "ABCDE" as a C-style string w…
Worth every byte.