Comments URL: https://news.ycombinator.com/item?id=47549722

Points: 2

# Comments: 0

Throwing an async mutex to fix the lack of atomicity before yielding is basically telling me that "i don't know when I'm calling await in this code so might as well give up". In my experience this is strongly correlated with the original designer not knowing what they are doing, especially in languages like JavaScript. Even if they did understand the problem, this can introduce difficult-to-debug bugs and deadlocks that would otherwise not appear. You also introduce an event queue scheduling delay which can be substantial depending on how often you're locking and unlocking.

IMO this stuff is best avoided and you should just write your cooperative multi-tasking code properly, but this is does require a bit more advanced knowledge (not that advanced, but maybe for the JS community). I wish TypeScript would help people out here but it doesn't. Calling an async function (or even normal functions) does not invalidate type narrowing done on escaped variables probably for usability reasons, but is actually the wrong thing to do.

[1]: https://www.npmjs.com/package/async-mutex

Comments URL: https://news.ycombinator.com/item?id=45858011

Points: 3

# Comments: 2

I know people mention 1 pixel lines (perfectly horizontal or vertical). Then they go multiply by 1.25 or whatever and go like: oh look 0.25 pixel is a lie therefore fractional scaling is fake (sway documentation mentions this to this day). This doesn't seem like it holds in practice other than from this very niche mental exercise. At sufficiently high resolution, which is the case for the display we are talking about, do you even want 1 pixel lines? It will be barely visible. I have this problem now on Linux. Further, if the line is draggable, the click zones becomes too small as well. You probably want something that is of some physical dimension which will probably take multiple pixels anyways. At that point you probably want some antialiasing that you won't be able to see anyways. Further, single pixel lines don't have to be exactly the color the program prescribed anyway. Most of the perfectly horizontal and vertical lines on my screen are all grey-ish. Having some AA artifacts will change its color slightly but don't think it will have material impact. If this is the case, then super resolution should work pretty well.

Then really what you want is something as follows:

1. Super-resolution scaling for most "desktop" applications.

2. Give the native resolution to some full screen applications (games, video playback), and possibly give the native resolution of a rectangle on screen to applications like video playback. This avoids rendering at a higher resolution then downsampling which can introduce information loss for these applications.

3. Now do this on a per-application basis, instead of per-session basis. No Linux DE implements this. KDE implements per-session which is not flexible enough. You have to do it for each application on launch.

[1]: https://en.wikipedia.org/wiki/Supersampling

https://github.com/Shopify/ghostferry/blob/main/tlaplus/ghos...

I also was able to find an concrrency bug before a single line of code was written with the TLC which saved a lot of time. It took about 4 weeks to design and verify the system in spec and about 2 weeks to write the initial code version, which mostly survived to this day and reasonably resembles the TLA+ spec. To my knowledge (I no longer work there) the correctness of the system was never violated and it never had any sort of data corruption. Would be a much harder feat without TLA+.

Comments URL: https://news.ycombinator.com/item?id=41740253

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=40374879

Points: 166

# Comments: 105

Comments URL: https://news.ycombinator.com/item?id=40339852

Points: 134

# Comments: 102

See https://m.youtube.com/watch?v=4DaaafyAUqA and https://m.youtube.com/watch?v=oLsPK2ATJcY. He is a pianist and he bought a novus5 to replace his own upright piano...

So I think protectioism is fine as long as we properly setup an environment that allows for and encourages competition and innovation. However, that doesn't seem to be a path we are used to taking .

Your call out to BYD is a good one, because it is conceivable that even western-made cars will be made non competitive in 10 years and it seems that we are sleeping through the news (or even encouraging it). I hope I'm wrong, but the road ahead is filled with challenge because the direction is fundamentally wrong, and it will take a lot of effort to reverse course, if that is even possible.

Now maybe these companies are likely just mismanaged and the cost of North American engineering is too high? That said, it still seems like there is a structural problem here that very few hybrid software-hardware companies succeed.

Comments URL: https://news.ycombinator.com/item?id=38963187

Points: 6

# Comments: 0