not only possible but sometimes necessary because sometimes you need to sacrifice familiarity and question the assumptions we have to truly make meaningful improvements
True, but why would people use yet another lookalike tool over the one they're currently using? Or is the implication that looks don't matter as long as it works? Because if that's the case, Why do we need CSS?
A better example might be why we build stairs with a standard riser height and tread run. If you've ever accidentally tripped on an unusual or non-standard stair, you already know this.
Users don't need to think about how to use them; they are ubiquitous and familiar, and therefore intuitive and automatic.
If every set of stairs (or, worse, if every stair in a set) was radically different, every time you approached some stairs you would have to think carefully about how to use them so you don't fall.
Your point is true, but the one I was replying to was focusing on the aesthetic aspect. For them, the sameness of UIs, while functional, make for a drab experience.
My point is that I don't find this to be case. Rather, consistent UIs, while functional, are also beautiful to me. The constituents of the UI can be designed with aesthetic taste, but the way it is all put together consistently and functionally has a beauty all its own.
Sorry, dumb question: is "mozilla.ai" related to "mozilla.org" and to the larger Mozilla organization? Because changing the tld makes this actually non-obvious. I see "mozilla.ai" and I think "someone is trying to phish".
Common question, thanks for asking! We’re a public benefit corporation spun out from, and primarily owned by, the Mozilla Foundation. We're focused on democratizing access to AI tech, on enabling non-AI experts to benefit from and control their own AI tools, and on empowering the open source AI ecosystem. We're a small team relative to the "main" Mozilla, which lets us experiment a bit more easily.
We do run into this branding question frequently, and will add some clarity to the website.
I saw that, but anyone can link to anything. Luckily on mozilla.org there's a link to mozilla.ai, so that legitimizes it a bit. But that is not obvious.
Except a lot of actual, very smart, economists are for UBI or similar arrangements (it's not a settled matter). And geohot might be smart, but he's just a self described hacker.
I think the problem is that a lot of the proponents are arguing for a level of UBI that is pretty close to the median wage whereas what would be affordable is probably a quarter of that.
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]
- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- Array.prototype.values https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
This addresses a few criticisms here, and the main criticisms I had.
reply