> these types of compliance efforts can mean completely redoing multiple core systems to handle privacy, wipeout, audit, reporting, per-location policies, etc etc.
Maybe the phrasing is unfortunate, but if compliance to the law requires a “redoing”, launching in that market was never a priority in the first place. That’s a completely legitimate choice, but usually companies whining about regulations are making a financial decision rather than an ethical one.
Of course not. To me, HN’s content is pretty similar what pop tech websites had 20-30 years ago.
One valid question, though, is whether or not you should add more pop tech content to your information diet. That, of course, is up to you. What makes HN such a good information source are experts actively looking for knowledge and being kind enough to share their findings here. That is something else you should consider—not the sharing part, but actively looking for it. You will consume objectively less “data”, but it will be much more meaningful.
Well, cargo cult programming is definitely a thing, and has been for a long time. It may “deliver value”, but it is not guaranteed. I believe entrepreneurs have an easier time having AI do the work for them because their value assessment framework is decoupled from code generation proper.
This is industrial-grade FOMO. They will take the jobs of the first handful of people. The moment it is obvious that LLMs are a productivity booster, people will learn how to use it, just like it happened with any other technology before.
It is very common to interpret taglines by their face value, and I believe the author did just that, although the point brought up is valid.
In order to “let it crash”, we must design the system in a way that crashes would not be catastrophic, stability wise. Letting it crash is not a commandment, though: it is a reminder that, in most cases, a smart healing strategy might be overkill.
Maybe I didn’t make myself clear. “Let it crash” is not something that should be thought of at the component level, it should be thought of at the system level. The fact that the application crashes “gracefully” or not is not what is really important. You should design the system in a crash-friendly way, and not to write the application and think: “oh, I believe it is OK to let it crash here”.
My personal interpretation is that systems must be able to handle crashing processes gracefully. There is no benefit in letting processes crash just for the sake of it.
Actually, now I thought about it, I know exactly what irked me about the approach. I hope the author takes it as constructive feedback:
Saying "let it crash is a tagline that actually means something else because the BEAM is supposed to be used in this particular way" sounds slightly "cargo-cultish", to the point where we have to challenge the meaning of the actual word to make sense of it.
Joe Armstrong's e-mail, on the other hand, says (and I paraphrase): "the BEAM was designed from the ground up to help developers avoid the creation of ad-hoc protocols for process communication, and the OTP takes that into consideration already. Make sure your system, not your process, is resilient, and literally let processes crash." Boom. There is no gotcha there. Also, there is the added benefit that developers for other platforms now understand that the rationale is justified by the way BEAM/OTP were designed and may not be applicable to their own platforms.
If I sounded snarky that wasn't my intention. At the end of the day though it doesn't feel like you read the article which was clearly in a different context than the one in which you responded. FWIW I didn't expect this small article speaking to a small audience (Elixir devs) to make the rounds on hacker news.
I agree on the importance of defining terms, and I think the important thing here is that "process" in Joe's parlance is not an OS level process, it is one of a fleet of processes running inside the BEAM VM. And the "system" in this case is the supervisory system around it, which itself consists of individual processes.
I'm critiquing a common misunderstanding of the phrase "Let it crash", whereby effectively no local error handling is performed. This leads to worse user experiences and worse outcomes in general. I understand that you're offering critique, but it again sounds like you're critiquing a reductive element (the headline itself).
I did read the article. I concede that I might not have understood it. Again, I never said it is wrong, but rather that it has a blind spot. I am familiar with Joe Armstrong’s work because I worked on a proprietary (and rather worse tbf) native distributed systems middleware in the past.
I actually skimmed the article before posting. I have some exposure to Erlang, but not to Elixir. As I’ve already mentioned, I think the author’s covering of application behavior is OK, but there is more to the tagline than meets the eye.
I am not sure if I agree with his conclusion, but some economists are of the opinion that countries in Northern Europe used the euro as a political tool to protect their own internal markets by making goods produced in the poorer countries of the Eurozone less competitive. If a country’s government could previously deflate their own currency to make their exports more attractive, they cannot do it anymore since they joined the Eurozone.
OK, I've heard of the second part about being unable to devalue the Euro because it basically reflects the economic power of the Eurozone as a whole and that e.g. Greece leaving the Eurozone could have helped Greece in 2008. But as a whole I'd guess that especially export-focused Eurozone members like Germany would welcome a depreciation of the Euro. At the very least I think they would not try to bolster it.
It does, however, not bring me any closer to understanding the "exporting unemployment" statement. I guess it is some kind of multi-step reasoning that is eluding me, or maybe it is an example of a control illusion? I don't know.
> But as a whole I'd guess that especially export-focused Eurozone members like Germany would welcome a depreciation of the Euro.
Yes, but only if it is guaranteed that their imports would depreciate similarly. Otherwise, say, Germany would devalue the Deutsche Mark but then run into the risk of importing produce from The Netherlands at a higher cost.
> It does, however, not bring me any closer to understanding the "exporting unemployment" statement.
The monetary policy after the 2008 crisis forced poor countries to cut public spending so that industrial economies could be bailed out. As a metaphor, the potentially unemployed factory worker from Germany was replaced an actual unemployed public service worker in Greece.
Not the economy as a whole, but there are some aspects of the economy that are. Indeed, negative externalities can be worse than a zero-sum game to those affected.
To be frank, this whole “the economy is not a zero-sum game” argument is kind of a meme at this point.
Maybe the phrasing is unfortunate, but if compliance to the law requires a “redoing”, launching in that market was never a priority in the first place. That’s a completely legitimate choice, but usually companies whining about regulations are making a financial decision rather than an ethical one.
reply