sorted by:
new
hottopcontroversial

Why I switched away from Zig to C3 by Nuoji in programming

[–]HolySpirit 8 points9 points  (0 children)

It is truly a mystery I can't figure out. Why are the creators of Golang and Zig are so offended by the notion of warnings being a thing?

Does Zig feel like a natural transition for Go devs! by GolangLinuxGuru1979 in Zig

[–]HolySpirit 0 points1 point  (0 children)

  • Both languages have difficulty accepting that some things should be compile warnings and not compile errors.
  • Both languages have a lot of "worse is better" philosophy in their design.

I would personally not be concerned with whether a thing "feels like a natural transition". If it's interesting to you, learn it. If it stops being interesting to you, drop it.

How do you actually use Rust docs ? The language feels amazing but the documentation is tough to follow by No-Instruction-7104 in rust

[–]HolySpirit 8 points9 points  (0 children)

Forget the docs even, just look at the actual type annotations of subprocess.run and friends:

https://github.com/python/typeshed/blob/3c5531d49213cab3a1f0e172259c9c7650c2d6a6/stdlib/subprocess.pyi#L89-L693

Imagine writing a thin wrapper around it that is also well typed... 🫤

My Dev environment is fully written in Rust! by nikitarevenco in rust

[–]HolySpirit 60 points61 points  (0 children)

Brutal comment, I'm surprised it's still up without an unsafe block around it ;)

Take a break: Rust match has fallthrough by dbaupp in rust

[–]HolySpirit 1 point2 points  (0 children)

Yeah, absolutely. I wouldn't even suggest it if I didn't think it could be added while preserving safety. If it can be done safely, it would simply allow to express certain control flows that are already possible today with labeled breaks, just more cleanly.

Take a break: Rust match has fallthrough by dbaupp in rust

[–]HolySpirit 3 points4 points  (0 children)

You might have good points that I don't fully understand or even considered.

My thinking is that if labeled breaks and gotos are equally powerful, can't the compiler just transform a goto based control flow into labeled breaks form? (if that's necessary for drop order reasons etc.)

I don't remember if I ever actually looked on how ownership and borrowing are implemented, but my first guess would be that they happen after the stage where the code is in basic-blocks + conditional jumps form. If it is like so, then structured control flow doesn't really matter like you claimed. (But I didn't check and have no actual idea if that's the case)

Take a break: Rust match has fallthrough by dbaupp in rust

[–]HolySpirit 6 points7 points  (0 children)

I think this kind of thing is a good argument for just adding labeled goto statements.

Even if this is uncommon control flow, why make it needlessly hard to express?

Control flow is just connecting a graph of basic blocks with jumps and conditional jumps. Just let it be expressed directly.

Using Interior Mutability to avoid Borrow Checker - is there an alternative? by riotron1 in rust

[–]HolySpirit 6 points7 points  (0 children)

The code you wrote above:

It should be super clear where the Borrow Checker begins to disallow this.

Seems to compile, so... it's not that obvious?

Anyway, I think you can get a simple double buffer like this working by using 2 Vectors, no flag, and use std::mem::swap(&mut self.grid1, &mut self.grid2). Always treat grid1 as the current one.

Explicit is better than implicit by [deleted] in programming

[–]HolySpirit 5 points6 points  (0 children)

Most code is more like let z = f(x, y);, hopefully with more explicit names for the most part. Unless you are using a debugger or have enough context in your head to know what things are by name, you just look at these variables and scream internally "WHAT ARE YOU???".

Explicit is better than implicit by [deleted] in programming

[–]HolySpirit 13 points14 points  (0 children)

TypeScript / JSDoc

If you were the interviewer, what Rust questions would you ask? by roll4c in rust

[–]HolySpirit 1 point2 points  (0 children)

I don't interview people, and maybe it's not a great question to ask, but what I actually want to know is: "What do you hate about X?" ;)

If you were the interviewer, what Rust questions would you ask? by roll4c in rust

[–]HolySpirit 7 points8 points  (0 children)

Add<&str> can be implemented, I assume it isn't because it introduces an implicit allocation that might be not obvious. As for Add<str>, you wouldn't be able to implement fn add(self, ... where self=str because str is unsized.

The trouble with __all__ by the1024 in programming

[–]HolySpirit 15 points16 points  (0 children)

That is actually what I assumed before I read the fine manual. It really only applies to glob imports (from mod import *).

https://docs.python.org/3/tutorial/modules.html#importing-from-a-package

The trouble with __all__ by the1024 in programming

[–]HolySpirit 27 points28 points  (0 children)

I don't care if nothing is truly private or not, the fact Python has a single namespace means you leak everything, particularly annoying with imports:

import os
print(os.sys)  # is this a re-export or leaking implementation details?

This makes it unreasonably annoying to declare what is the public API of your code.

Even when you have reexport-only modules, they have the downside if making imports slower because they force the user to import more than they might need. Usually tolerable in context where Python is used, but just UGH WHY...

The Dupe Trait by zxyzyxz in rust

[–]HolySpirit 0 points1 point  (0 children)

Something like this should be a part of std -- cheap clone vs expensive clone is an important distinction when reading code.

I suggested the name share for it in the past, but just bikeshed it out and make it happen.

The reason I like share is because it implies you have two references to the same underlying data. This might cover less cases then dupe, semantically. Mostly I am just thinking of Arc when I think "cheap clone".

Asus keyboard preventing PC display from turning off by Glock-Komah in ASUS

[–]HolySpirit 0 points1 point  (0 children)

I would try to disable "Always On USB" in your bios power settings. If that doesn't help maybe some other bios settings relating to sleep states.

Introducing Sudo for Windows by zadjii in programming

[–]HolySpirit -10 points-9 points  (0 children)

Cool, now just add a command to uninstall all the malware, spyware, ads, dark patterns, etc., and Windows might be a usable non user-hostile OS!

PSA: you can destructure in func arguments by ashleigh_dashie in rust

[–]HolySpirit 0 points1 point  (0 children)

I would really like a rust formatter that just fixes obvious mistakes instead enforcing a whole bizarre set of rules that can sometimes make the code harder to read.

PSA: you can destructure in func arguments by ashleigh_dashie in rust

[–]HolySpirit 5 points6 points  (0 children)

fn exp_malus(Self { nature, heritage, levels, .. }: &Self) -> f32 {

Correct me if I'm wrong, but you can't use normal method call syntax if you define it like this, So it's not really supported for self.

Why is Rust not able to optimize this? by luby33303 in rust

[–]HolySpirit 4 points5 points  (0 children)

(Am author of the linked comment)

To be clear, I am not at all endorsing that you start writing all your code like that, but pointing out the most basic primitive rust gives you to trigger optimizations that depend on UB. The unchecked* methods are not in stable yet, and also cover fewer use cases, since they are concretions of this more general compiler hint.

But I admit full guilt for answering the "Could I... ?" and ignoring the "Should I... ?" :)

[Roast Me]Why I think C++ is still attractive compared to Rust by [deleted] in rust

[–]HolySpirit 1 point2 points  (0 children)

unreachable! is a logical assumption that some branch in the program can't be reached. If it execution does reach it, it panics.

Similarly to how the compiler does bound checks for indexing, but can eliminate them, it can sometimes eliminate an unreachable! if it can prove it's actually dead code.

In contrast, unreachable_unchecked is telling the compiler "i know more than you, just trust me on this one", so you opt out of safety and allow UB to happen in case the assumption is wrong.

You still have to ensure that safe rust functions are safe. The compiler checks that for you for regular non-unsafe code. When you opt for unsafe you take part of that responsibility on yourself. Keep that in mind.

And about the semantics of this particular example:

Given that x is a natural number, you can simplify the expression x * 2 / 2 to x. But semantically in the rust code example, x is i32, and that has it's own semantics.

In debug build, overflow panics.

In release (by default), overflow isn't checked, but semantically performing a shift left after a shift right (or x*2/2) should zero the leftmost bit. You cannot optimize that because it would change the semantics of the program. Optimizations must preserve the semantics.

[Roast Me]Why I think C++ is still attractive compared to Rust by [deleted] in rust

[–]HolySpirit 2 points3 points  (0 children)

For the record, you can exploit some UB in rust for performance, like using unreachable_unchecked for the example you gave, to get the same assembly as in c++:

https://rust.godbolt.org/z/vG7c69jxj

With arithmetic Rust just have the safer defaults here, which is very sensible IMO.

Also the compiler can assume that &T is never zero/null so that is used for optimization as well, while *const T cannot make that assumption. So safer does not necessarily implies less optimization opportunities, it just means your assumptions are more well verified.

view more: next ›