Tinkerings

joined 1 year ago
[–] Tinkerings@beehaw.org 1 points 11 months ago

If they thought the fediverse was insignificant they wouldn’t even bother. Them spending publicly visible time and energy on it means there’s something for them to gain.

But yeah, I’m not entirely sure what yet. Like you said, reading data is freely available, so it’s not just that.

[–] Tinkerings@beehaw.org 6 points 11 months ago (5 children)

We’re pretty much agreeing here. I don’t think them federating out makes much of a difference. They get the data from the reverse for free. They only have to scoop, and it’s worth almost noting individually.

But that’s their current game. Has been for a long time. Serving one ad is a tiny thing. But they add up.

However, them wanting to federate indicates they see the fediverse as something worth noting and paying attention to, possibly even joining. That’s not nothing.

They either think:

  1. The fediverse will grow with or without them, and without them it’s a potential threat, due to loss of control
  2. The fediverse has potential that they want to water and help grow so they can prune it and shape it to become something valuable to them
  3. They can “try genuinely” to join the fediverse, and elicit a response that maims it

That response can come in many forms.

If they provoke a backlash of defederation (done), that causes devision and argument. They win by shattering the potential threat before it can grow.

If they are allowed to join and become a large voice and eventually be like gmail to email, big enough to have control and provide the filtering people are already (quietly, carefully) asking for. All they need to do is to offer “spam filters” and a “personal feed” and we have Facebook 2.0 and they don’t even have to foot most of the server bills.

I’m not sure how to win this, but there’s a lot of ways to lose it.

[–] Tinkerings@beehaw.org 6 points 11 months ago (7 children)

The Wig punched himself through a couple of African backwaters and felt like a shark cruising a swimming pool thick with caviar. Not that any one of those tasty tiny eggs amounted to much, but you could just open wide and scoop, and it was easy and filling and it added up. The Wig worked the Africans for a week, incidentally bringing about the collapse of at least three governments and causing untold human suffering. At the end of his week, fat with the cream of several million laughably tiny bank accounts, he retired. As he was going out, the locusts were coming in; other people had gotten the African idea.

  • Count Zero - William Gibson

They just need the data. It’s available, all they need to do is open wide and scoop.

[–] Tinkerings@beehaw.org 2 points 1 year ago (1 children)

Have you looked into Remote Tunnels?

You can control your Desktop VSCode remotely from an iPad browser. You’ll still likely need a keyboard and a trackpad or mouse will help a lot, but that’s basically the same situation as CodeSpaces.

[–] Tinkerings@beehaw.org 3 points 1 year ago

On your point about junior devs working on backend. I think part of that is that asynchronous programming is just hard. You have to have a brain for it. Some stuff you can get away with (front-end, for example, if you miss an event after an animation it’s not the end of the world), but for serious back-end systems you have to know how to handle async no matter what language you’re in.

[–] Tinkerings@beehaw.org 2 points 1 year ago

I’m not sure what you mean by unstable ecosystem. I can presume you mean it’s easy to gain tech debt since there’s such velocity in the node/JS/TS ecosystem (and I agree not all of it is good).

I haven’t found it to be an issue. My job is a contract system engineer guiding companies in fixing tech debt, so I am very attuned to it.

Specifically I’d say the tooling in the last year or two has gotten much better at stabilizing an environment for node/deno development in particular. Tools like fnm, projen, and esbuild mixed with installing tools per-project (using npx to run them) instead of globally for development allows flow project to project on the same machine without having conflicts of tooling versions. Combine that with Docker for deployment and something built today should last 4-5 years with little maintenance and not having to make any changes except for security patches.

Not that there’s not hiccups. The whole CJS/ESM nightmare is still going (but near an end I feel).

I also feel like 4-5 years without maintenance is not something you really want. In the rare case you do, then I’d say JS is likely not for you. I’m not sure what language is. C or C++ most likely. Those have been around forever, and will never go away. Modern C++ has a lot of great features to handle memory management automatically, functional programming capabilities, compile-time metaprogramming, and OS abstraction, so that’s what I’d recommend for something that needs to last forever with minimal changes. (Thinking like a COBOL replacement.) After all, that’s what node and the JavaScript engines are written in.

My biggest issue with Java in particular is the predatory enterprise ecosystem. I spend a lot of time helping companies get away from that for cost reduction and lock-in issues.

One more point for node: it’s hands-down the most optimized interpreted engine in the world. This can be determined simply by the size of the companies that work on it and that absolutely depend on it being it’s best for their bottom line. Google, Apple, Facebook, and Microsoft among them. Billions spent on that optimization. Just sayin.

[–] Tinkerings@beehaw.org 8 points 1 year ago (6 children)

I’ll throw my 2¢ in on TypeScript → JavaScript. The typings accelerate development significantly (if the developer doesn’t fight them and make everything any), and you can write to modem JS when you have older runtimes.

But more you can do full stack from cloud infra (Infrastructure-As-Code with something like AWS-CDK or CDKtf) to deploy and orchestrate front-end to back-end.