I've long suspected it's got to do with office real estate.
You spent $10m or $100m on a building that's now half empty.
Either you downsize or commit to enterprise scale sunk cost fallacy and enforce RTO so your real estate investment isn't "wasted".
City centres also thrive on RTO, with high street shopping on a generational decline it's up to office workers and their employers to prop up the economy of the CBD one overpriced lunch at a time.
The city centre / real estate thing sounds like an externalisation - which companies famously dont give a shit about.
It should be a tradegy of commons at best: it may affect the CEOs 401k, but not by much (0.000001% for their individual decision to RTO for that company y). It like buying McD shares then going to McD for lunch every day with your team.
Most companies, at least in the U.S., don’t own their offices. They lease them.
In fact, a whole bunch of office leases were supposed to be expiring in 2024/2025. If this was the reason RTO wouldn’t be picking up right now since they would be cutting back and ending their leases.
My go-to use case for modern Perl is to be the default program instead of sed. Sed regex support is abysmal and the same command line flags behave differently between BSD (and macOS) and GNU versions, in particular the `-i` for doing replacements - the number one use case for the program. So, this means that many shell one-liners and small scripts don't really work the same way on macOS and on Linux, and it's pretty annoying.
Perl is straight up better. You need to remember one word: pie - for it's command line options, and now you can do:
First of all, it woks the same way across platforms.
Second, you get all sorts of goodies: named capture groups, lookahead and lookbehind matching, unicode, you can write multiline regexes using extended syntax if you do something complicated.
And finally, if your shell script needs some logic: functions, ifs, or loops, Perl is straight up better than Bash. Some of you will say "I'll do it in Python", and I agree. But if your script is mostly calling other tools like git, find, make, etc, then Perl like Bash can just call them in backticks instead of wrapping things into arrays and strings. It just reads better.
BTW Ruby can do it, too, so it's another good option.
At my work we use perl extensively for utility scripts and such. In the past few years there has been a push to write new scripts in python, but I don't really see the point. It has most of the same drawbacks that perl has: 30x slower than a compiled language and dynamic typing.
We have many scripts that range from 5.8 to 5.36 and everything in between. 5.8 is 20 years old. Someone did a search & replace on the shebang lines to move all the older ones to 5.20 (why they picked that one, I don't know) and everything just continued to work.
I prefer perl over python. turn on use strict, use warnings FATAL => 'all' and use modern function signatures. Perl is still great for its purpose.
>It's extremely stable, ... It's a shame it's so dead,
The former is the consequence of the later. Popularity kills stability. Perl is the ultimate sysadmin language because it's so portable and never changes. We really lucked out with the Raku thing driving people away to python. Because of it my perl scripts I wrote in 2003 run on perl system interpreter today and the vast majority of my perl written today would run on a 2006 perl interpreter (some functions missing in some libs in troublemakers like Gtk bindings, etc), but it's generally very good.
These days with python you can't even run any random script written today on your system python from today. You have to set up an entire separate python for every script. And don't even think about trying to run a python script from 2006. That's what popularity does: fracture.
Good old Java is also stable and yet popular. It is not particular "trendy", thought. My feeling is that languages which "live in"/"create" ecosystems such as JVM, BEAM or even LLVM have a better probability to outlive other languages in the long run. Let's see what happens with golang in some years... ;-)
Stable? Huh. Never thought of Java that way. Dead, yes, but it was never stable. In my experience I have to set up a custom JVM version for every java application I've come across. Is your experience different?
For me, Java died with Oracle shenanigans. I moved to C#. Java isn't truly dead yet but I think it will slowly die off because of Oracle. Same as Solaris and SPARC, but a little slower.
It's stable, installed everywhere, and I use programs written in Perl like when building Linux From Scratch. I haven't written in Perl since the 1990s. I do read code written in Perl and Raku, and I am often impressed by how succinct the code can be.
By far not. It's only more readable, but much more verbose, overarchitectured, slower and esp. unstable. Old perl scripts still work fine, old python scripts are not only many, many files, but also break every other year.
And you cannot just install a python module as you install a perl module. You need venv everything because it's soo fragile.
But this 10k sponsoring is not really worth mentioning. It's just like Platinum sponsorship for one of their conferences.
It won't be a full-blown Hackney license, Hackney licensing is because unlike these "ride sharing" apps and what the UK would call a "mini cab" service, which require only a "public hire" license - the Hackney license authorises you to literally pick up strangers on the street, which was of course a completely normal way to use a taxi in a major city decades ago and is still somewhat common at say airports. That's what the glowing "Taxi" sign on the roof is for.
This needs more driver quality insight because e.g. passenger gets in your vehicle, you drive them to some secluded spot and their body is found the next morning - there's no records for murder cops to start from, unless there was a witness there may not even be a description of your vehicle. The UK has had this happen, but it's very rare because the sort of person likely to escalate to murder is not going to get licensed.
In contrast a mini-cab or Uber-style driver has records of who was dispatched to pick up somebody, where they were picked up etc. So if you take to murdering your fares the murder detectives will show up at your door with company records implicating you.
>Why Elixir + Erlang are not more popular for high concurrency projects is a mystery to me.
I work at an Erlang shop.
For Erlang to be useful you need to have massive scale, millions of DAU. Yes Elixir might run your website serving thousands of DAU but Erlang and the BEAM was not invented for you. Few companies have the scale that makes Erlang a reasonable choice.
More pressing these days I believe is that the Erlang ecosystem is all or nothing, the BEAM is like its own little operating system and has extremely (IMHO) complicated setup and configuration with many moving parts: ERTS, epmd, Rebar,... You don't need or shouldn't use container tech and k8s with Erlang because it's already doing that stuff in its own Erlang way - but it's the Erlang way it's extremely unique and unfamiliar to most.
When you have the right use case for Erlang and you see it in action it is truly like black magic, it's been a highlight of my career to work with it.
When we tried to use Elixir Liveview we found that containerizing it (docker compose) was necessary just because of how demanding the runtime environment is regarding keeping modules up to date and synced, and what that requires of the host operating system.
We'll run prod on one server and dev on 3-4 workstations and nothing will match between any of them without a docker container to give this Elixir app a cleanroom environment to work from.
The project we were trying this on eventually ran out of funding before it got off the ground, and we lost access to our main guy who understood Elixir setup really well, so nowadays the rest of us can't even manage to stand up the service to demo it because of all of the moving parts that get angry about not having their environment set up just right.
I've basically found it the only language more difficult than python to set up an environment for. (Well.. the more I think about it, Gradle and every other mobile development stack I have yet seen is literally Satan's armpit..)
With python (though I rarely code in that either) I can stand up almost anything on almost any machine with miniconda and venv and not have to drag Docker into things.
Node/NPM is a prima donna and a PITA but IME as long as you whack it with a wrench long enough following up on each of its complaints then you'll eventually get things running.
My experience still revolves around PHP or Perl or C on the backend, Raw Javascript or sometimes Elm on the front end, and those all seem to be a lot easier to maintain over a timescale of decades as servers update and browsers gobble up new and different features.
---
What I can say in favor of Elixir Liveview is that we built a smooth as hell SPA using that. It was incredibly user friendly to work with and aesthetically amazing, but the maintenance right down at the foundation was the biggest challenge.
What environment issues were you running into? We use mise/asdf to manage which version of erlang/elixir our project is using, and only needed to containerize our database to ease its maintenance.
For the dev experience, I'd also recommend NextLS/Lexical over Elixir LS until the official one is out. It should compile much faster for nontrivial Elixir applications.
> Elixir has been quite easy to set up, configure and deploy, at least for the last 5-6 years.
One of your sibling commenters noted...
> I've basically found it [Elixir] the only language more difficult than python to set up an environment for.
Quite the difference.
I'm not saying either one of you is wrong; I'm sure you both experienced what you say you did, it's just interesting to see the dichotomy, literally (as of this writing) next to each other.
We found Erlang to be the right choice at small scale. Namely, we used it in iot applications, where the self-healing property of proper supervision trees resulted in a very stable implementation. We also saw the same benefits in the cloud part of our application. No complicated k8s setup, just simple supervisor trees.
elixir softens a whole ton of the sharp edges around getting started and there are only a handful of "gotchas" coming from other hlls (like all terms being immutable when you pass to a function -- but thats honestly almost a problem with the "mainstream" languages).
Instead of treating the function like a "subroutine"? Like:
x = 10
doubler(x)
print x
I'm unsure why, but I use the former. Probably due to most sources saying global variables are bad and if I do it the latter way I get errors, whereas with the former I only get errors unrelated to scope.
I'm not a professional or even amatuer programmer, that's why I ask. My only exposure to Erlang unfortunately is from coding contests like advent of code and Codegolf stack; and those are "clever" and my brain doesn't abide clever. The inverse of "why use many words when few words will do"
In my own programs, if I go back and read the code I can tell what I copy-pasted vs what I understood as I wrote it, if that makes sense. Because clever stuff that solves the problem I've been unable to solve in the time I alloted will be in my code. You see anything pretending to be, or being a lambda in my code, I lifted it.
I would like to learn Erlang and there's been a few book recommendations aside from TFA. This comment also serves as my reminder to get some books.
>I find it useful for some coding tasks but think LLMs were overestimated and it will blow up like NFTs
No way. NFTs did not make any headway in "the real world": their value proposition was that their cash value was speculative, like most other Blockchain technologies, and that understandably collapsed quickly and brilliantly. Right now developers are using LLMs and they have real tangible advantages. They are more successful than NFTs already.
I'm a huge AI skeptic and I believe it's difficult to measure their usefulness while we're still in a hype bubble but I am using them every day, they don't write my prod code because they're too unreliable and sloppy, but for one shot scripts <100 lines they have saved me hours, and they've entirely replaced stack overflow for me. If the hype bubble burst today I'd still be using LLMs tomorrow. Cannot say the same for NFTs
LLMs are somewhat useful compared to NFTs and other blockchain bullshit which is nearly completely useless.
It will be interesting what happens when the money from the investment bubble dries out and the real costs need to be paid by the users.
Bitcoin has been bootstrapped into usefulness through the durability of the belief many have had in it, especially as people begin to lose confidence in the dollar and US equities.
I'm from West Yorkshire, the dialect is slowly fading. My grandfather would speak with a strong accent and with spatterings of Norse words. I notice now that, yes, dialects in the UK are becoming homogenised but there is also some American influence seeping in. The American way of pronouncing a double t as a d "better" => "bedder" is increasingly more prevalent in the UK, it's slightly saddening.
When I was staying with a friend in Norway once we visited his mother, and to me she sounded like someone with a broad Durham/Newcastle accent (my mother is from there) speaking German. A lot of north east words are germanic, or Scandinavian. My grandfather was a farmer near Durham and pigs were swine, children were bairns.
As for American influence, my youngest daughter picked up a lot of that from Youtube at one point, and I once interviewed a girl from Gravesend with such a strong US accent I assumed she'd grown up over there.
Exact same thing is happening in Australia. I'm guessing it's from watching streaming video, Netflix, TikTok, etc. where American accents predominate, and any non-American accents are flattened enough to be sure it's easy for Americans to understand them.
It's weird that the mainstream TV execs think audiences want boring American accents. To me, one of the best things about the White Lotus (hit HBO show) is that it highlights a distinct array of accents (including Australian).
Thanks! Now I'm inclined to watch it. I do love when shows make a point of keeping distinct accents.
What with having moved a lot as a bairn, I feel that accents in many places are fading away. And also, I tend to sound like whoever I've been talking most to for the last two hours. It's a bit weird, that…makes people ask why I'm speaking with x accent. (^_^);
I emigrated from the UK to USA in 1980 and my first code review at Bell Labs I spent about 30 mins explaining my code and then asked if there were any final questions and someone hesitantly asked, "What is this variable 'zed' you keep talking about?"
I used to work for a networking start-up and when we were in the US trying - without success - to sell the company we practised over and over saying "roWter" for "router" (English pronunciation like "rooter").
As a Canadian I read that as "rOATer" for a moment, because the word row rhyming with ow is quite uncommon here -- the row I know is in a boating or a data context.
Having posted the above a few days ago, last night I (originally from the UK) was in the car with my wife (US born and bred) following and reciting map directions on my phone like "0.8 miles left on San Antonio" which I say as UK standard "nought point eight miles left on San Antonio." After a while she asks "what is nought?" Here we just say "point 8 miles" or "zero point eight miles." We've only been married 42 years and are still learning each other's language:-)
Some time ago a few people from the UK kept calling/referring to someone as a nonce. It took me awhile to say something, but I finally asked because I simply couldn't understand or wrap my head around why they kept referring to this person as a single use random number (mostly for authentication in my case). It was so confusing.
There was a cartoon in Private Eye a couple of weeks ago that suggested the reason why Millenials and Gen Z could never be reconciled is that they can't agree whether it's pronounced "Generation Zed", or "Generation Zee", as the younger generation themselves would call it.
There really isn't one 'west yorkshire' accent, nor one 'north yorkshire' accent, there is much much more variety than that. A leeds resident sounds different from a wakefield or dewsbury resident, and even then there can be variation where some people exhibit less of their locale accent than others, depending on how much they rebelled against sounding 'local' in their teens.
I may be completely wrong, but I think one direction of evolution in pronunciation is the gradual shift to that which takes less physical effort to pronounce.
"Bedder" is less physical work, less effort, in the mouth than "better".
This is a bit of a myth. A glottal stop is a full consonant sound which takes effort to produce. It's not really any 'easier' to produce than an alveolar stop in any objective sense.
>The biggest mistake I see people make with Go channels is prematurely optimizing their code by making channels buffered. This is almost always a mistake. It seems logical. You don't want your code to block.
Thank you. I've fixed a lot of bugs in code that assumes because a channel is buffered it is non-blocking. Channels are always blocking, because they have a fixed capacity; my favorite preemptive fault-finding exercise is to go through a codebase and set all channels to be unbuffered, lo-and-behold there's deadlocks everywhere.
If that is the biggest mistake, then the second biggest mistake is attempting to increase performance of an application by increasing channel sizes.
A channel is a pipe connecting two workers, if you make the pipe wider the workers do not process their work any faster, it makes them more tolerant of jitter and that's it. I cringe when I see a channel buffer with a size greater than ~100 - it's a a telltale sign of a misguided optimization or finger waving session. I've seen some channels sized at 100k for "performance" reasons, where the consumer is pushing out to the network, say 1ms for processing and network egress. Are you really expecting the consumer to block for 100 seconds, or did you just think bigger number = faster?
