if its not possible to rewrite it in typescript in a way that is as fast as the go version, that really sheds a bad light on v8 and its performance and begs the question why you should write any non browser code in typescript.
As discussed at https://youtu.be/10qowKUW82U?t=2772 one of the main limitations of v8/javascript is that you cannot share object across threads. You also don’t have any control over the memory layout of objects.
If you are in a compute-heavy domain those are going to be a real bummer, but if you are in an io-heavy domain that doesn’t see as much benefit from sharing then you’ll be plenty fast.
This story is similar to python, and also why lots of nodejs and python projects see great utility in linking out to compiled languages for various tasks.
if its not possible to rewrite it in go in a way that is as fast as the assembly version, that really sheds a bad light on go and its performance and begs the question why you should write any code in go.
I’m pretty sure it’s not possible to rewrite it in assembly in a way that makes it 2 times faster than the go version. also go code is as easy to write as typescript code.
software development is about finding a sweet spot and between different languages that are about as easy to write 10 times performance difference is pretty meaningful imo
Flaky tests are just bad tests and more often than not they test nothing or at least not what they seem to test. Just set them to pending and create a ticket. Also flaky Test can be an indication of bad architecture
if its not possible to rewrite it in typescript in a way that is as fast as the go version, that really sheds a bad light on v8 and its performance and begs the question why you should write any non browser code in typescript.
lacking nuance imo
As discussed at https://youtu.be/10qowKUW82U?t=2772 one of the main limitations of v8/javascript is that you cannot share object across threads. You also don’t have any control over the memory layout of objects.
If you are in a compute-heavy domain those are going to be a real bummer, but if you are in an io-heavy domain that doesn’t see as much benefit from sharing then you’ll be plenty fast.
This story is similar to python, and also why lots of nodejs and python projects see great utility in linking out to compiled languages for various tasks.
if its not possible to rewrite it in go in a way that is as fast as the assembly version, that really sheds a bad light on go and its performance and begs the question why you should write any code in go.
I’m pretty sure it’s not possible to rewrite it in assembly in a way that makes it 2 times faster than the go version. also go code is as easy to write as typescript code.
software development is about finding a sweet spot and between different languages that are about as easy to write 10 times performance difference is pretty meaningful imo
What I would do is write a test for the happy path first
Flaky tests are just bad tests and more often than not they test nothing or at least not what they seem to test. Just set them to pending and create a ticket. Also flaky Test can be an indication of bad architecture