rumanator

I don't see a future where C survives

Meanwhile C is running strong since the 70s.

the lack of package manager

What do you call linux distro's package managers then? I mean, in distributions like Debian you can even download a package's source code with apt-get.

C has been "losing ground" not because of random per peeves of those who never wrote a line of code in C but because since C's last standard update there have been other programming languages that offer developers something of value so that the trade-off between using C or any alternative starts to make technical sense.

It also helps that C's standardization proceeds in ways that feel somewhat between sabotage and utter neglect.

Meanwhile, C is still the absolute best binary interop language devised by mankind.

Those cloud users can have the same benefit by spending a fraction of the price. That's the point. The question you're trying to ask is whether the added value being promised justifies a price tag that's 10x higher than the ones offered by established services.

Well the assertion is just a mathematical fact,

It really isn't. You're somehow assuming that the law of supply and demand doesn't exist. As the premise is blatantly wrong then this mistake renders all subsequent assertions mute.

Maybe the company isn’t targeting anyone

Irrelevant. The initial assertion was that higher prices somehow had no inpact in demand and thus revenue would be proportional. This assertion is blatantly wrong. The fact is that lower prices increase demand, and increased demand enables economies of scale, which lead to higher revenue. Conversely, higher prices lower demand, etc etc. Market segmentation is tangential to this point.

What domain problem is that? Communicating through a network?

If they reduce price to $10/m they'll need 5x customers to reach same revenue

This assertion could only start to make any sense if you believe that the law of supply and demand doesn't exist, and that economies of scale don't apply.

Meanwhile, I am a paying customer of cloud providers eventhough I don't use them just because they are affordable. This service expects that people like me spend 600€/year when I can have the same exact service somewhere else for 60€/year.

What a weird comment. I mean, it adds nothing to the discussion and intentionally sidesteps the core of any service: it's business model.

If you refuse to even discuss the pricing model of a service, why bother wasting your time posting anything at all?

For EC2 instances and the like it will be almost all X86 for a long time.

I wouldn't bet on it being so lopsided. AWS is betting stringing it's ARM processors, which appear to have a better price/performance ratio.

You're focusing your argument on a specific person while ignoring the point about how a global increase in liquidity triggers global inflation.

My point is that even though they're loosely coupled, the API actually cannot change freely because the actual consumer of the API, the business logic, is still tied to the API through the client.

The main promise of REST is that following that particular application style does indeed allow the API to freely change without breaking backwards compatibility.

The main drawback of REST is that no one actually follows those principles.

With REST, the client is not tied to an API. The client seeks resources, and relies on content discovery processes to determine how to access those resources. The only endpoint that may be hard coded is a home/root endpoint, and all other resources are accessible through it by following hypermedia. With REST you care about the what, not the where.

If your API changes and the client/browser is still able to traverse it fine, but your business logic breaks

This is where you're getting it wrong. REST is all about the interface. The interface has zero to do with the business logic. If you have an interface that allows you to access the same data but for some reason your business logic breaks due to non-opersrional reasons (i.e. extra latency from the content discovery process) you need to have a talk with whoever screwed that up.

These concepts were developed for the web. Not APIs on the web, but HTTP itself.

This assertion is just plain wrong. REST is an architectural principle focused on providing APIs for web services, and Roy Fielding was quite vocal in making it extremely clear that there is nothing in REST that is HTTP-specific, let alone makes it tied to HTTP. REST is an architectural style that relied on the concept of resources, which should be linkable. That's it.

Most of the time, those “things” are dumb business logic applications that can’t explore the hypermedia to discover new functionality and furthermore are not designed to do anything with it anyway.

Dumb business logic is not the point. One of the benefits of HATEOAS is that it allows REST clients to be loosely coupled with REST services, in a way that APIs can change freely change (i.e., change endpoints around, break away functionalities into other services, etc.) without requiring clients to be updated under the penalty of breaking compatibility.

The main reason why no one does REST and everyone does RPC-over-HTTP is that while REST clients require tracking and updating state to support service discovery, RPC-over-HTTP just requires a single HTTP request to achieve the same purpose, albeit without the resilience and future-proof.

If a random guy online uses an account created a couple of days ago to say he has knowledge of something without providing any proof or substance then everyone should just blindly trust him and take his word for it.

Right?

Electron exists to poach web developers into app development, because native code and frameworks are hard.

I don't agree with the "poaching" statement, but I would argue that "frameworks are hard" should be replaced with "desktop gui frameworks are appalingly poor".

Webview-based rendering frameworks trade away native look-and-feel for a myriad of tools and processes and techniques and workflows and expertise that you simply do not get with plain old widget frameworks. GUI developers know this, and in particularly GUI frameworks vendors are well aware of this. In fact, check XAML or QML.

Not it's not.

It really is. Just because some people have a uncanny propensity to mix concerns that shouldn't be mixed, that doesn't mean that a data structure is something else.

The browser has no real concept of "page navigation" or "site navigation" with any kind of state, or the "current" navigation item, or of hierarchy, breadcrumbs, menus, or other core navigational concepts involving site and page structure.

Why do you believe the browser should support that with primitives? Advocating for that kind of specialization lies somewhere between forgetting important and basic historical lessons on software engineering or an unsubstantiated belief that now everything will be different.

A large part of "knowing about usability" is just knowing how to execute these basic navigation features without goofing up on the many pitfalls available to you.

You're leaving out a part where said usability principles lie somewhere between emerging requirements that are still under development or fads that are scheduled to be replaced with the latest and greatest promising idea.

Suffice to say arguing to force them into browser as primitives is demanding that they should be set in stone as is.

This index has a lot of noise.

I would go even further and state that TIOBE is deprived of any meaningful value. It's basically a index that tracks web noise. I mean with TIOBE, C++'s ranking goes up if someone writes a blog post with a joke that goes "A C++ developer walks into a bar...".

I wouldn't be surprised if this post in HN is contributing to the bump.

TIOBE is what you get from garbage-in.

I wouldn't put much stock in this and I like C++.

I would bet that C++20 led some bloggers to post random stuff with C++ in it.

I thought this would be about APIs as in APIs, that is the general concept which goes back decades, not REST APIs.

I agree, the description is not ambiguity-free. However do keep in mind that in web development the concept of an API is rather unambiguous.

Once I bought from Amazon a pack of 4 or 5 USB cables from a seller which had good reviews. Once they arrived, they all broke in a matter of 2 weeks. I mean every single cable in that pack was busted after 2 weeks of use.

Based on my infuriating experience with the product I posted a 1 star review stating that all cables broke. After a week or so of posting that review I started to be spammed by the seller with offers of a 10$ or 20$ refund and a brand new pack of USB cables provided I recanted my review. By spam I mean the seller sent the same canned response about 7 or 8 times repeatedly bribing me to recant my review.

Thanks for the insightful post, specially the Dyck language plug. Really cool stuff.

I'm not sure what's your personal definition of REST but REST according to Roy Fielding's definition is an architectural style that helps design APIs that are as loosely coupled as it gets. In fact, I'm not sure what style of APIs you feel improves upon REST on this criteria.

It sounds you're describing faults, aren't you? I mean, don't you agree that exceeding the breaker's capacity is a fault?

https://en.wikipedia.org/wiki/Circuit_breaker

I don't believe this is up for discussion: the circuit breaker is a device that is designed and used to protect a circuit against fault conditions. That's the whole point of their use: if a fault condition is detected, the circuit breaker breaks the circuit to about the fault to propagate or damage the circuit and/or any device connected to it.

What many fail to understand is that disinterest in Github absolutely does not tell you anything meaningful about that programmer.

Well, it does. It says he doesn't have a portfolio for some reason. Is it because he is incompetent and has nothing to show for? Perhaps not, but if the candidate makes it difficult for recruiters and interviewers to get an objective way to corroborate his claims regarding his level of expertise then just for the sake of avoiding wasting your time with yet another paper tiger... It would be better to cut him out of the shortlist for further interviews.

In my case, I have found trying to contribute to open source to be a huge waste of time.

You mentioned the full extent of your attempt at contributing to open source consisted of a grand total of two meager pull requests.

I'm sorry to say but if throughout all those years you only managed to put together two patches then quite obviously you did close to zero contributions, both in absolute and in relative terms.

In fact, it seems you complain more about floss than actually contribute stuff.

I find that I general it's terribly easy to get your pull requests accepted to random FLOSS projects. Whether your PR is janitorial work, fixing bugs or adding features, you don't need much work to get your contribution in. So, quite frankly it sounds like you are grossly exaggerating and overstating not only the extents of your work but also the challenges you supposedly face.

Then there's the issue of dependencies. My cool tool for analysing satellite photos won't be of much use to anyone who doesn't have API access to a satellite ground station.

In that case your so called cool tool to analyse satellite photos sounds very poorly designed. I mean, the whole FLOSS earth observation stack is designed literally from the ground up with extensive separation of concerns in mind (see GDAL and proj4 and orpheo toolbox for example) and apparently somehow you failed to learn the lesson that everyone doing professional, academic, and even amateur work knows by heart.

about presenting facts without bias to let the consumer make up their own mind. That doesn't exist in today's over-charged political environment, which is a whole other discussion.

I see this card being played to justify how they ignore and cherry-pick facts that suits their personal agenda, because they treasure their tribal view of politics over making informed, rational decisions.

Plus Rust by design avoids all sorts of bugs leading to less tests imo.

This assertion on the amount to tests makes no sense at all. Tests are not about language features. Tests are about checking invariantes, checking input and output bounds, and checking behavior. Tests focus on the interface, not the implementation. Tests only work if test coverage is high.

Don't you believe it's a good thing to discuss facts and findings about a pandemic which already infected a few million people around the world, and changed everyone's lives?

I mean,in the US alone covid already killed nearly 190k people from a pool of around 6200k infected. Doesn't this justify having informed evidence-based discussions?

To be fair, this was the first time I ever heard of Kelly Marie Tran. Meanwhile John Boyega was a household name.

Does anyone else think this is a Gitlab campaign against overuse of monomorphization in Rust projects?

No,not really. I mean, in healthy projects build times are dwarfed by the time it takes to run tests. In web development projects even the delivery and deployment steps dwarf build times.

The account you've replied to is 19 days old. Not the most subtle sock puppet.