Hacker News new | past | comments | ask | show | jobs | submit | ravloony's comments login

Absolutely. I was leading a team a while ago and I instituted this practice to good effect.

Conversely, I was called by a company that I had built an app for previously. They had not upgraded the framework it was built with (Laravel), and ended up offering me consulting days to jump several versions. The irony is that the job ended up being quick and easy to do.


Laravel is relatively painless to upgrade as long as you have the autonomy to get the work done in a timely manner. I've seen upgrade projects drag on for weeks causing issues upstream since most of the team was still working on the product or fixing bugs while one developer was tasked with the upgrade.

Did you use a tool like Shift to help with the upgrade? What about frontend dependencies? The recent move from Mix to Vite is great, but if you have a large frontend, it can be a major PITA to update. More so if you have any sort of custom webpack configuration.


Yes, Laravel does a good job of making upgrades relatively simple


I also came here to say this. Structured concurrency gets rid of these types of problems.


This is exactly why this thread is full of slightly insecure comments making vague predictions. I'd suggest to most of them to get off HN and back to work, now is the time to make yourself useful!


Ah, but that is not what he wrote. He never claimed the toilet was broken because he was broke, but due to bad organisational skills.

He then used the story to illustrate the fact that such things can become fond memories, and related _that_ fact to poverty.

At least, that is how I understand the text.


anecdote incoming!

In my previous gig, we had a premium website hosting platform, and our incoming clients would usually want their old inbound links to keep working. Over time, this meant a few hundred thousand autogenerated rewrite rules in Nginx. This was causing Nginx to use about 10G of memory, so restarting it, which we had to do every time we added a redirect, was an issue.

I replaced this with a small reverse proxy written in rust that loaded all of the redirects from postgresql into a cuckoo filter. Adding a redirect was an INSERT, followed by a NOTIFY to let the proxy know to add the redirect to the filter.

Putting it all together took about 2 weeks of swearing at the compiler, but it never had an issue in production, and used about 1M of memory, while adding less than 1ms of latency, or about 4ms in case of a filter hit. Cuckoo filters can have false positives, so if a redirect was found, we still had to check in the db table before returning 301.

As far as I know it's still working fine, and I use rust whenever I can.


Interesting! Any chance you can share a few tips to get started doing the same? (eg any crates to use or other tips). I'm currently looking for a rust learning project and building what you described really hits the mark!


It seems to me like nix fits all of those criteria.


This is one of the reasons why I chose Purescript for my team's projects. Also it's got a more complete type system, a simpler FFI, and compiles to less javascript.

This is not to say that Elm is bad. O think it's great as a path into FP, and in fact _was_ my path in. But it does limit you in what you can do and learn.

Also, Purescript has this interesting property of being hard to learn (because it is powerful), but dead simple to use (because it compiles to JS). So you only really get stuck on figuring out how to do things in PS, as opposed to how to get PS working, and therefore every time you get unstuck, you have leveled up. So it's hard, but rewarding.

I'm probably off topic by now, but I do think that Purescript in the frontend is a better option for solid application development.


Purescript looks like a great language and if you want to dive into the deep end of typed FP, then it looks like an excellent choice. One reason I went with Elm for our in-house customer support app, was because of the simplicity of the language. It does result in more boilerplate but I don't think the project would have been successful if the learning curve was steeper.


I think https://purescript-users.ml is running on Discourse. It's quite young though.


This is actually a very good idea. Time is the one asset we all have. Community service is also a good idea, but it lacks the immediacy of both fines and your suggestion.


I don't subscribe to this at all. I think that the better explanation is that the people who are negotiating with the EU are, almost to a man, convinced EU-philes (for want of a better word). And so they favour the EU position in the negociations, instead of just implementing the will of the people.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: