fizzynut

The cynic in me thinks that their real plan is just to add monetisation and or implement/sell features that already exist in modified clients and that "security" is a convenient excuse.

I'm curious why a lot of people get a 3x improvement. I get about 6.5-7x speed up, which suspiciously lines up with a 60hz vs 144hz framerate...

Well, this paper found that a conservative underestimate of 15% of bugs would be saved through static typing:

https://www.microsoft.com/en-us/research/wp-content/uploads/...

I'm not sure what evidence your fact is based on, feel free to present some evidence for it.

I am curious for why people say this as in my experience when writing a function in a dynamic language that takes a variable as a parameter:

The function will generally only work on a subset of types for given variable.

If I don't check the type of the variable in the function, the function will not behave as you might expect, e.g. silently fail or crash.

If I do check for every possible type for a given variable:

I may not have a good way of handling certain types being passed in, I may be forced to either log something out, create a run time crash or even have the function silently fail. All 3 are bad run time behaviours.

If I am checking for every type in the functions, then using static typing would cause the failure at compile time so the bugs could never exist, but also being significantly less verbose than the dynamic language equivalent.

It's like selling cigarettes to children using manipulative marketing specifically aimed at children like cute characters on the box and blaming the parents.

Lots of people writing their own data structures and libraries should be a reflection of the different needs and diversity of the ecosystem, but if it's a reflection of difficulty then it tends to lead to a much narrower ecosystem.

That isn't to say a narrow ecosystem is necessarily bad, it can often be good if a particular language is used for a specific domain as all the libraries and data structures will likely be a better fit for your problems. Going outside of those constraints can often be very punishing in those languages though.

Writing your own data structures allows you to write it to suit the specific needs/constraints of your problem/domain. Typically that means you get something that is significantly simpler, faster and with a different feature set.

Libraries are typically optimized for generic use, so are often more complex, slow, and difficult to extend with new features (both coding wise or the features might not be suitable / have trade offs for other people).

On the other hand, how do developers sleep at night after updating their dependencies as it will now be littered with new unknown vulnerabilities.

The biggest correlated constant for bugs is that more lines of code = more bugs. As dependencies get updated they add more new features that I probably don't care about which adds more lines of code and therefore more bugs and security vulnerabilities.

I appreciate there is a balance between the two, but in my experience updating dependencies has broken things a lot more often than not updating things has broken things, and when that happens I find it a bit of a ridiculous idea that the maintainer has somehow made their product "more secure"(something that is usually a low dev priority) while at the same time introducing new bugs with the new features (something which is a higher dev priority) and they didn't even get that right.

Something that works now and will continue to work for years without changing any code.

To turn this on its head, if I'm creating a new product now, why invest time into an API where by the time the product would be ready with WebGL, instead I chose WebGPU, so now have the risks:

  -  The API is still years away from mainstream.
  -  Doesn't solve anything for my use case that wouldn't be solved with WebGL.
  -  Is too buggy to use on most configurations.
  -  Isn't supported by X hardware or Y OS.
  -  Has security issues that make browsers disable it for years.
  -  The code has to be regularly updated/maintained/fixed when browsers update.
  -  Performance could be lower for low end systems.
  -  Even if everything worked, it's a lot more work to do everything (e.g. VULKAN).
  -  To beat webGL, you have to optimise specifically for mobile/desktop/amd/nvidia/etc
  -  The documentation is poor.
  -  It's impossible to hire an expert in webGPU.
  -  It's very expensive to test every combination of GPU/OS/driver so you have no confidence it is working correctly. 

Most rendering code should abstract to many APIs anyway, so not starting with a webgl version would be quite insane.

Maybe this article is way over my head, but is it not really simple?

If my function to generate a circle is a simple for loop 0 to 2 PI.

Then the inverse of that maps each point on the circle back to a line with points between 0 and 2 PI.

In my experience Windows is the generally the best supported for general embedded work, video, graphics, audio, hobbyist, IDEs, etc. Linux has the best for server and server related hardware but is often pretty equal..ish?

MacOS...has a monopoly on developing for Apple products, but I can't imagine the embedded toolchain is particularly good?

I do enjoy the image in my head of some hipster guy in a coffee shop with a macbook, scope, power supply and a bunch of wires sticking out a pcb trying to debug something though.

Cheap tricks can create a much more responsive experience.

Whenever a user interactable element will be ready in <~100ms, you can display it as ready now, because it is faster than the reaction speed of a human, which makes all interactions with the software faster, smoother and more responsive than if I used a loading indicator. It's a free win.

Whenever you know in advance you need to display something to the user and need to load/process something that takes much longer than 100ms, you can load in the background while displaying whatever needs to be displayed and if the time spent on the screen is slower than the loading time then the next interaction will be instant (common case), if the user is faster on the screen you can still go to a loading screen, but the time it is on screen for would still be much much shorter.