This is certainly not true. But also arguments about "common" are completely misleading as long as there is many orders of magnitude more C code than Rust code.
Maybe you haven't been paying much attention in this space. Google found empirically that error density in _unsafe_ Rust is still much lower than in C/C++. And only a small portion of code is unsafe. So per LOC Rust has orders of magnitudes fewer errors than C/C++ in real world Android development. And these are not small sample sizes. By now more code is being written in Rust than C++ at Google:
But don't take my word for it, you can hear about the benefits of Rust directly from GKH:
www.youtube.com/watch?v=HX0GH-YJbGw
There really isn't a good faith argument here. You can make mistakes in Rust? No one denies that. There is more C code so of course there are more mistakes in C code than in Rust? Complete red herring.
I would expect that the largest factor is cultural, and of course it's possible to inculcate safety culture in a team working on a C or C++ codebase, but it seems to me that we've shown it's actually easier to import the culture with a language which supports it.
Essentially Weak Sapir–Whorf but for programming languages rather than natural languages. Which is such a common idea that it's the subject of a Turing Award speech. Because the code you read and write in Rust usually has these desirable safety properties, that's how you tend to end up thinking about the problems expressed in that code. You could think this way in C, or C++ but the provided tooling and standard libraries don't support that way of using them so well.
I also think that the largest factor is cultural. But my conclusion from this is not that one should import it with a new language while pretending achieving similar results is not possible otherwise. This just gives an excuse for not caring for the existing code anymore, which I suspect is one reason some parts of the industry like Rust ("nobody can expect us to care about the legacy code, nothing can be done until it is rewritten in Rust")
Of course highly correct C code is possible [1]. But ADA makes it easier. Rust makes it easier. You can write anything in any language, that is _not_ the argument. How could you plausibly advocate for a culture that invests a lot of effort [1] into making codes correct, and not also advocate for tools and languages that make it easier to check important aspects of correctness? A craftsman is responsible for his tools. Using subpar tools with the argument that with sufficient knowledge, skill and an appropriate culture you can overcome their shortcomings is absurd.
Rust is also often not the right tool. I looked at it fairly deeply some years ago for my team to transition away from Python/C hybrids, but settled on a fully garbage-collected language in the end. That was definitely the right choice for us.
The thing is. There always was a strong theoretical case that Rust should improve software quality (not just because of the fact that you have a lifetime system). The only reasonable counterpoint was that this is theory, and large scale experience is missing. Maybe in high quality code bases the mental overhead of using Rust would outweigh the theoretical guarantees, and the type of mistakes prevented are already caught by C/C++ tooling anyways?
The (in recent years) rapid adoption of Rust in industry clearly shows that this is not the case.
What about qmail? No one runs qmail and no one is writing new C with that kind of insanely hyperconservative style using only world-class security experts.
And it still wasn't enough. qmail has seen RCEs [0, 1] because DJB didn't consider integer and buffer overflows in-scope for the application.
Perhaps because qmail is an anomaly, not Android? To remain relatively bug-free, a sizeable C project seems to require a small team and iron discipline. Unix MTAs are actually pretty good examples. With qmail, for a long time, it was just DJB. Postfix has also fared well, and (AFAIK) has a very small team. Both have been architected to religiously check error conditions and avoid the standard library for structure manipulation.
Android is probably more representative of large C (or C++) projects one may encounter in the wild.
So you can't, and if a "dumbass" like me can understand the importance of empirical evidence but you can't, maybe read up on rational thinking instead of lashing out emotionally.
At some point I looked into it, and if the laws were what they are today, Disney wouldn't have been able to make Alice in Wonderland (1951) without paying Lewis Carroll's (d. 1898) estate until 1968. The Little Mermaid (1989) was safe though, since Hans Christian Andersen died in 1875 (so his copyright would have expired in 1950).
(OP) yes, the suffix clarifying it's a claim ("expert tells...") was too long for HN so I clipped it off and added the quotes. Leaving them off would have indicated a fact instead. Happy for any appropriate change to be made to better reflect the original title.
I've been quite taken with Go these last few months and I wish the western world had more skilled players. The Asian servers do not do much (if any) i18n, they don't need to, they aren't many players outside Asia.
I've been fortunate that one of my high school friends is a 4 dan EGF player and that he has taken lots of time to play with me and teach me. But I can see other beginners struggling with the basics because they're only playing other low-skilled players.
I wish the western world paid Go more attention, it's a beautiful game with a really nice balance.
Some things that may be of interest. First relevant to the posted article:
A site that has used neural nets to classify go moves that good players would probably make that weaker players (of varying ranks) would probably not: https://neuralnetgoproblems.com/ (code available on github)
https://ai-sensei.com/challenge (behind login wall, and in future possibly a pay wall) is a similar idea, but the difficulty of evaluating the position is determined by how users of the site perform in practice.
And more generally, but relevant to your comment:
Players can play humans at an appropriate rank on OGS https://online-go.com/ (not as popular as the Eastern servers, but probably popular enough) -- or against calibrated rank "human-like" AI players by painfully setting up the right katago models themselves, or by paying for a subscription on ai-sensei.com
A go education site that's currently largely by and pitched at Westerners: https://gomagic.org/ for leveling up from the basics.
And a lot of books are now available easily and electronically in English (and some in German): https://gobooks.com/ --- I'd recommend "graded go problems for beginners", "tesuji", and "attack and defense".
Some good sites aren't (fully) available in English, like https://www.101weiqi.com/ -- but there are chrome and firefox extensions to translate just enough of it to make it usable.
[To help search engines: go is also known as weiqi and baduk]
I've been writing code (and prose) with 3 vertical rulers for almost 10 years now: 66, 80 and 120 characters each. None of them are hard limits for me. But they do help guide my eye.
Most lines fit under 66. A lot more than 50%, even code written by other people. I'd say most lines also fit under 80, and very rarely do lines actually cross 120.
I agree hard limits aren't usually a good idea. Especially because they complicate auto-formatting (the Prettier algorithm which is clearly the best doesn't support them). Also sometimes you want to paste a long URL and that's a pain with hard limits.
>Very weird reasoning. Without AlphaGo, AlphaZero, there's probably no GPT ? Each were a stepping stone weren't they?
Right but wrong. Alphago and AlphaZero are built using very different techniques than GPT type LLMs. Google created Transformers which leads much more directly to GPTs, RLHF is the other piece which was basically created inside OpenAI by Paul Cristiano.
Google Brain invented transformers. Granted, none of those people are still at Google. But it was a Google shop that made LLMs broadly useful. OpenAI just took it and ran with it, rushing it to market... acquiring data by any means necessary(!)
As did Google. They had their own language models before and at the same time, but chose different architectures for them which made them less suitable to what the market actually wanted. Contrary to the above claim, OpenAI seemingly "won" because of GPT's design, not so much because of the data (although the data was also necessary).
Agreed - AlphaGo/Zero's reinforcement learning breakthroughs were foundational for modern AI, establishing techniques like self-play and value networks that influenced transformer architecture development.
Not really shocking considering how Japan likes conglomerates.
Hyundai makes cars and military weapons and probably thousands of other things that aren’t even related to each other, don’t know if they still make computers.
To nitpick: Hyundai are Korean but the Korean Chaebols are in many ways even more dominant than Japanese Keiretsu (fmr. Zaibatsu) are. Mitsubishi would be a good Japanese example.
> HTTP/1.1 is inherently insecure and consistently exposes millions of websites to hostile takeover.
On August 6, James Kettle from PortSwigger Research will reveal new classes of desync attack, that enabled him to compromise multiple CDNs and kick off the desync endgame.
> Follow PortSwigger for the full reveal.
With a timer on top.
So yeah, I guess we may know nothing much from them until then.
I meant "empty" of actual information. I'll guess there'll be more on the date. But for now that's just weird and suspect, trying to raise hype for a security related announcement ? weird and suspect
FYI, maybe for you and other readers. My key to really understanding clap's derive macro was to understand that the macros takes as argument every methods of clap's Command struct https://docs.rs/clap/latest/clap/struct.Command.html
Looking at this resolved most of my issues about discoverability.
reply