I think the assertion might even have been true for non-pathological cases 20 to 40 years ago. A company that chose Visual Basic or Perl would have had a much harder road than one which chose C# or Python. But i think the languages which have survived to the present day are all pretty close in productivity. Except C.
I've worked for a company with a large code base in Visual Basic .net. Product been in development since the 90's, with rich customer that only cares about their software doing its job. It's a surprisingly productive language combined with Visual Studio. Even though, as a language enthusiast, I barfed a bit now and then. Dev team would like to switch to C# but it would have been a multi-year effort taking away from lucrative feature requests.
that comment is probably referring to VisualBasic 6.0 which was not a dialect of C# like VB.NET but then again your product from the 90s likely started off as that
> A company that chose Visual Basic or Perl would have had a much harder road than one which chose C# or Python.
Based on what? Economics define where you go, not language. If company using Perl or VB has steady cash flow and their bottleneck is language - they’ll just rewrite when it makes sense. No amount of writing in C# or Python from scratch will save you if your product is garbage.
The majority of popular PvP shooters use anti-cheat which does not work on Proton, so "almost all modern games" seems like overselling it to me.
But the stuff that does work, works well. I play Helldivers 2 via Proton on Fedora, and i experience far fewer crashes and instances of weird behaviour than friends on Windows or Xbox.
I couldn't run Delta Force [1], due to anti-cheat as far as i can tell.
Shame about Battlefield 6, some of my friends are playing that and it would be fun to join them. Oh well. Fortunately they're mostly still playing Helldivers 2 as well, and that works fine.
The rough idea is that if the kernel blocks a thread on something like a page cache miss, then it notifies the program through something a bit like a signal handler; if the program is doing user-level scheduling, it can then take account of that thread being blocked. The actual mechanism in the paper is more refined than that.
Nice find. That going nowhere seems like classic consequence of the cyclical nature of these things: user-managed concurrency was cool, then it wasn't, then Go (and others) brought it back.
I think the more recent UMCG [1] (kind of a hybrid approach, with threads visible by the kernel but mostly scheduled by userspace) handles this well. Assuming it ever actually lands in upstream, it seems reasonable to guess Go would adopt it, given that both originate within Google.
It's worth pointing out that the slow major page fault problem is not unique to programs using mmap(..., fd, ...). The program binary is implicitly mmaped, and if swap is enabled, even anonymous memory can be paged out. I prefer to lock ~everything [2] into RAM to avoid this, but most programs don't do this, and default ulimits prevent programs running within login shells from locking much if anything.
[2] particularly on (mostly non-Go) programs with many threads, it's good to avoid locking into RAM the guard pages or stack beyond what is likely to be used, so better not to just use mlockall(MCL_CURRENT | MCL_FUTURE) unfortunately.
> At Boston Organics, we believe that access to healthy, local, and responsibly grown food should be simple and accessible to everyone. That’s why we deliver fresh, organic produce while respecting the environment, supporting small farms, and building strong, sustainable communities.
Is this some sort of weird content mill domain squatting situation?
That science.org article at least manages to show an image of the ship, the OP covered the only (!) image with the headline, and then every time in the article when you thought an image was coming, it was ads.
Anyway, I know absolutely nothing about being on the bridge of such a ship, but can't help to think that it looks/feels "wrong" for a mariner not to be able to see the sky ahead, since there is a helicopter pad jutting out over the bridge. Oh well, I guess they can go to the side.
Many of us just don't use JSON in our day jobs, weird I know, but true.
The only thing I use JQ for at work is parsing the copilot API response so I remember what the model names are - that's it! TBH, I could just skip it and read the json
