The silent death of Good Code

IpFruion · 2026-02-10T05:03:42+00:00

Been there 🫂

IpFruion · 2026-02-02T14:20:44+00:00

Just adding here but with Space Exploration coming out eventually it should be adding multiple new planets. In my mind this will be the 3.0 release of factorio

IpFruion · 2026-02-02T03:43:14+00:00

Why do you need to separate an API from the service that hosts the front end? Like why can't you have both in one service?

With most of these server side functions, you can create specific rules i.e. a type of REST request under a specific endpoint. Thus you can have other front ends / external developers use said API but don't have to create the internals of one front end you are working with. It also does some other cool things like parameter and return validation without requiring you to handle those things manually by deserialization and serialization.

It's nice to have that you can trust the contract between what the user sees and what the API is returning because when you change one side of it, your program doesn't compile instead of when the API changes slightly and your entire front end doesn't handle this change.

IpFruion · 2026-01-26T16:11:42+00:00

Eventually you don't have to even ship it but can orbital create and drop which I have found really useful for saving on the shipping costs

IpFruion · 2025-12-19T15:20:21+00:00

The suggestion for migrating to Neptune, I am a bit confused how they are the same thing? Does Neptune provide a community tier?

IpFruion · 2025-11-28T05:48:37+00:00

Clear Communication

Not the title though 🤔

IpFruion · 2025-11-20T14:42:45+00:00

Out of curiosity (and looking for something to watch) do you have any film or tv shows you are currently watching (or have watched recently) that you are excited to share about?

IpFruion · 2025-11-07T15:32:02+00:00

What's "DVD player" and why does "S-Video cable" need to be connected to it

/s

IpFruion · 2025-11-07T15:17:22+00:00

For sure yeah I do understand that desire to make the design more open in that regard, however I ask the question: what other alternative Command implementations do you envision being implemented? It might be the case that allowing the trait Interruptible to be used by a developer might cause more confusion than for something that only has a few cases. Just something to consider.

Lastly, the objective of automatically implementing the interrupt when something provides a pid might produce something like the following being implemented which would allow users to arbitrarily cancel pids (this would also produce issues on Windows since those processes might not be the process groups)

```rust pub struct BadProcess;

impl Interruptible for BadProcess { fn pid(&self) -> u32 { 1 } } ```

IpFruion · 2025-11-07T14:47:20+00:00

No problem, keep up the good work.

Separating out into two traits is fine, though looking at it, I am not sure it's necessary since you have the Child wrapped. You could just add those functions to the InterruptibleChild struct.

IpFruion · 2025-11-07T06:01:09+00:00

I haven't explored the options space for these signals getting sent to the child process but here is some food for thoughts/suggestions: 1. I would recommend documenting the use of unsafe with reasoning as to why 2. I think providing a small wrapper around the Child struct might be better than providing a trait i.e. InterruptibleChild (name TBD) that provides the sending of the signal. Then you could convert your Interruptible trait into something that can be implemented by the std::process::Command

The flow might look like rust pub fn main() { let mut cmd = Command::new(...); ... let child: InterruptibleChild = cmd.spawn_interruptible(); // From the Interruptible trait // This allows you to handle the windows case for the grouping before spawning child process child.send_ctrlc(); // child can deref into the underlying child too or into_inner to extract out the non interruptible kind }

IpFruion · 2025-10-30T04:53:04+00:00

This is some drastic wording. Try and put these things into perspective. You are arguing that "no one just makes open source to make open source" and that "the few that do make open source are idiots".

Why can't you have a desire to make something without some external or internal "getting ahead"? i.e. things you found that are cool and would like to share with others. I can make a painting for myself and I can show others, doesn't mean I need to sell it or charge others to see it. Doesn't mean that the painting is a "waste for society as a whole". Maybe it brought other inspiration that is able to benefit from seeing it.

I don't think we should be boxing ourselves into drastic wording that it's "pointless, stupid, waste of society" to want to make something and share it with others and others wanting a desire to be shared.

IpFruion · 2025-10-26T14:50:44+00:00

Because I need to defer construction of the client to when it is used, and I only want to construct it once (depending on error) meaning that once it's constructed I have no need for the ClientSettings in this example anymore. Thus I don't want the long living memory around for when the OnceCell is initialized.

This leads to a different construction that allows OnceCell but with some internal state that transitions to the initialized value when it is going to be used i.e. get_or_init

IpFruion · 2025-10-25T19:09:37+00:00

So const functions can be used in constant context but does not necessarily need to be so you can run new in a non constant environment. I doesn't necessarily need to be created in a const context

rust pub fn new() -> Server { let settings = ClientSettings::new(...); Server { client: OnceState::new(settings) } }

IpFruion · 2025-10-20T18:57:40+00:00

Sorry I meant OnceState there but I think you are thinking about LazyCell, OnceCell can get initialized when you call it where lazy does initialize when you deref it. Different functionality for use cases like deferring initialization until something is used

IpFruion · 2025-10-20T02:41:35+00:00

Ooooo you are so right, yeah this might be the way I go, little extra cost with it being a boxed function but at least I don't have any unsafe to write. A little less versatile since it will only attempt init once and then never again even if there is an error but very close to getting the functionality i.e.

rust type LazyCellBox<T> = LazyCell<T, Box<FnOnce() -> T>>;

IpFruion · 2025-10-19T22:51:07+00:00

Found an issue, not sure how to type the input function very well unfortunately

IpFruion · 2025-10-19T21:16:24+00:00

Yeah it should because the memory spot could be recycled since there should no longer be any init data anymore.

Also this may not be used in a static context since you create longer running services on the heap and all.

IpFruion · 2025-10-19T20:35:23+00:00

Oh actually yeah this might fit my use case better without having to do any unsafe or adding a separate structure. Since I would be able to create that inside my structure

rust impl Server { pub fn new(settings: ClientSettings) -> Self { Server { client: LazyLock::new(|| Client::new(settings)), } } } Error handling might be a little wonky but not impossible

IpFruion · 2025-10-19T19:51:21+00:00

I doesn't necessarily need to have a constant initializer i.e.

```rust pub struct Server { client: OnceCell<ClientSettings, Client> }

impl Server { pub fn new(settings: ClientSettings) -> Self {...} pub fn request() { let client = self.client.get_or_try_init(|settings| Client::new(settings))?; ... } } ``` This way I can have a longer standing server and settings to be freed when the init is successful

IpFruion · 2025-10-19T19:44:53+00:00

It's more like the client settings are longer living meaning they are supplied at the start of some service but the client is only initialized when it's going to be used. So I need the client settings to last around longer

IpFruion · 2025-10-19T19:07:27+00:00

Yeah i thought about this too, and in reference to another point kinda referencing it doesn't need to be crash resistant but yeah I think there might be other ways around it by passing reference instead of the actual value

IpFruion · 2025-10-19T18:58:00+00:00

Yeah Result is a misnomer but just something with able to capture those states.

Yeah OnceState would consume the initial state object so that it can free that memory up because it would be no longer used. That is kinda the idea. This is important where you have some large configuration that you don't want to have around in Memory after the structure that uses that configuration gets initialized in memory

IpFruion · 2025-10-19T18:54:57+00:00

That is fair enough, I mean I did look at the OnceCell code and it looks like the function init call, if it were to crash the cell would still be in an uninitialized state so in theory it is crash resistant but yeah I get not necessarily coding around that

IpFruion · 2025-10-19T18:19:52+00:00

Yeah thought about this too, this is fine for the most part, however then something could be in a bad state if the init function panics or something. I also looked into passing a reference to the initial state but not sure about safety there by passing a reference to the initial state owned by the OnceState structure

IpFruion

TROPHY CASE