No. If you don't want to maintain it, don't package it, or for that matter programs written in it. Yes, there are valid reasons not to use zig from a stability perspective, but just ignore it if it isn't good enough for your standards.
Personally I'm glad that there are more people trying to break out of the C tar pit. Even if I'd never chose to use the language.
Trees fall down due to combination of heavy snow and wind. They probably don't cut sufficiently around power lines. It is extra bad if the ground hasn't frozen properly yet.
In some places it may be cheaper to dig down the cable than facing storms.
Makes them a lot easier to get to. Buried infrastructure is fantastic until it breaks. Then it really sucks ass.
A lineman can fix anything on a pole within a few hours. Probably before lunch if they start first thing in the AM. Fixing a buried line can take days or worse depending on what's above it.
> Buried infrastructure is fantastic until it breaks. Then it really sucks ass.
Or if you want to upgrade it. My local electricity provider charges an order of magnitude more for upgrading home electrical service for more amperage if your service line is buried.
When you build a home in the middle of nowhere, you actually have to pay for the power line to be run out to you. Burying utilities is tremendously expensive if you are footing the bill on your own.
It can also be structural. Depending on the elevation, my county mandates houses be designed to survive wind speeds up to 157 miles per hour and snow loads up to 545 pounds per square foot. That means a flat roof would have to be built like a parking garage floor, but a sloped roof can transfer that weight to the exterior walls, and an true A-frame directly transfers the load to the ground.
"static inline", the best way of getting people doing bindings in other languages to dislike your library (macros are just as bad, FWIW).
I really wish someone on the C language/compiler/linker level took a real look at the problem and actually tried to solve it in a way that isn't a pain to deal with for people that integrate with the code.
> I really wish someone on the C language/compiler/linker level took a real look at the problem and actually tried to solve it in a way that isn't a pain to deal with for people that integrate with the code.
It exists as "inline" and "extern inline".[1] Few people make use of them, though, partly because the semantics standardized by C99 were the complete opposite of the GCC extensions at the time, so for years people were warned to avoid them; and partly because linkage matters are a kind of black magic people avoid whenever possible--"static inline" neatly avoids needing to think about it.
Essentially all the most important functions to interact with rings during runtime is static inline. The prep_* methods for sqes are so simple they are not problematic to reimplement, but all the other interactions necessary - submit, advance, peek, wait etc are all static inline, nested several layers. Those are not trivial and details have changed over time.
Thankfully that particular library do nowadays also provide a _ffi version of the .so as it is such an horror otherwise. But there are other libraries out there that don't do that, where it is almost as big of a hurdle to bind with.
I don't see what you're getting at with respect to writing bindings.
The whole point of using "static" in that way is to prevent people from using it outside of the file.
If you need to call a static function (inline or otherwise) from outside of the compilation unit to use the API, then it's a bug in the API, not a problem with static.
I agree with you about pre-processor macros, though.
Here is a use case. I have a function that takes variable parameters, so there is no formal type control:
int Foo(int a, ...);
But in fact the types are restricted depending on a call type, set by 'a'. So I could add a wrapper for a specific variant:
static inline FooVar1(char b, long c)
{
return Foo(FOO_VAR_1, b, c);
}
All the wrapper does is adds a bit of type control during compilation, otherwise it must be just a function call to 'Foo'. It is like a supermacro. It does make sense to put that into 'static inline' in a header.
That is not an option - it may be layers on layers of them and force you to recreate half the library and force you to have to redo subsequent version updates in your code. Then a shim is the preferred solution. But anything that requires a C compiler for FFI is something that won't make anyone happy. Hence my claim that it really is something that needs fixing on the language or linker level.
But FooVar1 isn't part of the library, that's the point. Sure, the library developer could choose to make it a part, but he explicitly choose to not make it a part of the library. Hence, it is also nothing that needs fixing, because it is already possible to make the interface boundary somewhere else, people just choose to do it this way. As far as the language and the linker is concerned FooVar1 is part of your code, not part of the library.
If the language provides nice features to libraries for C language users by sabotaging the library for use outside the language, then this is absolutely a problem on the language side.
The library interface says to do X call `Foo(FOO_VAR_1, b, c)`. That is what you need to somehow call from another language using FFI. In addition it also has an example wrapper for convenience. You can choose to also include that example as part of your implementation in another language, but you don't need to. I fail to see how that is sabotaging.
It also does not have to do anything with the language, because it IS possible to have FooVar1 as part of the interface. The library developer just didn't want that, likely because they do not want tons of slightly different functions in the interface that they would need to maintain, when they already exposed that functionality.
EDIT:
Concerning your earlier complaint, that you would need to
> have to redo subsequent version updates in your code.
, such a change would be ABI-incompatible anyway and demand a change in the major version number of the library. Neither your FFI, nor any program even when written in C, is going to work anymore. The latter, would just randomly crash, not sure about the former.
Note, that you also see here, where the real interface is. A change to Foo itself, would break programs written in C as well as your FFI, while a change to FooVar1 wouldn't matter at all. Both C programs and your FFI will continue to run just fine without any changes.
> likely because they do not want tons of slightly different functions
No. They do it because it avoids the overhead of dynamic dispatch. Nothing else.
So when I've seen these in reality in real library interfaces they have not been 'example wrappers'. They are real intended usage of the API, and in some cases the lib authors recognize that it is a problem and even provide ways to build it without the issues - either by compile time flag or always outputting two variants of the .so. The former moves the question to the distro - should they provide the version optimized for C or the one optimized for other languages? In the case of the latter it obviously creates a situation where the vast majority of both .so-s are duplicated.
As an example of the compile flag, there is libpipewire. As an example of providing two versions of the .so, there is liburing.
So no, this is clearly something the language ecosystem lacks a good answer to. There is currently no way to make everyone happy.
> such a change would be ABI-incompatible anyway
True, but the C based ones can at least simply rebuild and the problem would go away.
Modern libraries consistently use `static inline`, to avoid the overhead of dynamic dispatch. Just take a look at liburing, and the client libraries for pipewire and wayland. All of them have `static inline` all over the place, for methods that are definitely intended to be called.
my point was that f() had been defined static then you can't access it from outside the translation unit it is defined in - in other words, it is "private". i'm afraid i'm unclear what your point is.
For most purposes, not being able to access something, and being able to access something not officially in an interface, where doing so introduces an unpredictable breaking dependency, the practical result is the same: You can't (actually/sensibly) do it.
What if I want to internally access it from multiple compilation units, but not necessarily encourage downstream users from using it? This is really common.
It's going to become private, but its part of your side of the interface, not of the other side. The ABI boundary is between that `static inline` function and the library, not between that function and your code.
Doesn't help. The point is to avoid having to invoke a C compiler when working in X language. But it would certainly be nice if the distros enabled that.
3 has a really nice feel when you manage to get the early timing attacks off against the neighbours, but the later half of the game is too solved - the game ends with infantry + artillery stacks being the only units you need, and with the 3x4 city grid bring optimal.
4 in contrast had a bunch of different paths to power, and those worked even on high difficulties. There were also no optimal city grid the same way (though still being denser than civ5).
Yes, if you don't follow EU laws prepare to not do business in Europe. Likewise, if you don't follow US laws I'd advise against trying to do business in USA.
>Yes, if you don't follow EU laws prepare to not do business in Europe.
Sure, that's what laws are for. Surely we can still point at those laws and question their motives though.
Spanish PM plainly stated a sort of editor framework of responsibility for platforms. This is the same country that strongly advocates for Chat Control within the EU, also looking for a similar under-16 ban on social media.
So the same government is at once looking to deanonimize social media users, revoke their privacy regarding communications, and to enforce moderation standards never seen before. This is, supposedly, a center-left + left coalition mind you.
Same country that blocks a chunk of the internet when a LALIGA football match is on, too. Lawfully of course. All of this is preposterous, making it the law doesn't make that better it makes it far far worse.
If X/Twitter was to be banned in the EU, and some of its citizens still wanted to access X/Twitter, let us say for the sake of getting alternative points of view on politics and news, would it be a good or a bad thing if accessing X/Twitter by IP was stopped?
As in, a citizen of an EU country types x.com/CNN, because he or she wants to know the other side of some political issue between the EU and the USA, and he or she feels that the news in the EU might be biased or have misunderstood something. Would it be good or bad if the user was met with a "This website is by law not available within the EU"?
Generally speaking I wouldn't support blocking their IP, but rather I'd block the ability of European companies to pay for ads on X unless they fixed their shit and paid any damages. That might of course lead X to block Europe visitors in turn but that is a different discussion.
Or in other words: I would block the do business-part, not the access part.
Like anything involving hundreds of millions of users, there's going to be good or bad effects. However I have been on the internet long enough to have concluded that the idea that local law has _no effect at all_ on websites is not good. Ultimately if they don't comply they would probably have to be blocked.
CNN is a very silly example though, because .. you can just go to the CNN website separately. The one that is blocked is Russia Today and various other enemy propaganda channels.
there's a push to end with VPNs in the UK and in the EU because it's clear that this is a very plausible endgame
currently VPNs are too easy to use for the leadership of autocracies like the EU or the UK to be comfortable with them, so at the very least they will require for backdoors to see which citizens are watching what, and have them visited by fellows in hi-vis jackets
> there's a push to end with VPNs in the UK and in the EU
No there isn't.
Governments discussing such things doesn't _remotely_ mean there is a political will for them, or that they will be voted into law.
Governments are expected to research and discuss paths of legislation (and in this case, come to the conclusion banning VPNs is both harmful and ridiculous). This is how our democracies work!
Reporting government discussions as approved legislation is, at best ignorant, at worst trolling.
I’m reminded of Lord Haw-Haw, an English-speaking Nazi propagandist during WW2 that garnered quite a bit of attention for his radio broadcasts.
There’s an interesting tidbit that he gained quite a few listeners when he started releasing casualty information that the British government withheld to try to keep wartime-morale high.
Lord Haw-Haw then tried to leverage that audience into a force of Nazi sympathy and a general mood of defeatism.
Anyway, fun anecdote. Enemy propaganda during wartime (or increased tensions) is harmless until it isn’t.
I would have thought that the Great Firewall of China would be a more obvious thing to be reminded of. Especially since there is no world war currently, yet, at least, and communication might help stop one.
Once there’s a fascist regime with ambitions of world domination that documents their horrors more thoroughly (and has their enemies document their horrors more thoroughly) than the Nazis then we can start referencing that regime instead.
Conveniently, at least in the US, WW2 is old enough to be “history” rather than “politics”, compared to Korea and Vietnam. Or, at least that’s the excuse I was given in AP US History when the curriculum suddenly ended at 1950. So WW2 will continue to be the most well-documented topic that we’re all educated enough about to collectively reference.
Trust me, I’d much rather speak plainly about the horrors of the atrocities that the US committed in the 20th century American but we’re not there yet because the people who grew up in the nation while it committed those atrocities still run the government and basically the nation in general.
Edit: also if it wasn’t obvious I was comparing Musk to Haw Haw. I don’t know if there is an equivalent for China
I’ll admit to being misinformed on occasion, and greatly appreciate the opportunities to learn and be corrected.
Dishonest, though? To what end? If anything, the anonymity of the internet allows me to test my more weakly-held fringe beliefs and adjust them as I receive feedback.
I get the impression that you’re not well-informed enough to have a meaningful conversation about these difficult topics, though you may hold an opinion with significant conviction. Sorry.
Just to clarify – are we agreeing both are unreasonable, or is your point that both are reasonable and EU fines even more so?
If you're arguing that DOJ fines on European banks are more unreasonable than EU fines on US tech companies that's fine with me. But that wouldn't make either reasonable or my comment "ridiculous".
The whole thing is essentially a workaround for lack of sufficiently good/easy ways to package code in the ways people want to use it.
reply