Hacker News Reader

Comment by lixtra | Hacker News Reader

Depending on the situation a write unsafe fast fix later maybe the more economic approach. Especially if the code is more exploratory, changes a lot and large parts will be finally discarded.

View on HN

It seems to me that letting yourself work under the assumption something may be easy to fix later when you add the safety constraints back is just asking for major pains when it isn't easy. A wrong assumption at that level can render your entire algorithm unworkable if your plan was to make it safe in the end, since some patters just don't lend themselves to easy expression in rust. Then you're stuck with the choice, leave it unsafe and worry about it from them on, or rewrite it safely using an altered or entirely different algorithm. That doesn't seem like a gamble that's worth it to me.

Even for exploratory code. Unless it's such a performance critical portion of the project that I'm willing to write it in a different language for speed, why bait myself so?

If one of my goals for a project is to write somewhat functionally, I wouldn't start off with an exploratory approach using procedural techniques. I think we can all see what I'd probably end up with in the end, and it might work, but it probably wouldn't have some of the attributes I was hoping for.

I've found that more often, it should be reworded as "unsafe fast, painfully maintain without the resources to ever fix later".

The number of TODO's that litter code in general, or issues file to "cleanup" are generally significant. You're making a great point that accruing technical debt at the cost of safety, is quite possibly technical debt, like all other, that will never be paid down over the life of the software.

I completely agree.

What is this "fix later" you speak of?

Usually the "later" part never comes, specially in consulting, where there is only one shot to implement each module.

Reply on news.ycombinator.com