151–160 of 230 posts
Earlier quoted context omitted.
C and modern C++ are so different that lumping them together in a blanket assertion doesn't really carry much meaning.
It is true that they are different, but also, given the significant overlap between the two, people will reasonably talk about them together.
Earlier quoted context omitted.
Note that this can lead to horrid economics for the user. An example being Google unilaterally flipping on VP8/VP9 decode, which at that time purely decoded on the CPU or experimentally on the GPU. It saved Google a few CPU cycles and some bandwidth but it nuked every user's CPU and battery. And the amount of energy YouTube consumed wholesale (so servers + clients) skyrocketed. Tragedy of the Commons.
Do you have an article about this? What is the state now?
It's been a long time since I've seen a VP8 video on YT, so I'd assume it's not even used anymore due to worse compression.
Earlier quoted context omitted.
That's not really the most charitable reading of GP's comment. I think they very clearly mean that Apple does not sell Macs with non-HiDPI displays anymore . It's not a configuration they sell, so they don't need to support those features anymore in their current offerings. You're right that there's nothing stopping someone from hooking up an HDMI-to-VGA adapter for their 22" Trinitron from 2001, but that doesn't mea…
> It's not a configuration they sell So what is the "configuration they sell" for the desktop Macs? The Studio Display that costs way too much for what it is, so to no one's surprise, they're not selling all that many of those? Or the Pro Display XDR for which the stand alone costs more than an entry-level Mac Mini? Sure no one will buy a $1600 monitor to use with their $600 Mac Mini. They'll get a much cheaper third…
If you want a 2k monitor you can buy one and hook it up, but Apple isn't interested in making it look good. It's a not new decision, either. They stopped selling Macbooks without Retina displays in 2016. They haven't supported 2k scaling since the M1 Mac Mini over 5 years ago: https://www.macworld.com/article/549493/how-to-m1-mac-1440p-...
Apple is not a budget vendor. They're a premium vendor. That's not just what other people call them. It's what they themselves profess to be. That's why you can get an Apple Thunderbolt cable for $70. To Apple, if you buy a Mac Mini, yes they're expecting you to hook it up to a 4k monitor. They expect you to be getting a Mac Mini because you want a Mac, not because you can't afford a Macbook.
Earlier quoted context omitted.
Yes, a SWE-year is a common unit of cost. And there are internal calculators that tell you how much CPU, memory, network etc a SWE-year gets you. Same for other internal units, like the cost of a particular DB. This allows you to make time/resource tradeoffs. Spending half an engineer’s year to save 0.5 SWE-y of CPU is not a great ROI. But if you get 10 SWE out of it, it’s probably a great idea. I personally have use…
Note that this can lead to horrid economics for the user. An example being Google unilaterally flipping on VP8/VP9 decode, which at that time purely decoded on the CPU or experimentally on the GPU. It saved Google a few CPU cycles and some bandwidth but it nuked every user's CPU and battery. And the amount of energy YouTube consumed wholesale (so servers + clients) skyrocketed. Tragedy of the Commons.
Implementing VP9, enabling it, transcoding videos and testing it COST SWE hours, it didn't save them. It also cost resources.
In what way did you envision the VP9 issue being related to SWE/resource hour computations here?
> Merely keeping up with the stream of issues found by fuzzing costs Google at least 0.25 full time software engineers I like this way of measuring extra work. Is this standard at Google?
Earlier quoted context omitted.
The best libraries are libraries that have a clearly defined goal, hit that goal, and then don't change until the goalposts get moved. Something that happens only very slowly in font land. Its age is completely irrelevant other than as demonstration that it did what it set out to do, and still performs that job as intended for people who actually work on, and with fonts.
I don't think you understand how backwards it is. My patch that makes SDF rendering 4x faster was not accepted, presumably because floating point-maths is some strange new-fangled technology. Freetype uses antiquated fixed-point integer maths everywhere. See https://gitlab.freedesktop.org/freetype/freetype/-/merge_req...
Sure, a compile-time option to use one or the other might sound reasonable, but then that's two different code paths that need to be maintained and tested. Are you willing to do that maintenance on an ongoing basis?
And can you be certain that switching to floating-point doesn't change the results of calculations in various ways that actually matter for rendering? Are you willing to put in the time to test that thoroughly?
Instead of engaging with the developer, you just ignored them and moved on. I certainly wouldn't want to merge a patch into one of my projects if it came from someone with your attitude.
This is the true power of Rust that many are missing (like Microsoft with its TypeScript rewrite in Go): a gradual migration towards safety and the capability of being embedded in existing project. You don't have to do the Big Rewrite™, you can simply migrate components one by one instead.
Hi, I lead Chrome's Rust efforts. I think the Typescript folks made a great and well-reasoned decision.
In entirely unrelated news, I think Chrome should totally switch engines from V8 to a Rust built one, like hmm... our / my Nova JavaScript engine! j/k
Great stuff on the font front, thank you for the articles, Rust/C++ interop work, and keep it up!
This is the true power of Rust that many are missing (like Microsoft with its TypeScript rewrite in Go): a gradual migration towards safety and the capability of being embedded in existing project. You don't have to do the Big Rewrite™, you can simply migrate components one by one instead.
> like Microsoft with its TypeScript rewrite in Go Go is also memory safe.
Earlier quoted context omitted.
> like Microsoft with its TypeScript rewrite in Go My understanding is that Microsoft chose Go precisely to avoid having to do a full rewrite. Of all the “modern” native/AoT compiled languages (Rust, Swift, Go, Zig) Go has the most straightforward 1:1 mapping in semantics with the original TypeScript/JavaScript, so that a tool-assisted translation of the whole codebase is feasible with bug-for-bug compatibility, and…
As I understood their arguments it was not about the effort needed to rewrite the project. It was about being able to have two codebases (old and new) that are so structurally similar, that it won't be a big deal to keep updating both