Many functional and ML-based languages, such as Haskell, OCaml, F#, etc. allow the signature of a function to be inferred, and so a change in the implementation of a function can change the signature.
2,660 karma · joined May 6, 2012
Right, and even more to the point, there's another important property of Rust at play here: a function's signature should be the only thing necessary to typecheck the program; changes in the body of a function should not cause a caller to fail. This is why you can't infer types in function signatures and a variety of other restrictions.
When you break things regularly, you're forcing a choice on every individual package in the ecosystem: move forward, and leave the old users behind, or stay behind, and risk that the rest of the ecosystem moves forward without you. Now you've got a whole ecosystem in a prisoner's dilemma. For an individual, maybe you can make a choice and dig in and make your way along without too much trouble. But the ecosystem as a whole can't, the ecosystem fractures, and if it doesn't converge on the latest version, it slowly withers and dies.
I know the last time I picked it up, there were a well respected set of patches from scient (a quick google pointed me to https://github.com/DrazharLn/scient-unofficial-smacx-patch ). Somewhere in here is a pre-done distribution you can just click and run with for modern windows.
My tl;dr:
The vlang team has repeatedly made false promises and assertions about what the language can do, ranging from a "we put things that are on our roadmap in our features list" to "we've promised something that is outright impossible". Analyzing how this has changed over the years, the only reasonable conclusion is that they're grifters who are okay with lying.
In addition, they regularly engage in flamewars about it on this site, and their moderation practices of silencing any sort of criticism in their own spaces and calling anyone who dares question it idiots are well known and documented.
They don't have to do literally any of this.
Another lame excuse and some faux transparency to go with it.
See this article and the discussions, and if you’re so inclined follow along links in that thread from last time that show folks from the vlang team flaming all over HN.
In order for the fork() it calls to be safe, it needs to guarantee a bunch of properties of the program that it simply cannot. If this gets used in a multithreaded program that calls malloc, you've got UB. There's a long list of caveats with fork mentioned in some other comments here.
In my view, this is not serious code and should be regarded as a joke. There's no actual value in this type of isolation.
https://www.fortinet.com/blog/threat-research/phish-free-pay...
This is wrong in a couple ways. First, Apple ships plenty of GPL code. https://github.com/apple-oss-distributions/bash/blob/bash-13... as an example.
What Apple does not ship is GPLv3 code. GPLv3 had two major changes around patents and "tivoization". The tivoization clause in particular forces changes that break Apple's security model for their hardware, and is probably the core reason they do not ship GPLv3 software.
This part was an important part of the sentence you might've missed.
Go binaries are statically linked by default if they do not call out to any C functions.
Go will automatically switch to dynamic linking if you need to call out to C functions. There are some parts of the standard library that do this internally, and so many folks assume that go is dynamically linked by default.