521–530 of 667 posts
Earlier quoted context omitted.
It's true that metacommenting about leaving a discussion in order to leave a supercilious last word is a flamebait trope. But please don't respond by breaking the site guidelines yourself. That only makes things worse. https://news.ycombinator.com/newsguidelines.html
Understood, I've read the guidelines and will endeavour to follow them.
To me this merely signals how broken C++ development really is. Most if not all of the bugs being uncovered are memory related and therefore intimately tied to the mental memory model of C and C++, namely manual memory management. It's fine for a C or C++ program encompassing a couple hundred lines but beyond that it's a liability. C and C++ are simply not fit for purpose when large scale software projects are concer…
C++ has had smart pointers for memory (and other resource) management for a long time now (see e.g. the Windows ATL classes for working with COM objects and resources). There are a number of challenges that make browsers more challenging (even in memory safe languages like Swift and Rust). 1. Back references/pointers like `parentElement` to other objects in the graph that create dependency cycles (where traditional/s…
Maybe Rust let's you encapsulate the unsafe a little better than C++ but the wins are going to be surprisingly small. If you had to build it today you'd maybe use Rust but the case for rewriting an existing C based runtime in Rust is not that strong.
Also for things like interpreter loops the absence of computed goto in Rust stable is a real performance killer. Explicit tail calls (the `become` keyword in nightly) work but maybe you don't want your big rewrite to rely on that.
To me this merely signals how broken C++ development really is. Most if not all of the bugs being uncovered are memory related and therefore intimately tied to the mental memory model of C and C++, namely manual memory management. It's fine for a C or C++ program encompassing a couple hundred lines but beyond that it's a liability. C and C++ are simply not fit for purpose when large scale software projects are concer…
I'll await your Rust ports of Windows, Linux and MacOS then. This isn't really a fair take. Keep in mind that C/C++ has been the backbone of the most important software in the world since the 1970s. At that time we didn't have virtually unlimited compute and memory at our fingertips the way we do now. It was a huge improvement to have a high level language which still could be optimized nearly as well as assembly. It…
Unironically this. Like most game developers, I was extremely sceptical of Rust, based on opinions I've read on the internet. Ugliest syntax I've ever seen, and "safety" features are irrelevant and just get in my way. Compile times are glacial. Tons of direct and indirect dependencies needed.
But then I got to use it professionally for a year or so, and I was MINDBLOWN by how much less stuff I have to keep in my working memory at all times. And libs like tokio and actix-web were so well-designed that I actually enjoyed reading the code in my free time. Fighting the borrow checker? I had like five such instances in the first month, understood what it wants and why, and it never bothered me again. Compiles were indeed slow, but I went from "if it complies the first time around, I'm probably missing something" to "if it compiles the first time around, it's most likely correct".
Turns out, I had significantly underestimated what Rust brings to the table, while focusing on stuff that wasn't really that important once you get used to it.
Nowadays I'm back to gamedev. I'm happy about that, because my year in cloud/edge dev felt like we were consistently solving the wrong problems. But I do wish my current team was more open to giving Rust a chance. It solves so many actual problems, and is being dismissed with reasoning like "sorry, I don't have programming socks". And by very smart people! WTF is this timeline?
Earlier quoted context omitted.
> That is true, I was mostly speaking about a supposed need to review the code. Until you go to prod, you can believe a lot of things about the state of your code. Reviewing code is not merely about “Does this things work”. Testing and linting do cover most of that. Reviewing is mostly about: Will this design cover the current set of constraints (some may be conformance) and can it evolve? Are the assumptions correct…
In the context of a mobile app the user interface is the main part. Testing and linting often do not cover whether things work or provide decent UX. The 'security layer' is almost irrelevant here. Do you do mobile app development? I would guess not.
Even though a lot of mobile app are just presentation layer for a backend service, there are indeed a few stuff that warrants carefulness.
Like any data saved offline. Any update to that offline format means a migration plan unless it’s just a cache for the online data. Then if you support something like multiple organization, you don’t want user data to jump the separation between those siloes. And finally, if you you data that are created locally, or present data that are transformed locally using some feature, you have to be sure you’re not corrupting it or open some side vulnerabilities (think about the clickable vulnerability in messaging apps).
UX and UI can be designed using a prototyping tool coupled with user feedbacks. And with the wealth of components in the mobile SDK and the UI toolkit ability to create custom widgets, it’s very easy to implement the final version of that design. Most of the delicate work is presenting the correct information and that each interaction proceeds well.
Worrying. Extrapolating a (speculative) future, this means (Google will feel) that soon the chromium base will no longer need the crowd-sourced bug hunting that is open-source. I expect Google to eventually stop working on chromium (in the open) and all current chromium-flavours will become de-facto forks of the last published version of chromium. These forks won't be equally easy to maintain given that the groups ru…
Worrying. Extrapolating a (speculative) future, this means (Google will feel) that soon the chromium base will no longer need the crowd-sourced bug hunting that is open-source. I expect Google to eventually stop working on chromium (in the open) and all current chromium-flavours will become de-facto forks of the last published version of chromium. These forks won't be equally easy to maintain given that the groups ru…
Conversely, it has never been more feasible for alternative web browsers to be created and maintained outside of big tech.
Earlier quoted context omitted.
Conversely, it has never been more feasible for alternative web browsers to be created and maintained outside of big tech.
Yet, no one's taken Cursor's fastrender to production.
Earlier quoted context omitted.
Yes, sort of. Not that there is anything wrong with that. Fuzzing yields tons of trash results, the occasional fleck of gold and the even more rare nugget. Then you analyze how it found the flakes and nuggets update your fuzzing harness. Every so often you get to write a paper or give a talk about a breakthrough to share meaningful improvements. Current AI isn't super effective at making the breakthroughs, but it sur…
What does that mean? Democratising the breakthroughs you can point LLMs at?
That's democratization - shifting power and skills away from those with the wealth to purchase vulns and run offensive security teams. It's still not simple, but it's one of the reasons bigger vendors want to lock down the capabilities of models that present a threat to the wealthy and powerful.
Earlier quoted context omitted.
Somehow, magically, some people managed to write C software that I now use for three decade with not a single crash in all this time.
What software would that be, and how do you know there have never been memory-related bugs and vulnerabilities in it?