Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comparative unsafety

flak.tedunangst.com

Post reply on HN
Print view View original

41–50 of 99 posts

Re: Comparative unsafety

#41

Post by nottorp »

ChrisSD wrote: post #38
GuB-42 wrote: post #29

Earlier quoted context omitted.

Looking at the source, the progress bar is completely fake, it really does nothing besides making you wait. It even introduces slight delays to make it look more realistic. Why? Just why? The worst part is that the site is actually very light, with none of the ads, analytics and resource hog frameworks that are all too common these days. It probably could load almost instantly if it wasn't for that fake progress bar.…

It's meant as satire on the needlessly script heavy websites that many people create nowadays. The blog post itself isn't entirely serious either.

Well, unfortunately for me it resulted into an early page close. I thought someone who uses that much javascript for a page that could have been 100% static can't have anything interesting to say.

Re: Comparative unsafety

#42

Post by ChrisSD »

thaumasiotes wrote: post #36
ChrisSD wrote: post #30

Earlier quoted context omitted.

In Rust the simplest way would be to use the `u32::MAX` constant. Create a fun alias for it if you want to express intent.

I actually find ~0 more intuitive. u32::MAX makes me think the relevant concept is "a really big number"; ~0 makes me think the relevant concept is "a bunch of bits that are all 1s".

Fair enough. But tbh I'm not sure it really matters in this context. It's just a constant that means "ignore this parameter". Whether it's "a really big number" or "a bunch of bits that are all 1s" is incidental.

Btw, you can directly express "all ones" in Rust as:

    0b_1111_1111_1111_1111_1111_1111_1111_1111
Though it's somewhat less succinct. ;)

EDIT: Added more ones, thanks adwn!

Re: Comparative unsafety

#43

Post by cesarb »

nicoburns wrote: post #8

From my perspective as someone who knows Rust but primarily works with high-level languages like JavaScript, some developers who from a background of unsafe languages (particularly C and C++) seem incredibly cavalier around `unsafe` blocks in Rust code. It's like they're desensitised to the unsafety. As someone who is used to working in a language where one absolutely cannot hit memory safety issues or undefined beha…

> From my perspective as someone who knows Rust but primarily works with high-level languages like JavaScript, some developers who from a background of unsafe languages (particularly C and C++) seem incredibly cavalier around `unsafe` blocks in Rust code. It's like they're desensitised to the unsafety.

That's true. If you are used to 100% of your code being within the equivalent of a Rust "unsafe" block, having over 90% of your code being verified as safe by the compiler is a luxury. Even if one in ten lines are marked as "unsafe", that's already many times less "unsafe" than what they are used to in their C or C++ code.

Moreover, C and C++ developers are used to all kinds of bizarre memory-saving and cycle-counting code that require "unsafe" in Rust. Things like intrusive double-linked circular linked lists, stashing things in the lower bits of pointers (I mean, it's a pointer to a 32-bit value which will always be 32-bit aligned, the lowest two bits will always be zero, why not use them?), doing XOR on pointers, and plenty of other useful tricks.

Re: Comparative unsafety

#44

Post by adwn »

ChrisSD wrote: post #42
thaumasiotes wrote: post #36

Earlier quoted context omitted.

I actually find ~0 more intuitive. u32::MAX makes me think the relevant concept is "a really big number"; ~0 makes me think the relevant concept is "a bunch of bits that are all 1s".

Fair enough. But tbh I'm not sure it really matters in this context. It's just a constant that means "ignore this parameter". Whether it's "a really big number" or "a bunch of bits that are all 1s" is incidental. Btw, you can directly express "all ones" in Rust as: 0b_1111_1111_1111_1111_1111_1111_1111_1111 Though it's somewhat less succinct. ;) EDIT: Added more ones, thanks adwn!

> 0b1111_1111_1111_1111

That's just 16 bits and will result in the value 65535, not -1.

Re: Comparative unsafety

#45

Post by rectang »

ncmncm wrote: post #35
im3w1l wrote: post #23

Earlier quoted context omitted.

> I was a TA in a first-semester course in C programming for several years, and one of the harder things to inculcate is how return value checking is not optional. It's very tempting to assume your standard library function just works, always. The situation is worse than that. People check for errors except when they don't. And you are expected to know the difference. Take for instance malloc. It can return NULL but…

No one checks close()'s result because it lies. What should you write, while (close(fd) != 0) {} ? Or does it risk getting an infinite loop if, e.g., some network connection disappears? Maybe if (fsync(fd) == 0) while (close(fd) != 0) {} else abort(); But maybe fsync is interruptible too. Ultimately there is nothing strictly correct to write, and you should just not really count on files being closed before process t…

> No one checks close()'s result because it lies.

And since nobody checks the result of close and very few check the result of every single write operation, many "disk full" errors go unnoticed.

Re: Comparative unsafety

#46

Post by ChrisSD »

adwn wrote: post #44
ChrisSD wrote: post #42

Earlier quoted context omitted.

Fair enough. But tbh I'm not sure it really matters in this context. It's just a constant that means "ignore this parameter". Whether it's "a really big number" or "a bunch of bits that are all 1s" is incidental. Btw, you can directly express "all ones" in Rust as: 0b_1111_1111_1111_1111_1111_1111_1111_1111 Though it's somewhat less succinct. ;) EDIT: Added more ones, thanks adwn!

> 0b1111_1111_1111_1111 That's just 16 bits and will result in the value 65535, not -1.

Ha, yes you're right. I'm on my phone and got tired of writing ones. I'll edit when I'm next at my laptop.

Re: Comparative unsafety

#47

Post by caslon »

tyingq wrote: post #21
caslon wrote: post #15

Earlier quoted context omitted.

It's a joke. It's not a terrible idea. It's a great idea! A great joke!

Well, aside from the delay in seeing the content, it borks the back button up, etc. Breaking all the pages on your site for a joke is an odd idea to me. Edit: As mentioned by another commenter, seems to be deliberate punishment for having javascript enabled. Also, clicking outside the main window (like in the url bar) does the render thing again. And a search for javascript has some odd results too: https://flak.tedu…

Yeah, what's wrong about punishing Javascript users? It's funny.

Re: Comparative unsafety

#48

Post by stefan_ »

rectang wrote: post #37

In Rust, dereferencing a pointer is unsafe and so must be isolated within an `unsafe` block — but creating a dangling pointer is not unsafe. What this means is that as soon as you add `unsafe` code which accepts a pointer argument, all the supposedly "safe" code which can affect this pointer argument becomes a potential source of memory errors. To me, this was unintuitive — I expected the `unsafe` block to require an…

In general unsafe should be viral: you can't call unsafe without yourself being unsafe. But it hits the same "snag", then nothing works anymore.

Re: Comparative unsafety

#49

Post by [deleted] »

tyingq wrote: post #21
caslon wrote: post #15

Earlier quoted context omitted.

It's a joke. It's not a terrible idea. It's a great idea! A great joke!

Well, aside from the delay in seeing the content, it borks the back button up, etc. Breaking all the pages on your site for a joke is an odd idea to me. Edit: As mentioned by another commenter, seems to be deliberate punishment for having javascript enabled. Also, clicking outside the main window (like in the url bar) does the render thing again. And a search for javascript has some odd results too: https://flak.tedu…

[deleted]

Re: Comparative unsafety

#50

Post by [deleted] »

nicoburns wrote: post #8

From my perspective as someone who knows Rust but primarily works with high-level languages like JavaScript, some developers who from a background of unsafe languages (particularly C and C++) seem incredibly cavalier around `unsafe` blocks in Rust code. It's like they're desensitised to the unsafety. As someone who is used to working in a language where one absolutely cannot hit memory safety issues or undefined beha…

[deleted]
Post reply on HN