> I am puzzled by the claim that C and assembly are not relatively close.
Did anyone say that?
I think the point is not that it is not "close", but that C is not equivalent to ASM: C has its own abstractions, and there are things you can do on assembly that you can't express in C.
The other low level languages such as C++, Rust, Zig, ... are equally close since you can express the same things. In some respect they are even closer since they got more features builtins that modern assembly can now do that was not part of the design in C. (SIMD, threading, ...)
Modern languages also have extra abstractions that makes programming easier without compromising on the cost. There are more abstractions than in C, but they also are optional. (Just like you could use goto instead of while or for loop, but you're happy this abstractions exist. We could also use functions pointer in C++ instead of virtual functions, but why would we if the language provide tools that make programming easier, for the same result)
> The other low level languages such as C++, Rust, Zig, ... are equally close since you can express the same things.
C is not just low level friendly, but low level out of the box. That is the level that all C must be written in, even when creating higher abstractions.
Some higher level languages are also low level friendly, not low level strict. Which is a kind dual.
I would argue that what makes C lower level, is that it comes in at, or under, the low levels of other languages, and its high bar comes in much lower than the abstractions built into other languages.
Forth is a good candidate for being even lower level.
But if someone else doesn't see things that way, that is fine. It is just one lens for comparing languages.
> C is not just low level friendly, but low level out of the box. That is the level that all C must be written in
No, it is not:
- People use for/while loop, for example, instead of the "low level" 'goto'
- C compiler compute pointer aliasing, assume operations don't overflow, etc., in order to optimise your code: What you write doesn't translate directly to assembly.
- Some low level operations cannot even be represented in pure C (without using __asm__ extension escape hatch)
a term falling out if use does not make it foreign. even if no longer common pommes frites is still a french term. the french wikipedia page also does not give any indication that the term is no longer used.
eh, 30cm of broken ragged ice, a light layer of snow over top ... that's a Saskatoon Saskatchewan winter road.
so a LOT worse. heck the car does not handle it very well.
the wind makes it worse for clothing too, mind I have driven a jeep without a windshield or roof at -40C and that was more cold than I ever want to repeat. It was rather worse than working out in a field with survey gear at -55C and white out winds...
There is already arbitrary tariff. At this point, it is better to trade with other countries instead of chasing the US. Let the American citizen pay their tariff, their loss.
If the Us imposes sanctions such as "no more login to any Google/Apple/Microsoft/... accounts from EU citizens until they give Greenland".
Many European companies would stop to a halt as they can't access any documents they have "on the cloud" or maybe can't even access their own phone or computer.
I think this particular scenario is far fetched as that would be economic suicide for the US, an empire-ending decision. And while not everyone has backups, many/most of the important companies do so they would eventually recover.
> Many European companies would stop to a halt as they can't access any documents they have "on the cloud" or maybe can't even access their own phone or computer.
I hate that "Nobody got fired for choosing IBM" is a thing and that the people suggesting that we have good enough FOSS options when things were being planned out were probably given a dismissive look by the business people who were promised the sky by MS salesmen.
At least that's how I imagine it probably looked, given my own past experience of suggesting PostgreSQL and in the end the project going with Oracle (it's okay when it works, but for those particular projects PostgreSQL would have worked better, given the issues I've seen in the following years). It's the same non-utilitarian / cargo-cult thinking that leads to other solutions like SQLite not being picked when the workload would actually better be suited for it than a "serious" RDBMS with a network in the middle.
Apply the same to server OSes (Windows vs Linux distros and even DEB based distros vs RPM RHEL-compatibles), MS Office vs LibreOffice when you don't even need advanced features and stuff like Slack/Teams vs self-hosting Mattermost or Zulip or whatever. It's not even jumping on untested software, but fairly boring and okay packages (with their limitations known that are objectively often NOT dealbreakers) and not making yourself vendor-locked (hostage).
I guess I could also make the more realpolitik take - use MS, use Oracle, use whatever is the path of least resistance BUT ONLY if you're not making yourself 100% reliant on it. If Microsoft or Google decides they hate you tomorrow, you should still have a business continuity plan. If systems have standby nodes, why not have a basic alternative standby system, or the ability to stand up a Nextcloud instance when needed for example (or the knowledge and training on how to do that)? If people had govt. services before computers being widespread and you can have people processing a bunch of paper forms, then surely if push comes to shove it'd be possible to standup a basic replacement for whatever gets borked while ignoring all of the accidental complexity (even if it'd mean e-mailing PDFs for a while). Unless someone builds their national tax system or ID system on a foreign cloud, then they are absolutely fucked.
I don't think it's easy to replace ENTRA feature-wise with European provider.
Or github if you're using a bit more than self-hosted gitlab can provide.
It's not always about the location, it's usually about features (how it integrates into other hardware/software) rarely prices.
For example, can you suggest firewalls for offices that aren't either American or Israeli? We'd need something to replace Palo Alto, Bluecoat, Fortigate and Juniper. Also it'd be good to replace Cisco VPNs to be honest.
But it kind of must be feature parity, because (European) regulators hold our balls over hot coals.
C++ was the GUI king during the 1990's, and none of the Rust toolkits is half as good as the surviving frameworks, like C++ Builder, Qt, wxWidgets, heck even MFC has better tooling.
Trying to defer to native widget rendering per platform was a mistake, and every time I've touched wxWidgets in the past decade and a half I've regretted it.
FLTK on the other hand is ugly as sin, but I've found it reliable enough to not act in surprising ways, and it's also small enough to where you can vendor it and build it alongside your program.
I already have this feeling on french-speaking forums where everything is very France-centric despite there are french speaking people from other countries reading it.
Did anyone say that? I think the point is not that it is not "close", but that C is not equivalent to ASM: C has its own abstractions, and there are things you can do on assembly that you can't express in C.
The other low level languages such as C++, Rust, Zig, ... are equally close since you can express the same things. In some respect they are even closer since they got more features builtins that modern assembly can now do that was not part of the design in C. (SIMD, threading, ...)
Modern languages also have extra abstractions that makes programming easier without compromising on the cost. There are more abstractions than in C, but they also are optional. (Just like you could use goto instead of while or for loop, but you're happy this abstractions exist. We could also use functions pointer in C++ instead of virtual functions, but why would we if the language provide tools that make programming easier, for the same result)
reply