Yeah, Steam may be effectively a monopoly, but it's because nobody else really wants to compete with them at their level.

Steam has two types of customers. Us the gamers where we can decide which platform to use. They have an effective monopoly on us because they provide a good service. But with a large game library we are locked into steam as well and cannot just switch to a different platform. If valve ever did decide to be evil then we are screwed.

But developers are also customers of valve. And this is arguably where valve makes their money. They take a cut from the developers sales. Devs cannot just use a different platform without cutting out a huge userbase. This gives valve a real monopolistic control over developers.

Its hard to argue that 2 config files both multiple lines long is simpler then a single line in an existing file. Adding a service to cron is just simpler. But adding all the extra bit you are going to want on top increases the things you need to learn to do and configure correctly.

IMO systemd timers are simpler to get right at a little bit more of an upfront cost to learning how they work. But cron is still simpler to just get something working without caring that much. I still find that ends up biting you in the longer term though though all the missing features you need to add manually on top of that one basic line you added.

The problem is - users pay for Windows only once

That is not in the slightest true. They pay once per computer. And people go through multiple computers in their lifetime. So it is not at all tied to birthrate.

Very few people buy licenses directly. Most people buy it pre-installed with an OEM license that is tied to that computer.

'I never thought leopards would eat MY face,' sobs woman who voted for the Leopards Eating People's Faces Party. - Adrian Bott

Don't ignore the responses. If you abuse it too much there is a chance that the api will just block you permanently and is generally seen as not very nice, it does take resources on both ends to process even that response.

The ratelimit crate is an OK solution for this and simple enough to implement/include in your code but can create a miss-match between your code and the API. If they ever change the limits you will need to adjust your program.

A proxy solution seems overly complex in terms of infra to setup and maintain so I would avoid that.

A better solution can depend on the API. Quite often they send back the request quotas you have left either on every request or when you exceed the rate limit. You can build into your client for the API (or create a wrapper if you have not done so already) that understands these values and backs off when the limits are reached or nearly reached.

Otherwise there are various things you can do depending on the complexity rate limit rules they have. The ratelimit crate is probably good for more complex things but you can just delay all requests for a while if the rate-limiting on the API is quite simple.

You can also do an exponential backoff algorithm if you are not sure at all what the rules are (basically quickly retry with an exponentially increasing delay until you get a successful response with an upper limit on the delay). This is also a great all round solution for other types of failures to stop your systems from hammering them if they ever encounter a different problem or go down for some reason. Though not the best if you have more info about the time you should be waiting.

Rust syntax is badly designed compared to most other languages I used

It really isn't badly designed. Yeah there are more symbols than you are used to from JS/Typescript world. But more symbols does not mean bad syntax. It makes things more explicit which IMO makes things easier to read and understand what is going on. Rather than all the implicit behavior in JS/TS.

Let’s take a look at hashmaps vs json

What is the point of this? Lets compare two different things to prove no point! Look I can do it to:

let person = Person {
  name: "joe".to_string(),
  age: 23
}

const scores = new Map();

scores.set('Name', Joe);
scores.set('Age', 23);

Why would you construct a map like this? That is not what maps are for in either JS or rust. But either way all these examples are easy to read and can tell what they are doing even if you have not coded the language before. Now you do need more of an understanding of rust code to read some rust code but not these examples given.

Every single library in rust is half-baked.

That is just hyperbole. Many rust libraries are very mature now. Not having a website is not a sign of maturity and the docs for axum are very good in rust docs site. If you really want a webserver with a website then you have actix-web. Many rust projects do have sites like this or even books on how to use them. And if you look at the JS ecosystem, how many libraries do you use there that have nothing more then a readme on their github page? IMO I tend to find far worst documentation for JS libraries then I do for rust ones - if you look beyond the big things like react.

No GUI framework is as stable as something like Qt or GTK

This is true of basically all languages but C/C++ and maybe JS. Most languages just lean on these for good UIs, but there is a lot of effort ATM in getting nicer GUI support in native rust. It will come with time but a GUI library is a complex thing to make.

literally every rust project has like 1 dev maintaining it in his free time and has “expect breaking changes” in the readme

This is just more untrue hyperbole.

Apparently everyone loves dealing with hours and hours of debugging basic problems because it makes you a better programmer, or there’s some information I’m just missing.

One of the things I love about rust is I don't need to spend hours and hours debugging basic problems because the language is explicit and makes me think better about things upfront. Rather then spending hours wondering why something is producing weird output at runtime because something somewhere else got a "1" instead of a 1. It takes a bit more effort to get something to compile, but I find vastly fewer surprises at runtime then I do in other languages. And it is those runtime bugs that take the most amount of time to solve.

When you’re running a company you don’t have time to mess around with syntax quirks, you need thinks done, stable and out the door

You also don't want things to break in production and have to spend hours and hours debugging some weird edge case.

I disagree. What is wrong with a fully featured batteries included desktop environment that has proper tiling support (not just partital drag the window to the edge of the screen support). Lower the barrior to entry so that more people can make use of this powerful way of working. The main reason that tiling is considered hardcore is becuase it has mostly only been available on minimal configure them yourself window managers. But tiling does not have to be for the fully DIY only crowed.

IMO the basic tiling support on gnome or KDE are not good enough. So I am forced to use something minimal but TBH I am sick of needing 100s of lines of config to get a basic environment setup. Cosmic seems like it will be a good answer to this post as its tiling support looks far more fully baked than other full desktop environments and hopefully we will see more people wanting to try out tiling once it reaches a more stable point.

This is an absolute terrible post :/ I cannot believe he thinks that is a good argument at all. It basically boils down to:

Here is a new feature modern languages are starting to adopt.

You might thing that is a good thing. Lists various reasonable reasons it might be a good thing.

The question is: Whose job is it to manage that risk? Is it the language’s job? Or is it the programmer’s job?

And then moves on to the next thing in the same pattern. He lists loads of reasonable reasons you might want the feature gives no reasons you would not want it and but says everything in a way to lead you into thinking you are wrong to think you want these new features while his only true arguments are why you do want them...

It makes no sense.

So, if you just use the system API, then this means logging with syslog(3). Learn how to use it.

This is old advice. These days just log to stdout, no need for your process to understand syslog, systemd, containers and modern systems just capture stdout and forward that where it needs to do. Then all applications can be simple and it us up to the system to handle them in a consistent way.

NOTICE level: this will certainly be the level at which the program will run when in production

I have never see anyone use this log level ever. Most use or default to Info or Warn. Even the author later says

I run my server code at level INFO usually, but my desktop programs run at level DEBUG.

If your message uses a special charset or even UTF-8, it might not render correctly at the end, but worst it could be corrupted in transit and become unreadable.

I don't know if this is true anymore. UTF-8 is ubiquitous these days and I would be surprised if any logging system could not handle it, or at least any modern one. I am very tempted to start adding some emoji to my logs to find out though.

User 54543 successfully registered e-mail user@domain.com

Now that is a big no no. Never ever log PII data if you don't want a world of hurt later on.

2013-01-12 17:49:37,656 [T1] INFO c.d.g.UserRequest User plays {'user':1334563, 'card':'4 of spade', 'game':23425656}

I do not like that at all. The message should not contain json. Most logging libraries let you add context in a consistent way and can output the whole log line in Json. Having escaped json in json because you decided to add json manually is a pain, just use the tools you are given properly.

Add timestamps either in UTC or local time plus offset

Never log in local time. DST fucks shit up when you do that. Use UTC for everything and convert when displayed if needed, but always store dates in UTC.

Think of Your Audience

Very much this. I have seen far too many error message that give fuck all context to the problem and require diving through source code to figure out the hell went wrong. Think about how logs will be read without the context of the source code at hand.

And undermine their own ai offering

for larger or more intricate shell scripts

Those are call applications. Use any language you like. If go/rust is what you know use them. I use rust all the time for things beyond run a bunch of commands and tends to be my go to when I need to process data in any way.

IMO that is a disingenuous way to state that. It makes it sound like they had to work to find games that worked on Linux at all and suggests that most games do not. Which is far from the truth. Most games just work these days and it is only a handful that don't, so only a handful work 100% better. Then it all really depends if you care about those few games or not.