Tiny CC doesn't have its own runtime, it uses whatever you specify (falling back to system standard), same as GCC or Clang. For low runtime footprint you are probably better off with one of those two compilers as they generate smaller, more optimised code.
I've been using "slopocalypse". People already know AI is responsible, but slop existed before — e.g. conventionally generated SEO spam. It's just... so much worse now.
> GitHub has recently seen more outages, in part because its central data center in Virginia is indeed resource-constrained and running into scaling issues. AI agents are part of the problem here. But it’s our understanding that some GitHub employees are concerned about this migration because GitHub’s MySQL clusters, which form the backbone of the service and run on bare metal servers, won’t easily make the move to Azure and lead to even more outages going forward.
Age-old lesson: change the tires on the moving vehicle that is your business when it's a Geo Metro, not when it's a freight train.
I'm sure the people with the purse strings didn't care, though, and just wanted to funnel the GH userbase into Azure until the wheels fell off, then write off the BU. Bought for $7.5B, it used to make $250M, but now makes $2B, so they could offload it make a profit. I wonder who'll buy it. Prob Google, Amazon, IBM, Oracle, or a hedge fund. They could choose not to sell it, but it'll end up a writeoff if the userbase jumps ship.
I assume this is all of the pains of going from "GHA is sorta kinda on Azure", which was a bad state, to "GHA is going full Azure", which is a painful state to get to but presumably simplifies things.
> Any massive infra migration is going to cause issues.
What? No, no it's not. The entire discipline of Infrastructure and Systems engineering are dedicated to doing these sorts of things. There are well-worn paths to making stable changes. I've done a dozen massive infrastructure migrations, some at companies bigger than Github, and I've never once come close to this sort of instability.
This is a botched infrastructure migration, onto a frankly inferior platform, not something that just happens to everyone.
Not right now, it is far too early days. I'm currently working through bugs, and missing stdlib, to get a simple backpropagation network efficient. Once I'm happy with that I'd like to move onto more complex models.
It uses the same trick as Go [1]. The grammar has semicolons, but the tokeniser silently inserts them for ease of use. I think quite a few languages do it now
I tried this with an old iOS only game a few years ago. It is clearly not a heavily used library, but it seemed to work ok
- There was a bug or two I had to patch, but the code is readable, so it wasn't a big deal
- OFString, etc aren't intended to be 1:1 replacements for NSString, etc. This wasn't a real problem. They mostly match, and all I needed to do was write a few categories
- The runtime functions are not compatible at all, but most projects wouldn't touch those
- CoreFoundation and the other C APIs are not there at all, so you'll need replacements
- It is a replacement for Foundation framework, not AppKit, so if it is a GUI app you still have a lot of work to do
This is why I went with GNUstep. All of the APIs are 1:1 with Apple's, including the runtime (which is very important imo). It has AppKit support as well; its AppKit implementation is kind of half-baked, but at least it exists. Also, a lot of the APIs are kind of old. But looking at how Swift evolved over the years, maybe that's not a bad thing.
My main complaint with GNUstep is the licensing. The runtime itself is MIT which is great, but its implementation of Foundation/AppKit is LGPL. ObjFW, including its runtime, is LGPL. At least with GNUstep one day I can create my own version of Foundation based on Cocotron or swift-corelibs-foundation or something, and not need to muck with rpaths + ship a bunch of .dll/.dylib/.so files with my app in order to comply with the license.
Discord if you don't mind something proprietary, Mattermost or Rocketchat if you do, Zulip if you want something slightly different . . . and no doubt many other alternatives
Slack is easy to replace with something cheaper and better on a product or technical level. The network effects are strong of course, but they won't sustain it forever
Discord is a solid product. They just need to launch a simple business-friendly alternative UI without the teenager gamer aesthetics. I’m surprised they never tried going after the enterprise market.
Enterprise doesn't buy chat/meeting products without PSTN interop (dial-in dial-out to traditional phone line). Discord would probably need to double their dev team to add PSTN.
Building something like Slack or Teams to the level that a F500 company would make it their primary videoconferencing solution is a multi-thousand-employee project. It's not a little skunkworks project for 15-20 people in some corner of the office.
That's why TFA is hilariously flawed. When Altman says "tell us what we should build, we'll probably build it!", he's talking about driveways and backyard pools, not the Golden Gate Bridge. It's like asking mall Santa for a summer home in the Hamptons.
I know absolutely nothing about PSTN interop and I'm sure it's very complex to implement. However, at the end of the day, this is just software we're talking about right? Software is cheap and easy to produce these days and I doubt you need thousands of people to implement something that syncs your meeting's audio stream to a phone line especially given that it's a problem that has been solved before.
Hardly. You're going from analog to digital and vice-versa. You probably need specialized appliances. For every country in the world. And it's "solved" but only in proprietary contexts; I don't think there's a standard. Then you need to operate it - you need SREs, bug fixes, keeping up with downstream changes etc.
Adding PSTN to Discord is absolutely a Discord-sized problem.
