HN user
The intern didn't make them "look bad". They were bad. I mean, I'm sure that they were great developers in some sense, but refusing to ever update your toolkit because you've always gotten along just fine with what you already use is a great way to get sped past by the next generation who start from a better baseline.
My suggestion is not to blow up the moon, but to launch payloads from earth via nuclear pulse propulsion containing extremely low albedo material, like coal dust, and create an artificial ring that way.
Yes! It says the rings would have caused a cooling effect. Vindication that my mad science plan of giving the Earth an artificial ring system to combat climate change is viable!
Do the job you want, not the job you have, eh?
I'm sure there's a set of shaders that will basically let you emulate the fixed function pipeline without having to endure the shitty performance implications of passing a vertex list to the GPU every single frame.
I've seen this video and while it's informative overall, it's also about 10 minutes or less of information stretched out to 30 minutes. super repetitive throughout and trying to constantly tickle you with the idea that resolution to questions are coming any second now.
a pipe 230m tall with the bottom at ground level would experience the same hydrostatic pressure as water 230m under the ocean. the pressure comes from the weight of water above it, not distance from sea level. this is literally how water towers work.
I feel like with the skyrocketing costs of education in the US, fixing the problem is probably a better path than "burn it all down"
Put that coffee down. Coffee is for closers.
the dream of every ticket seller is to extract as much money as each ticket user is willing to pay. knowing who's getting tickets means more opportunities for differential pricing.
all I've heard about this guy is that he ignored warnings, cut corners, and that he was a wealthy dude who's never had to deal with anyone telling him no his entire life. in all the reporting I haven't heard anything at all that would make me say "he got that right at least" and I challenge anyone to come up with something.
also when engineers disagree with each other you generally don't continue to use the topic of disagreement as a passenger vehicle. Finally, the guy making decisions wasn't an engineer and as far as I've heard no actual engineers who were well informed on the subject and experts in the domain were supporting this guy.... so what you should have said is "management disagree with engineers and dismiss their opinion all the time, often leading to high public catastrophes like the Challenger and the Titan"
This wasn't some new gig economy venture, or some software idea. This was a submarine carrying tourists to one of the most dangerous places on earth.
There are companies dedicated to certifying maritime vehicles and standards against which they need to be built and tested, and Stockton Rush explicitly rejected them because he felt that they were stifling to innovation. Additionally, the people who told him that he was needlessly endangering people's lives were experts in their fields. And again, it wasn't just "someone", it was virtually everyone with experience in super-deep submersible operation.
The idea that just because there are often naysayers who claim some big projects are impossible doesn't mean that there aren't situations where they should absolutely be listened to and taking passengers on a submersible down to the Titanic is absolutely one of them. This guy played fast and loose with safety and if it had just been him down there, that would be fine, but he managed to bamboozle a bunch of innocent people into it as well.
Go and Rust both strike me as languages made by people who HATE Java/C++ style exception handling but thought the best way to deal with it was to invent a language that constantly punches you in the face.
the fact that the most popular Go IDE actually has logic to automatically fold and hide the constant error handling boilerplate and that people seem to have no problem with that makes me feel like I'm taking crazy pills.
please get in touch
How? You haven't provided an email or website.
My take is "don't use the same channel for internal coms as for customer coms". That way training could make it clear:
* Supervisor communication will always come through Slack, or email or some other mechanism. * Never trust that the identity of anyone on the phone is someone internal unless you initiated the call.
solved by Web3.
To the extent that web3 is even well defined, no it absolutely doesn't. The blockchain space right now is rife with scams and people getting stuff stolen from their wallets. At best it makes it harder for the average user to understand how to be secure and at worst it changes this scenario from "I lost my facebook account" to "I lost control of every asset I own and my entire identity".
Right, but you don't want anyone in the world to have access to your home computer and printer, right?
You're talking about a different problem: How can I extend the concept of my "home network" to the devices that I use and trust regardless of where I am? I'd argue that this is something that suggests that VPN functionality should get built into gateway devices.
Regardless, I don't want scammers in Malaysia port-scanning my 10 year old printer that's never going to get a security update.
I don't think it's just an OS issue, because people often want promiscuity within their home network, but want a moat and drawbridge keeping the rest of the world from that network. There's too much value in home / office situations where you want discoverability enabled, but only to other devices behind your gateway to the internet at large.
I'll certainly grant that unchecked exceptions are problematic for static analysis, but in regards to your second point, I don't feel like Rust has actually avoided creating "a separate syntax". It's created a different, more complex syntax which must be adopted inline in your actual normal code path, obfuscating what your code is actually expected to do under non-error conditions.
IMO, one of the most valuable pieces of exception handling is a distinct separation between your error logic and your non-error logic, which makes methods easier to comprehend. I also feel like the existence of the ? syntax is a dead giveaway in this regard because it's a fig-leaf trying to cover up the most egregious parts of the code where you'd otherwise have to be write the frequent "if error then early return error" statements which plague Golang.