1,264 karma · joined September 26, 2011
Twitter: @{username}
Email: {username}@gmail
[ my public key: https://keybase.io/nateabele; my proof: https://keybase.io/nateabele/sigs/tffmWJKPOzE_9N5C74rXo42NaKXoMsogz1xMZFIkIMk ]
I can happily pick up the torch on everything except the PCB design.
All it would take is for one of them to require senior leadership to take a certain number of flights (per year, let's say) on each new model of aircraft they ship. This would be solved immediately.
¯\_(ツ)_/¯
[0] https://www.fdareview.org/issues/theory-evidence-and-example...
And this improved technology was an inevitable, foregone conclusion?
People make arguments like this as if it was some passive thing, as opposed to thousands if not millions of conscious decisions to improve turbines, airframes, and myriad other technologies, then actually implement them in real aircraft, then acquire and deploy a commercial fleet.
People made these decisions because they were incentivized to trade time and money today for material improvements tomorrow. Why do you think that might have been?
Hint: think about industries where there isn't much competition. Do we see similar improvements there, usually?
What's more, though, is that a good type system will help you 'Make Impossible States Impossible'[0]—even more behavior you don't have to test because bad behavior is simply not representable in your program.
Tests are strictly more powerful in the small, because they can be arbitrarily complex, but I would say a (really good) type system is more powerful in the large, because you get way more leverage in terms of overall program correctness.
A lot of my personal projects are in Elm (yeah, yeah, bring on the hate)—the models are really well-defined, but the test suites usually only have a handful of tests of behavior I really want to verify. Haven't even played with the property checker yet, but again, that's something that is strictly more powerful than unit tests, but you can only get it* if you have a type system.
[0] https://www.youtube.com/watch?v=IcgmSRJHu_8
* Okay that's not really true: see clojure.spec in Clojure—but there are so few counterexamples that it's true for most practical purposes
Whatever part you played in that, well done, and thank you.
I got to speak with him briefly afterwards, and to say that he had a chip on his shoulder would be putting it too strongly, but there was definitely some kind of an 'edge' there.
I spent 5 years in fintech and touched over a dozen financial institutions. You're not thinking creatively enough. Plus everyone has to do KYC/AML, including two-bit money transmitter startups.
> And compliance issues by HSBC et al is a direct result of a lack of proper AML/KYC systems and processes.
Hah, okay. Even if that were true, just keep walking down the menu: JPM knew Jeffrey Epstein was their customer, too.
1) That AML creates a massive honeypot of data for hackers, housed at institutions which historically have structural challenges with technology investment
2) The real, material downsides felt by non-criminals, as expressed by many others in this thread
3) That the sum total financial activity of criminals who would benefit from the lack of AML is likely a rounding error compared to money laundering carried out by banks like HSBC
4) The philosophical position that governments are entitled to dragnet surveil law-abiding citizens in order to combat crime
Think of it this way: do your friends or family care about you based on your ability to perform to a certain standard? Of course not! (At least I hope not... that's its own problem).
Once you no longer identify with your work, you're able to take the emotion out of it, because it no longer affects how you feel about yourself. When you get to that point, you'll be able to see every experience as an opportunity to learn and improve, no matter who or where it comes from, which is the ultimate goal.
As far as dealing with other people, it's a lot easier once you've figured yourself out. You're better able to recognize that everyone's on their own journey, and their ability to deliver feedback in a constructive way is more about them than it is about you. Once you internalize these things, you'll start to care a lot less about their opinion of you.
Also, from my own experience, learning to confidently look stupid (i.e. admit that I have no idea about something), has been one of the biggest and most successful hacks of my career.
In summary: You are not your work. Focus on your own journey, and unsubscribe from giving a crap about what other people think about you. Conversely, it'll earn you more respect.
I still don’t understand this idea that labor supposedly has some sort of intrinsic value. The value is derived from the labor being done in the context of a system created by someone else. As others have said, if you want to reap the full value of your labor, you’re free to go it alone.
Some friends run a platform called Transloadit, and they used to use little bot icons[0] for each of their processing jobs, and that seems to have worked well for them.
[0] https://transloadit.com/docs/transcoding/handling-uploads/up...
Because that's worked out great so far?
In every case I can think of, the government (usually because it's already captured) only ever serves to further exacerbate the issue.
Yeah... no comment.
"Early in life I had noticed that no event is ever correctly reported in a newspaper, but in Spain, for the first time, I saw newspaper reports which did not bear any relation to the facts, not even the relationship which is implied in an ordinary lie. I saw great battles reported where there had been no fighting, and complete silence where hundreds of men had been killed. I saw troops who had fought bravely denounced as cowards and traitors, and others who had never seen a shot fired hailed as the heroes of imaginary victories, and I saw newspapers in London retailing these lies and eager intellectuals building emotional superstructures over events that had never happened. I saw, in fact, history being written not in terms of what happened but of what ought to have happened according to various ‘party lines’."
This has always happened, and it's still happening. Anybody remember the Ghost of Kyiv, or the 'fuck you' surrender?
No, 'everything we see out of Ukraine' is not a lie (which in itself is a false dichotomy: we've seen plenty of 'facts' framed in a way that's explicitly misleading), but the overwhelming preponderance of the evidence of the past ~year, not to mention the rest of human history, suggests that a lot of it probably is.
'Escape hatches' are definitionally exceptions to the rules, whereas effects in React are standard practice.
Constraints give you freedom because they allow you to make guarantees. Checksums, reliable test suites, and good software abstractions are all examples.
> I don’t want to be forced to use go or rust - maybe I’d like to use bash, node or even the jvm depending on the problem I need to solve.
Those are runtimes, not languages. Here's a list of languages that compile to WASM: https://www.fermyon.com/wasm-languages/webassembly-language-...
IMO bash wouldn't make sense, but Java and Kotlin are there, as well as AssemblyScript, which is basically TypeScript.
I'm happy to hear all of that and, yes, I believe you did.
> Docker [...] is singularly focused on the development experience, i.e. the inner loop of code/test/build, not the outer loop of deploying to production (which is largely controlled by cloud platforms and k8s at this point).
I would push back on this a bit: although it may not be a focus, and that's totally fair, deployment is undeniably part of the developer experience, particularly within the context that containers were born into (i.e. DevOps values of continuous deployment & no silos). I certainly wouldn't presume to tell you what to do, but I would suggest that Docker is uniquely situated to address developer experience from end to end.
> We will happily work with anyone interested in working with us to improve the production/deployment landscape for Wasm
If you gave us a path out of containers for the end-to-end developer experience, I believe many of us would be eternally grateful. Let me know how I can help.
So, to your point, the opportunity here is to provide WASM-native alternatives to existing container-specific technologies, that are more composable by design, because they don't have to deal with the complexity of trying to ape an extra operating system just to run some software.
For example, I'd love to see container orchestration be supplanted by something like a la carte Erlang-style service discovery—that's a primitive that could easily be composed with other primitives, and wouldn't result in the combinatorial explosion of nouns we see in systems like k8s / Swarm / others.
Then we immediately trade any semblance of sanity for container orchestration.
(And please don't try to convince me that Kubernetes is sane. I operated a production SaaS on it for 4 years, and spent another year at a DevSecOps consultancy with 40+ CKAs—sanity and familiarity are not the same.)