301–310 of 344 posts
Earlier quoted context omitted.
Rust fell into the same trap that killed many, many gamedev companies: Performance matters. Even more than features.
Is that still true? PUBG is probably the worst-optimized game ever written, barely getting 60fps on a setup that can run Overwatch at 200+ fps. And yet, it's the most-played game on Steam.
Earlier quoted context omitted.
In the OpenBSD world i386 == x86. And it's pretty easy to find an x86 processor now a days.
… such as? You're merely restating the claim, without providing any proof. Consumer machines, AFAICT, are all amd64 (or x86_64, if you prefer that name). I understood the original post to mean i386 == x86, and I agree — where do you even find an x86 today (for sale, in a non-niche use case, i.e., "pretty easy")?
Earlier quoted context omitted.
>modern C++ is already secure enough Why to have nullptr dereferencing? Why to have an undefined behavior on option dereferencing? Why to have dangling refs? Why not to check borrow possibility statically? God, we don't event have a decent and safe variant (sum) type in c++. Adding all that (unnecessary) complexity c++ has (how many whatever-values and initializations does it have?). It is unsafe as hell, and lots of…
Just as a sidenote, rust has no defined behaviour when dereferencing a null pointer. What makes it worse is that a null pointer in an option is handled as None instead of Some, which kind of broke some of my code until I found that particularly nasty bug and worked around it (with offsets).
>What makes it worse is that a null pointer in an option is handled as None instead of Some
What? How could NULL be treated as Some?
If "safe" language would be real magic pill for safe programming, Ada would have replaced C and C++ in systems programming and safety critical applications long time ago.
I believe Ada suffered from its DoD origins, from the era of giant monolithic project management and its verbosity. Rust is a different kind. Also, I've seen people doing generic low level network stacks (or at least articles about it) in Ada, seems lovely.
Earlier quoted context omitted.
If OBSD feels it can make use of older arches then so be it, many users will find less intensive jobs for the respective hardware and it saves it from going to waste/recycling.
Not to mention plenty of people in the "developed" world (let alone "developing") can't afford to buy a new computer, and thus are going to use 32-bit "legacy" desktops and laptops for a very long time.
Earlier quoted context omitted.
Just as a sidenote, rust has no defined behaviour when dereferencing a null pointer. What makes it worse is that a null pointer in an option is handled as None instead of Some, which kind of broke some of my code until I found that particularly nasty bug and worked around it (with offsets).
Rust does not have nulls beyond unsafe blocks, does it? >What makes it worse is that a null pointer in an option is handled as None instead of Some What? How could NULL be treated as Some?
I think your parent must have been doing something strange; if you have a *const T, one that's null will still be a Some. It's &T, which cannot be null by definition, that uses the null value as None, since it cannot be null.
Earlier quoted context omitted.
Linux and BSD ran for a long time on 32bit systems. 4GB of memory is an ocean in my mind. Those systems should be able to compile their own programs and tools. On a related note, we will eventually be running development tools on microcontrollers. Not that little 16bit parts will run the tools, but that 16bit parts are going away. In price sensitive areas this will not happen, but for things with a larger budget why…
They don't mean "x86" (the 32bit instruction set), but i386 aka Intel 80386, a processor introduced in 1985: https://en.wikipedia.org/wiki/Intel_80386
> the 80386 instruction set, programming model, and binary encodings are still the common denominator for all 32-bit x86 processors, which is termed the i386-architecture, x86, or IA-32, depending on context.
Earlier quoted context omitted.
Just as a sidenote, rust has no defined behaviour when dereferencing a null pointer. What makes it worse is that a null pointer in an option is handled as None instead of Some, which kind of broke some of my code until I found that particularly nasty bug and worked around it (with offsets).
Rust does not have nulls beyond unsafe blocks, does it? >What makes it worse is that a null pointer in an option is handled as None instead of Some What? How could NULL be treated as Some?
When packing such an address into a mut or const within a Option, a NULL will be treated like a None when you write, essentiall, Some(NULL).
Earlier quoted context omitted.
Rust does not have nulls beyond unsafe blocks, does it? >What makes it worse is that a null pointer in an option is handled as None instead of Some What? How could NULL be treated as Some?
It does not. I think your parent must have been doing something strange; if you have a *const T, one that's null will still be a Some. It's &T, which cannot be null by definition, that uses the null value as None, since it cannot be null.
Earlier quoted context omitted.
Fast compilation: less than a second (feels like not waiting at all) Slow compilation: more than a minute (makes to start browsing HN, missing the end, thus losing even more time) To have fast compilation even with big projects is hard. Go, C, and D are usually fast. Scala is usually slow. I care about development builds primarily. The edit-compile-test loop must be really really fast. Optimization flags are irreleva…
This is off topic a bit, but there is a solution for this: > Slow compilation: more than a minute (makes to start browsing HN, missing the end, thus losing even more time) See the thread here: https://askubuntu.com/questions/409611/desktop-notification-... TL;DR install undistract-me, add 2 lines to bashrc, and you will get a desktop popup when a command that takes longer than 10 seconds to complete is finished. Fedo…
[0] https://github.com/qznc/dot/blob/master/config/fish/config.f...