Most of the “money American tech brings in” comes from the magnificent seven. US software engineering salaries are high even outside of those. In fact, it's high even in companies that are merely burning investor's money.
there are plenty of american cos that bring in tons of money that are outside the mag7.
vc funded companies pay high so they can grow and eventually bring in lots of money, and america has the deepest vc pockets so it reaps the rewards of the biggest exits
Why would they "normalize"? Do you think Microsoft, Amazon, Apple, Amazon, etc. are going to relocate to the EU or something? Are all the venture capitalists going to flock to Spain?
The mechanics driving compensation arent "normal." American pay is driven by the underlying mechanics. The USA didn't just randomly win at tech.
There are real factors that could reduce US compensation, but calling that "normalization" assumes the current gap exists for no reason. It exists because the US software industry is structurally different from most of Europe.
Globalization? Look at manufacturing, it moved to a country where things are a lot more affordable. In a world where remote collaboration gets easier and easier and you're able to pay software engineers half the world away a lot less there's no way it wouldn't have an effect on the domestic market.
feel like that narrative has died given the return of RTO. In person work is really valuable
and the talent is just better in the US on average (mostly because of immigration!), software is so levered one good Eng can 1000x the value of a bad one
If demand for software developers decreases due to AI, salaries are likely to decrease as well. Take the academic world for comparison, where supply of very smart people vastly exceeds the demand.
I suspect demand for software is nearly infinitely elastic, so far we’ve seen demand and comp for engineers increase as coding agents got better
Academia for comparison doesn’t make money…maybe a better comparison is HFT? Plenty of very very smart people playing a zero sum game, yet their comp has only increased
I already addressed this in my comment. There are real factors that could reduce US compensation, but calling that "normalization" assumes the current gap exists for no reason.
It's a game. You're supposed to click on the different route options that are presented to you on the bottom of the screen. That's why it goes slower the more options there are.
But I also just followed it for the first time from beginning to end, not doing anything. Because I assumed someone had already done the math.
While 7700 per hour sounds big, pretty much any dinky server can handle it. So I don't think it's a matter of DDoS. At this point it's just... odd behaviour.
especially for a txt file. I don't know anything really about webdev but I'm pretty sure serving up 7700 plaintext files with roughly 10 lines each an hour isn't that demanding
Forgejo does set "cache-control: private, max-age=21600", which is considerably more than one second, but I grant it uses the "private" keyword for no reason here.
For some reason, Facebook has been requesting my Forgejo instance's robots.txt in a loop for the past few days, currently at a speed of 7700 requests per hour. The resource usage is negligible, but I'm wondering why it's happening in the first place and how many other robot files they're also requesting repeatedly. Perhaps someone at Meta broke a loop condition.
As facebookexternalhit is listed in the robots.txt, it does look like it's optimistically rechecking in the hope it's no longer disallowed. That rate of request is obscene though, and falls firmly into the category of Bad Bot.
Note that the API is split into XSS-safe and XSS-unsafe calls. The XSS-safe calls [0] have this noted for each of them (emphasis mine):
> Then drop any elements and attributes that are not allowed by the sanitizer configuration, and any that are considered XSS-unsafe (even if allowed by the configuration)
The XSS-unsafe functions are all named "unsafe". Although considering web programmers, maybe they should have been named "UnsafeDoNotUseOrYouWillBeFired".
Gleam is technically as suitable for distributed computing as Erlang: since it compiles to Erlang, it can do anything that Erlang can. You can use Erlang and Elixir libraries and write FFI code to do things that would be unergonomic to do in Gleam. Sure the experience is different and if you want to embrace the guarantees of static typing, then the APIs will look different, like gleam_otp.
If you compile it to JS, then the guarantees change to JS's guarantees.
Personally I've felt that the JS target is a big plus and hasn't detracted from Gleam. Writing a full stack app with both sides being in Gleam and sharing common code is something I've enjoyed a lot. The most visible impact is that there's no target specific functions in the stdlib or the language itself, so Erlang related things are in gleam_erlang and gleam_otp, and e.g. filesystem access is a package instead of being in the stdlib. If you're just into Erlang, you don't need to interact with the JS target at all.
Same here, I've only been using it for a bit and have 100% been ignoring the JS part and the only time where I felt I needed to think about it for a moment was when I was writing a patch for someone else's code that did not ignore it, so basically when contributing to a library you might have to do extra work.
Of course I can't say if anyone ever made any decisions based on the other target that would have repercussions for me only using the BEAM.
og:description is exactly the meta tag to use for link descriptions in embeds. Not all meta tags are only for search engines. The app acted correctly here.
It's basically what Phoenix LiveView specifically is. That's only one way to do it, and Phoenix is completely capable of traditional server rendering and SPA style development as well.
LiveView does provide the tools to simulate latency and move some interactions to be purely client side, but it's the developers' responsibility to take advantage of those and we know how that usually goes...
reply