4 ms·
It is impossible if you're being responsible. You don't choose a technology that could potentially block you from solving problems in the future unless it bring
by ISV_Damocles 3y ago
It is impossible if you're being responsible. You don't choose a technology that could potentially block you from solving problems in the future unless it brings a huge value to you.
Elm's value proposition is mostly being a functional language with an opinionated MVU library baked in, so you can reproduce that value with a better functional language and selecting a similar MVU library in that other language, which means it should never actually cross the value bar above the risk it brings if you need a browser feature it doesn't support and actively prevents you from accessing.
- matsemann 3y agoNow you're moving the goalpost. You said it was impossible to use in production. Which is clearly wrong.
- ISV_Damocles 3y agoI am just clarifying why I consider it impossible. Production is not some place you're supposed to cowboy code, but instead have a reasonable expectation that you will be able to continue supporting it for as many years as it operates, and it's impossible for anyone to responsibly use technology with known limitations that have bitten other real engineering teams that they can find zero workarounds for. If you don't consider that an impossibility for a production environment, then I certainly wouldn't want to work with you on a team with production responsibilities.
- matsemann 3y ago[flagged]
- ISV_Damocles 3y ago[flagged]
- matsemann 3y ago[flagged]
- marc136 3y agoZero workarounds seems overly dramatic, here are a few: https://news.ycombinator.com/item?id=39567011 https://news.ycombinator.com/item?id=39567011 If you want to rely on them for every possible future requirement or rather want to pick another tool is another question :D Anyways, just building the compiler without that check was also not that hard.