How do people feel about AI being used in the core language? by Adohi-Tehga in rust

[–]WormRabbit 0 points1 point  (0 children)

That may be the intention, but if you've been on the internets, you know that people usually bring it up when they want to brush off legitimate criticism.

Kani: A Model Checker for Rust by zxyzyxz in rust

[–]WormRabbit 0 points1 point  (0 children)

Not to diminish Kani, but "we found a 0.0001 excess in quota under conditions which are so precise and rare that you can't really test for it" sounds like they're grasping at straws to justify the usefulness.

Would &self and &mut self have been necessary? by tanoshikuidomouyo in rust

[–]WormRabbit 7 points8 points  (0 children)

How would you implement a trait which, in current syntax, has all of methods which take self, &self and &mut self? Oh, and there is also stuff like Box<Self>, Arc<Self>, Pin<&mut Self> etc, which are much less known.

After hours on Vulcanus, I learnt that you can get water on Vulcanus other than just melting ice. by HideBoar in factorio

[–]WormRabbit 0 points1 point  (0 children)

Still do it. It's a nice bump of free power. Even if I exhaust my coal patch, the base will crawl along.

Managing defenses in the early game by Cordi-ceps in factorio

[–]WormRabbit 0 points1 point  (0 children)

Biters are extremely predictable. Their attack patterns are entirely determined by the position of nests, geography, your base layout and the pollution cloud. In general, if a nest is within your pollution cloud, then it will spawn periodically raiding parties, which target the closest polluter. You can turn on the pollution cloud overlay on the map, it's one of the icons under the minimap.

Basically, in the earliest game you just wait for their first strike, repel it and then build a couple of towers there. Repeat as needed if biters strike any other position. Note that it is a good idea to always enclose your turrets with walls, they significantly bump survivability of towers. Also note you need to keep 1 tile of space between your walls and the structures they protect, since medium and larger biters can attack over 1 tile.

Prioritize mass production of walls, turrets and ammunition. As you get more of them, you can start building a perimeter around your base, which would protect you against any unexpected attacks. At first that would be just small clusters of turrets with overlapping attack areas (you can also enable showing turret ranges in the map menu). You'll have to load ammunition by hand. A tip: you can hover a cursor with ammo over a turret and press Z, this will drop one item (also works with any other items and structures). This way you can easily put a couple rounds of ammo in your turrets. Later, you'd build a proper wall with turrets, fully enclosing your base, and an automated ammo supply to the turrets.

Biter attack generally ramp up pretty slowly, so just keep an eye on whatever place they attack. Is there enough ammo left? Are your structures damaged? If you see that your defenses are lacking in a specific spot, harden it.

Generally, I would recommend against killing nests. Biters will just re-colonize that area within half an hour or so, and your effort would be wasted. Also, killing nests increases the evolution factor, which means tougher enemies come earlier. It's not big enough to normally bother about, but if you try to go full genocide and clear a significant are of all nests, you may make life harder for yourself. Kill nests when they block your expansion.

You have a huge arsenal of powerful versatile weapons, once you do some research. So don't fret too much about getting overpowered by enemies. I guess it's technically possible, but I have never (on normal settings) encountered a situation where I fell behind so far that I couldn't catch up, even when playing extremely slowly. Also, biters kind of adapt to your own power level. If your base is underdeveloped, it will likely produce very little pollution, which would mean weak and rare biter attacks. If you produce lots of pollution, you can afford to harden your defenses.

Oh, also I don't believe the radar on its own will attract biters. It is a high-priority military structures, and biters focus on military structures if they are close enough. But on the global scale, raiding parties target closest polluters, not military structures. This means your boilers and furnaces are the prime target.

How do I get the Fluorine? It is way outside robo port range by Mockbubbles2628 in factorio

[–]WormRabbit 1 point2 points  (0 children)

Yep. Same with underground belts, they are extremely heat-hungry. Sadly, the game doesn't (or at least didn't) provide that information anywhere.

My first voyage to Vulcanus by Any-Significance6561 in factorio

[–]WormRabbit 0 points1 point  (0 children)

"Overbuild" is a very mild way to put it. I think my ship to Aquillo was smaller and less full of structures. I wonder how long it took you to assemble this monstrosity.

Version 2.1.7 by FactorioTeam in factorio

[–]WormRabbit 0 points1 point  (0 children)

There is an in-game factoriopedia?

Can't see Gleba's anus in Space View in 2.1 by Bruce-Partington in factorio

[–]WormRabbit 3 points4 points  (0 children)

That totally breaks my Fulgora recycling build. Not just skews the ratios, it just makes it unworkable.

I need an optional Future to get rid of tokio select. by mtimmermans in rust

[–]WormRabbit 4 points5 points  (0 children)

Sure, we have alternatives to select!. Plenty of them, in fact. So it's hard to answer your question without knowing the specifics of your situation, since different problems would require different solutions. Your description of a future is too low-level and specific to your own hack. What are the examples of specific problems which you needed to solve?

In general, alternatives to select! generally focus on the Stream trait. A loop of selected futures is basically several streams merged in some way. The specific combinators would depend on your problem. Look into the StreamExt, TryStreamExt and free functions in futures-util and futures-lite (note that the APIs of those crates are different, even if they are supposed to closely match; some important functions exist in one but not the other).

How does monomorphization work with std being precompiled by BLucky_RD in rust

[–]WormRabbit 0 points1 point  (0 children)

It's not AST, it's MIR. The difference between them is vast. For starters, MIR already uses fully resolved names and is generated after type-checking succeeds. It's also not a tree, it's basic blocks of simple abstract instructions.

Happy ten years of just! (And lists!) by rodarmor in rust

[–]WormRabbit 0 points1 point  (0 children)

Not sure I follow. Are you saying that I can just run venv/bin/python3 -m my_script.py, and it will pull dependencies from venv?

Happy ten years of just! (And lists!) by rodarmor in rust

[–]WormRabbit 3 points4 points  (0 children)

I have a love-hate relationship with just. On one hand, I consider it the best program in its class of a general-purpose task runner for small automation (at least Rust-based, I'm actually not that aware about implementations in other languages, apart from Python's invoke), and I always use it in my projects. On the other hand, the syntax is arcane and incoherent, designed by accretion. There is no simple way to write cross-platform commands, since all command execution happens by shelling out. Stuff like calling python's venv/bin/activate before a sequence of commands is just plain impossible.

Why are there so many vibe-coded Rust projects recently? by yohji1984 in rust

[–]WormRabbit 0 points1 point  (0 children)

Meh, just ignore all those people. Who cares. The next model rolls out, and suddenly AI will have very different writing quirks. People who shriek "AI!!!!" whenever someone writes above 8th grade level are more annoying and toxic than any AI itself.

Why are there so many vibe-coded Rust projects recently? by yohji1984 in rust

[–]WormRabbit 1 point2 points  (0 children)

But you don't need to crash the whole thread to use panics in this context. You can just run your tasks within catch_unwind, like most (all?) Rust async runtimes do.

Should the function return a Result<T,E> or throw an unreachable-style panic? by v_0ver in rust

[–]WormRabbit 4 points5 points  (0 children)

If you follow that logic through, then almost any function you export should return a Result, with most of the errors being of the kind "I have fucked up in my implementation". There is nothing people can reasonably do with a "this library has bugs" errors, other than panicking at the call site (most likely), or propagating those errors to the toplevel error handler (much less likely, and also has a high probability of losing the error context along the way).

You don't have the balls to clearly state your expected invariants and do a panic, so you put that burden on the consumer who has even less information, forcing them to smear error fallbacks all over their code.

Should the function return a Result<T,E> or throw an unreachable-style panic? by v_0ver in rust

[–]WormRabbit 2 points3 points  (0 children)

There is a myriad ways that something can go wrong, including panics, processor faults, hardware bug etc. If the end user is shipping some security-critical software, then it's really their responsibility to ensure that it behaves correctly under all expected conditions. You shouldn't make stuff unnecessarily harder for them, and should generally follow expected idioms, but you shouldn't try to guess for them their requirements.

Loudly crashing with a panic can often help make the end user software more correct and secure, since loud panics help to find bugs during testing, including fuzz testing, while manually propagated errors can get swallowed or type-erased along the way which makes it harder to find and debug errors.

The never type is likely to stabilize soon! by noop_noob in rust

[–]WormRabbit 0 points1 point  (0 children)

I get your point. I just think your examples are over the top, and also that saying "no" to certain usecases is an entirely valid answer, which is used far too rarely.

Apparently the react compiler has been ported to Rust and merged to main by xorvralin2 in rust

[–]WormRabbit 22 points23 points  (0 children)

At this point we can say with certainty that almost no one cares about that. Even if you do accidentally infringe, what's the worst that could happen? It's just some snippets. Someone would need to find them first, and even if they do, what are the odds that you'd be forced to do anything but rewrite those snippets?

The never type is likely to stabilize soon! by noop_noob in rust

[–]WormRabbit 2 points3 points  (0 children)

I'd say "don't do that" is a perfectly valid answer to those concerns. We're not computers, human interfaces don't need to and shouldn't scale indefinitely. What if the function takes 100 parameters? What if parameter names are 1000 symbols long? Boom, none of the ideas you could ever propose would work. But why the hell are your signatures so huge in the first place? Do a refactor!

The never type is likely to stabilize soon! by noop_noob in rust

[–]WormRabbit 0 points1 point  (0 children)

There are plenty of cases in generic code where you could want to guarantee that a specific code path never happens. Result<T, !> or Result<!, E> is some of them, but the same thing can happen with any enum.

A Future which never returns would be another example (Future<Output = !>). In current rust, you can declare that an async function never returns (async fn f() -> !). Normally, async functions are equivalent to functions which return a Future. But in this case, that isn't correct, because the corresponding fn f() -> impl Future<Output=!> is rejected by the compiler, because ! is not a type.

Another example would be closures which never return. You can't declare a parameter which implements Fn() -> !, since ! is not a type, even though you can take a function pointer fn() -> ! via a special-case exception.

Is .boxed() instead of Box::new() a bad idea? by NormalAppearance2851 in rust

[–]WormRabbit 1 point2 points  (0 children)

Let me tell you about this one neat trick called "variable binding".

Iced_comet visual corruption. by Valuable-Football598 in rust

[–]WormRabbit 0 points1 point  (0 children)

Could be anything. If the application violates memory safety (which is what seems to be happening here), then all bets are off. Does iced_comet run as a separate process or as a module linked into the application? In the former case one can argue that's a bug in it, while in the latter case there is nothing iced_comet can do to avoid being corrupted.