drones are probably the boss level of asymmetrical warfare ever seen
cheap to make - if you care to do so -- to stop them your enemy has to deploy expensive anti-missile tech -- thereby in a war of attrition the person who quickly churns out drones wins.
drones can also destroy -- more expensive sites like oil plants, factories etc that cost XXX more than the drones
and the person who flies the drone if not automated -- can be safe somewhere
That was years ago. Today's armies have plenty of cheap anti-air weapons deployed everywhere, and they manage to intercept the vast majority of long-distance drones cost-effectively.
The Gulf War era world, where a small professional force using expensive high-tech gadgets could win a war without the enemy being able to fight back, is gone. Today you still need the small high-tech force to win, but you also need a larger cost-effective force for defense.
Didn't we just see something like 15% of Russia's nuclear bombers wiped out from a drone attack last year?
A guy got close enough to shoot at and almost kill a Presidential candidate during the last election -- imagine how different things would have been if he had just used something like this[0] instead.
The first time someone attacks an outdoor music festival with drone strikes like that asshole who shot up that concert in Vegas is going to change society for the worse. :-/
That particular attack against Russian bombers was done by undercover saboteurs working deep inside enemy territory. The drones being discussed here are essentially cheap cruise missiles. For example, you have a ~200 kg drone carrying a ~50 kg warhead that is launched using a rocket booster and capable of flying 1000+ km. In Ukraine and Russia, 80-90% of such drones are routinely intercepted by cost-effective air defenses.
The question I ask myself to this day is why they began switching to React. It made no sense at all for me. Like it was a working product, so why would you switch?
I get that new developers might be more familiar with React, but then again, as soon as the trade-offs were apparent, I would've pulled the plug.
But they said: Buckle up, everyone, let's ruin our product!
Hm, I didn't realise they'd moved to React. I remember reading years ago that it used jQuery for the longest time but they put in some effort to move to pure Javascript (maybe using web components).
If you don't need concurrency, then you simply don't need to define any concurrency segmentation. But the real world is wildly concurrent, and most programs will eventually benefit from some degree of concurrency (especially when you can leverage that concurrency into parallelism), so it's beneficial to work in an environment where that improvement can be incremental rather than "we need do a complete rearchitecture to support n=2".
"letting it crash" in BEAM terms often means "simply redo the process". The difference is you end up defining your "transaction" (to borrow database terminology) by concurrency lines. What makes it so pleasant in practice is that you take a bunch of potential failure modes and lump them into a single, unified "this task cannot be completed" failure mode, which includes ~impossible to anticipate failure states, and then only have to expressly deal with the failure modes that do have meaningful resolutions within a task.
With that understanding in mind, I'd argue that nearly all business cases benefit from the BEAM. It's mostly one-off scripts and throwaway tools that don't.
> what would it look like if you didn't need concurrency at all - would simply having a step by step process enough e.g using DAGs
What business systems don't use concurrency in some form? I can only think of the simplest data processing tasks written for batch processing. But even every embedded system I've ever developed or worked on used concurrency. Though for older systems this was often hand rolled, and as error prone as you might expect. For newer systems (developed this century), it was often done using a task system baked into the embedded RTOS.
I also agree - however the ART of making software that's simple and works is disappearing fast.
One of the most impactful things in my career was watching Simple Made Easy by Rich Hickey
our industry is part engineering | part art (i.e having taste) - A.I doesn't have taste (hence why vibe coding) doesn't work - the art of engineering is reducing the amount of code you've to write
it's not about saying YES to every feature - but saying NO and shipping the most impactful feature in the smallest amount of time. sometimes it's about stepping back to relearn so you can do things the right way.
whereas AI is about producing the most amount of code possible - which is the very antithesis of Software Engineering
> the art of engineering is reducing the amount of code you've to write
I would argue that it's _scaling_ software development?
Making it so that you can create bigger programs: that accomodate more contributors, more requirements, faster, with more features, while being more correct, etc, without everything collapsing into spaghetti and chaos?
Historically, keeping a close eye on lines of code spent helped a lot along most axes. Finding ways to keep "code spent" down will remain very valuable but I don't think it's the _only_ way to scale?
Along the way we've developed architecture conventions, useful interfaces, test practices, standards, protocols, plugins & extension points, package repositories, etc. There are also social technologies like mailing lists, SIGs, bdfls, modern project & product management, etc etc.
To the extent that simplicity is measurable (less LoC spent, less code coupling, less cyclomatic complexity) it seems like it can be addressed as an optimisation problem and automated.
one thing it mentions is how in Europe etc - places with limited land quickly pivoted to monogamy was due to limited resources. in places with limited resources, raising kids under monogamy has shown to produce the best results i.e kids tend to have better future success.
however, even though legal systems in the west restrict polygyny - due to inequality - its coming back - we already see that with onlyfans etc / high levels of prostitution in younger western females - the richer guys can maintain a harem - while the plebs become sexless incels.
>> yes we over-hired during covid because i incorrectly built 2 separate company structures (square & cash app) rather than 1, which we corrected mid 2024. but this misses all the complexity we took on through lending, banking, and BNPL. and that we’re now targeting $2M+ gross profit per person, 4x our pre-covid efficiency, which stayed flat at ~$500k from 2019 until 2024. we have and do run an efficient company... better than most.
Block job listings were all over for a couple years. I thought it was odd that they were hiring so much given what we know about their business lines. I assumed there were some internal projects or new business lines.
I feel sorry for anyone who joined recently and then got laid off because they company wasn't planning properly.
Payment processing is one of the most tightly regulated, and some might say corrupt, industries. Replicating the tech wouldn't be difficult. The social and regulatory part is effectively impossible for anyone who's not already in the inner circle.
Ironically Square isn’t good at anything in particular. Square fails to have a good point of sale (Toast wins) and fails for online store fronts (Shopify wins). Square is in a position where they spread themselves thin and aren’t at the top of anything in particular.
With light CRM, Staffing, and Banking tools, it seems like Square's strategy is to be best-of-suite for small businesses rather than best-of-breed.
I've never seen Toast outside of bars/restaurants (although they are ubiquitous in that segment). Every other service or retail shop has been Square, especially farmers markets and craft fairs.
i think they dont have a great moat in their individual offerings, but across square, cash app, and afterpay they offer a pretty good suite of products for the entire transaction stack.
It doesn't matter if the main reason is they over-hired. Financial services is going to eat it up, there are eyes going wide all over the place in the C-suites, I am certain. Companies/Funds that own other companies see an opportunity to reduce input costs (human costs). Even if over-hiring and AI are both explained reasons, the second one is going to win out as it's a narrative that lines up with what their goal is, to reduce costs.
Now the question is will that sustain? Are 50% of us doomed? Is it temporary, and a reversal will take place? Will it start and sputter?
"over-hired" seems like mostly copium of engineers being very afraid that their company will discard them like this and are trying to rationalize why they won't follow.
There was obvious over-hiring in the couple years after COVID while interest rates were low. A lot of companies corrected and laid off staff when that stopped.
This was before LLMs writing code was a daily discussion topic. Blaming every layoff on AI is mostly people connecting trending headlines together.
I don't think it's copium because it doesn't really matter if it's due to AI or COVID-era ZIRP-infused overhiring. If your company hasn't done multiple rounds of layoffs since 2022, they're going to come.
reply