@chris echoes my (limited) experience as well. I love the idea of a linux laptop and practically it consumes time I don’t want to spend. Even less software is available on an arm64 architecture right now.
P.S. a couple typos:
@technomancy awesome! I started roasting a couple years ago on a Behmor and today I’m awaiting delivery of my first solid drum roaster! Enjoy the journey!
Any and all answers are greatly appreciated. No judgement whatsoever. Asking this for research on a WIP article:
Do you #selfhost ? If so:
- What do you host yourself?
- Do you use an existing toolchain (Ansible/Puppet scripts, Yunohost, etc)?
- Do you run it bare metal, virtualized or containerized? Which one?
Why not both?
Though productivity and performance are not the only factors, I could see a time in which a language with similar values to what the Ruby community values but with far better performance reaches parity with the Ruby ecosystem for productivity - that would be interesting.
Maybe this will be Crystal, or maybe Ruby's JIT will catch up, or have the option of compiling to LLVM in the future, who knows?
Now I'm considering that perhaps developer time is even _more_ valuable when there's no profit.
Hardware only gets cheaper, and Ruby keeps getting faster.
E.g. decentralized services like mastodon, or my own little ARM home server - since there's no profit, I need to squeeze all I can out of that hardware.
This in mind, I tried to build something simple in Crystal and wasted an insane amount of time shaving yaks and gave up. I'm sure I would have finished the project in Ruby in the same amount of time - probably partially because of my familiarity but more because the libraries are so much better.
It's clear to me Ruby/Rails ecosystem still has large productivity advantages that make it competitive in the market.
The line for years has been, developer time is far more expensive than machine time, so if productivity outweighs performance, then 🤷
However, I have wondered if the same thing holds true if profit isn't involved.
@nateberkopec what strikes me about this is also that they've calculated it's cheaper to scale Rails to that level than swap out parts of their stack. Could be some sunk cost fallacy at work, but I doubt that's entirely it. At that level they must be getting advantages
@openrisk @humanetech I’m no expert but this idea is interesting to me. I would hypothesize the opposite - I think it’s generally more efficient to share resources on one larger machine than divide it up - you would have more resources wasted by idling. This seems apparent with memory, but maybe there’s more nuance with electricity.
@nateberkopec also my primary need for preventing duplicate jobs is pdf rendering. Re-running isn’t a problem but because those jobs can take a while, don’t want multiples running at the same time.