procaryote

How do you mean? You can at least do things like

typedef struct foo foo;

and somewhere else

struct foo { … }

The article makes it sound like this is inevitable, and the only choice you have is

A: participate and have a chance to not be part of a perpetual underclass

B: for moral reasons, don't participate, be part of the underclass

I kinda would have hoped for

C: <something> to stop this from happening

Otherwise it's the worst sales-pitch ever

Also, those things are horrible. You pay in money, and in sanity, and in productivity

One reason might be that microservice foundations tend to become frameworks rather than building blocks.

Auth is a building block you can slot into your system and the shape of the hole isn't all that complex. A framework is something you need to slot your system into, and it has a lot of twists and turns so it ends up restricting how you do all the other things.

There are lots of microservice-foundation-related building blocks. E.g. I use a library somewhere that just does circuit-breaking. I slot that into my app rather than the other way around, and if I wanted to replace it, it's a fairly isolated thing. I don't use any frameworks for it though

Frameworks also tend to grow more and more complex as they evolve. If I as a user want a different auth for example, that needs to be supported by the framework. Over time, all things become pluggable and configurable, until at some point it's complex enough that someone restarts the process, or makes an opinionated spin of the framework.

There's a lot wrong with Javascript's Date, but the fact that it's an object is is not really in the top 10.

Would it have been nice if the Date object had been immutable? Sure, but the fact that changing the mutable object does indeed change the object shouldn't be a shock

Why would you give up just because something is NP hard if there are good algorithms to approximate a solution, and an approximate but good solution is useful?

AI doing a bullshit job isn't a productivity increase though; it's at best a cost cut. It would be an even bigger cost cut to remove the bullshit job

This makes a lot of sense and is consistent with the lens that LLMs are essentially better autocomplete

As I understand it, NLP is pseudoscience.

Rhetoric and persuation has long been studied by humanity, but that doesn't make NLP real

It's a way to dig yourself out of the hole without a full rewrite, and with a smaller retraining effort for your developers.

The best advice is probably "don't", as it usually is to most people setting out to design a programming language, and even more so for people setting out to do a mostly backwards compatible extension to a language that isn't suited for what you want it to do.

The second best advice is probably, do just c with classes. Allow defining your own allocator to make objects of those classes. It's fine if objects built with one allocator can only refer to objects built by the same one.

Don't do templates, just do the minimum needed for a container type to know what type it contains, for compile time type checking. If you want to build a function that works on all numbers regardless if they are floats or complex or whatever, don't, or make it work on those classes and interfaces you just invented. A Float is a Number, as is an Integer. Put all that cleverness you'd waste on templates into making the compiler somewhat OK at turning that into machine types.

Very specifically don't make the most prominent use of operator overloading a hack to repurpose the binary left shift operator to mean `write to stream`. People will see that and do the worst things imaginable, and feel good about themselves for being so clever.

C++ is a katamari ball of programming trends and half baked ideas. I get why google built golang, as they were already pretty strict about what parts of the c++ sediments you were allowed to use.

C11 adds a couple of nice things like static asserts which I use sometimes to document assumptions I make.

They did add some optional sections like bounds checking that seem to have flopped, partly for being optional, partly for being half-baked. Having optional sections in general seems like a bad idea.

Is modern C really much more complicated than old C? C++ is a mess of course.

Lowering the barrier to create your own syntax seems like a bad thing though. C.f. perl.

From your faq: "We maintain zero logs of your activities. We don't track IP addresses, …"

Front page says "zero logs"

Some logs, including specifically datapoints you have promised not to log, but you mean well (?) is pretty different from zero logs

They're good enough for fingerprinting and matching against other logs.

Also:

> // What we DON'T collect:

> - IP addresses (not logged, not stored, not tracked)

> - Usage patterns (no analytics, no telemetry, nothing)

> - Device fingerprints (your browser, your business)

so, I've read one blog from this company, and already they're lying or incompetent

is that faster to say than do, or is it an accessibility or while-driving need?

As in "always run a network firewall" or "keep the IP secret"? Because I've had people suggest both and one is silly.

I don't understand your answer I'm afraid

You can of course bet on not being very successful as a company. If you can keep the number of users down you simplify a lot of things

I get the impression that pico with micropython does this pretty well. You can ignore the second core and PIO if you don't want them. They won't hurt you.

CMake doesn't spark joy, but it's not something you need to touch constantly. I figured out how to set up a basic cmake file and now I mostly need to touch it to set a project name, add or remove modules etc.

It was a while since I used arduino, but I remember having a harder time setting up a workflow that didn't need me to touch the arduino IDE.

The raspberry pico is much nicer to work with, if you're looking for an alternative. It has dual core if you need it, and the fun little IO coprocessors if you want to get really low level. The pico2 even has a risc-v mode

The process of getting a binary onto the board is just dragging a file, and on linux at least you can script it with picotool

It's a nice ambition, but it's a different thing than memory safety

Of course things are easier if you can run all your code in one binary on one machine, without remote users or any need to scale.

As soon as you add users you need to start coping with backwards compatibility though, even if your backend is still a monolith.

The backend being a monolith is probably easier for a while yes, but I've also lost count of the number of companies I've been to who have been in the painful process of breaking apart their monolith, because it doesn't scale and is hard to work with

Microservices or SOA aren't trivial, but the problems you bring up as extremely hard are pretty easy to deal with once you know how; and it buys you independent deploys and scale, which are pretty useful things at a bigger place

If you've run a microservice stack or N at scale with good results, someone saying it's impossible doesn't look pragmatic

> or they had other requirements that necessitated microservices

Scale

Both in people, and in "how do we make this service handle the load". A monolith is easy if you have few developers and not a lot of load.

With more developers it gets hard as they start affecting eachother across this monolith.

With more load it gets difficult as the usage profile of a backend server becomes very varied and performance issues hard to even find. What looks like a performance loss in one area might just be another unrelated part of the monolith eating your resources,

You usually can't simultaneously deploy two services. You can try, but in a non trivial environment there are multiple machines and you'll want a rolling upgrade, which causes an old client to talk to a new service or vice versa. Putting the code into a monorepo does nothing to fix this.

This is much less of a problem than it seems.

You can use a serialisation format that allows easy backward compatible additions. The new service that has a new feature adds a field for it. The old client, responsibly coded, gracefully ignores the field it doesn't understand.

You can version the API to allow for breaking changes, and serve old clients old responses, and new clients newer responses. This is a bit of work to start and sometimes overkill, given the first point

If you only need very rare breaking changes, you can deploy new-version-tolerant clients first, then when that's fully done, deploy the new-version service. It's a bit of faff, but if it's very rare and internal, it's often easier than implementing full versioning.

You solve a bunch of them by not using javacript in the backend though