Theres this pattern where you make your wealth off dubious means, then one day become born again and start a new life where you gain more popularity and influence by speaking out against the reason you have a megaphone at all. These people interestingly never give away that naughty wealth they now regret so much.
Meanwhile, those with the backbone not to do evil from the start get nothing at all, continuing this warped set of incentives (do evil > get rich > "I'm sowwwy" > zero accountability) for the next generation.
It's also worth noting the framing of the article: "I wasted years of my life in crypto." It's not contrition for the harms inflicted, it's pure self-pity.
Edit: This post is now second in "/best". This is the best of HN? What a depressing thought.
I thought it was really perceptive. Look at what JS was designed to do cf. what it's actually doing these days.
Turns out it doesn't really matter what domain you were originally trying to tackle. If you've stumbled upon a low friction way of achieving other things, people are going to use your tool for those things, even if it's not the optimal tool for those domains.
I dread the JS/TS future, but it's obviously coming.
Terrible, no good, upsetting, false class consciousness-derived take.
The point of the left is to bring prosperity into reach for everyone, not to stroke the hair of able young men in poker dens who refuse to work, and whisper "You're valid."
That's what capital wants the left to degrade into.
More broadly, I think the observation tends to get repeated because C and Zig share a certain elegance and simplicity (even if C's elegance has dated). C++ is many things, but it's hardly elegant or simple.
I don't think anyone denies that Zig can be a C++ replacement, but that's hardly unusual, so can many other languages (Rust, Swift, etc). What's noteworthy here is that Zig is almost unique in having the potential to be a genuine C replacement. To its (and your) great credit, I might add.
>> At its core Zig is marketed as a competitor to C, not C++/Rust/etc, which makes me think it's harder to write working code that won't leak or crash than in other languages. Zig embraces manual memory management as well.
@GP: This is not a great take. All four languages are oriented around manual memory management. C++ inherits all of the footguns of C, whereas Zig and Rust try to sand off the rough edges.
Manual memory management is and will always remain necessary. The only reason someone writing JS scripts don't need to worry about managing their memory is because someone has already done that work for them.
This is relatable. I often find myself starting a reply on here, really thinking it through as I type it out, and then hitting delete on what I just wrote. Sometimes I even hit submit, and then delete a few moments later.
It's just hard to justify engaging. Worst case, I get a fight on my hands with someone who's as dogmatic as they are wrong, which is both frequent and also a complete waste of my time. (A tech readership is always going to veer hard into the well, akshually...) Most likely case, I get fictitious internet points. Which - I won't lie - tickle my lizard brain, just as they do everyone else's. But they don't actually achieve anything meaningful.
Best case is that I learn something. Realistically, this happens vanishingly infrequently, and the signal-noise ratio is much, much worse than if I just pulled a book off my shelf.
I suppose this is all an artifact of time and experience. Maybe I've just picked all the low-hanging fruit, and so I no longer have the patience to watch people endlessly repost the same xkcd strips from fifteen years ago, navel-gaze about tabs or spaces, share thrilling new facts that I have in fact known for many decades, etc. And while I'm very excited for them to discover all these things anew (and anew... and anew...), it's just not a good use of my time and patience to participate.
> It's just hard to justify engaging. Worst case, I get a fight on my hands with someone who's as dogmatic as they are wrong, which is both frequent and also a complete waste of my time.
The three mindset changes I found that really help with this are understanding that:
* You don't have to try and get the last word in.
* Other people are not entitled to your time, especially if they're engaging in bad faith.
* Outside of small and curated communities, there's pretty good odds that you're not interacting with a real and honest person.
So whenever I click into the comment box, I always ask myself "Can I really be bothered with this? Is this really what I want to be spending my free time doing?"
And then I often close the comment box and get on with my life.
Well, if your try and force yourself to engage with multiple people, the site won't let you post that many comments in such a short time period. Which, overall, is a good thing I believe.
It's also bad with games that have been sucked into the live service hell-vortex. I can't fire up a quick game of Madden against the CPU because EA has turned Madden into a multiplayer lootbox casino, so they chuck Linux-blocking anti-cheat on the whole damn thing, single-player and all.
It's fairly telling of the state of the software industry that the exotic craft of 'fixing bugs' is apparently worth a LinkedIn-style self-promotional blog post.
I don't mean to be too harsh on the author. They mean well. But I am saddened by the wider context, where a dev posts 'we fix bugs occasionally' and everyone is thrilled, because the idea of ensuring software continues to work well over time is now as alien to software dev as the idea of fair dealing is to used car salesmen.
> But I am saddened by the wider context, where a dev posts 'we fix bugs occasionally' and everyone is thrilled, because the idea of ensuring software continues to work well over time is now as alien to software dev as the idea of fair dealing is to used car salesmen
This is not the vibe I got from the post at all. I am sure they fix plenty of bugs throughout the rest of the year, but this will be balanced with other work on new features and the like and is going to be guided by wider businesses priorities. It seems the point in the exercise is focusing solely on bugs to the exclusion of everything else, and a lot of latitude to just pick whatever has been annoying you personally.
The name is just an indication you can do it any day but idea is on Friday when you are at no point to start big thing, pick some small one you want to fix personally. Maybe a big in product maybe local dev setup.
That is why I stand on the side of better law for company responsibilities.
We as industry have taught people that broken products is acceptable.
In any other industry, unless people are from the start getting something they know is broken or low quality, flea market, 1 euro shop, or similar, they will return the product, ask for the money back, sue the company whatever.
There should be better regulation of course, but I want to point out, that the comparison with other industries doesn't quite work, because these days software is often given away at no financial cost. Often it costs ones data. But once that data is released into their data flows, you can never unrelease it. It has already been processed in LLM training or used somehow to target you with ads or whatever other purpose. So people can't do what they usually would do, when the product is broken.
"Free" software resulting in your data being sold is the software working as intended, it's orthogonal to the question of software robustness.
Software isn't uniquely high stakes relative to other industries. Sure, if there's a data breach your data can't be un-leaked, but you can't be un-killed when a building collapses over your head or your car fails on the highway. The comparison with other industries works just fine - if we have high stakes, we should be shipping working products.
Imagining that the software will be shipped with hardware, that has no internet access and therefore cumbersome firmware upgrades, might be helpful. Avoiding shipping critical bugs is actually critical so bricking the hardware is undesirable.
This type of testing is incredibly expensive and you'll have a startup run circles around you, assuming a startup could even exist when the YC investment needs to stretch 4x as far for the same product.
The real solution is to have individual software developers be licensed and personally liable for the damage their work does. Write horrible bugs? A licencing board will review your work. Make a calculated risk that damages someone? Company sued by the user, developer sued by the company. This correctly balances incentives between software quality and productivity, and has the added benefit of culling low quality workers.
The kind of relates to proper Engineering titles, unfortunely many countries don't have a legal system in place for those that decide to call themselves engineers without going through the exam, and related Order of the Engineer.
I don't think titles are for anything besides establishing blame. If a company hires someone in a local where the engineer can't be held responsible, the executives and major investors should be held liable. That way things will naturally sort themselves out. Need something unimportant done? Offshore. Have some critical system? Hire someone that can take responsibility.
You don't need formal licensing for this to work, passthrough liability would do plenty. The real sign of success is whether an insurance industry sprouts up to protect software engineers, just like doctors.
There are a thousand and one legal reasons one may wish to block a region, including Europe. From anti-gay speech laws in Hungary, through the VAT/tax obligations that kick in at one cent, to all sorts of watershed rules and disclaimers and alien and unjust laws (such as lese majeste laws, or absurd British 'online safety' laws).
Every day I see Europeans on here sharing tips how to de-cloud and de-America, bemoaning the open Internet, yearning for Balkanisation. Cool. Well, this site does it for you. You're welcome! Enjoy!
> You might as well be making the “I’m okay with my 2004 Honda accord with a tape adapter” argument.
I love how authoritatively you say this, as though this is meant to be just so patently absurd it doesn't require any further argument. This is an attempted reductio ad absurdum, but the absurdum in question fails to actually be abusrd.
Not everyone wants to drop $50K every few years on some liquid-glass-operated subscription-based monstrosity. Some people much prefer cars operated by knobs and dials, that are easy to repair, and dirt-cheap to replace. It's simply superior tech.
This is a wild take. It's one thing to criticise the BEAM for things it's bad at, it's another to criticise it for the thing it absolutely excels at.
The BEAM is built around passing immutable messages between cheap green threads, watched over by resilient supervisor trees. This means no data races (immutability), no hung threads (supervisor trees), no boilerplate (all of this is built in). The performance is surprisingly good, since mandatory immutability permits reference-based optimisations (copying, passing, etc).
The BEAM is, in fact, the perfect platform for the exact use case you describe - fault-tolerant, distributed/concurrent systems.
Not only does it do this all very safely, it uses the absolute most minimal of memory to achieve this.
This video from 9 years ago... 1 million people in 1 chatroom, on a server with 40+ cores and 128GB of memory, one single physical server, it used up about 30 GB of memory. Show me a language that can do this efficiently. In under a second it went to a million different connections. The cores didn't spin up to grind hardcore, none of that. Just efficient lightweight processes running. This isn't even on "raw Erlang" its on Elixir -> BEAM which is impressive on its own in my eyes. I would love to see equivalent videos on similar hardware today in other languages. ;) Please by all mean, show me your JVM application that can handle this.
I also love that he thinks all those languages that are a decade (and decades) younger than the BEAM which has been in production since 1992 are more production ready and tested. I don't think he realizes the origin story to Erlang whatsoever, it was 100% built to be used in production for a major telecoms provider.
There are paths towards redemption - the author could begin by donating every ill-gotten cent to a worthy charity.
What's that? Crickets? Thought so.
reply