6 ms·

>That's hilarious because most of the electronics That was an analogy. I wasn't talking about car electronics. I was talking about the lack of professional edu

by emsy 7y ago

>That's hilarious because most of the electronics That was an analogy. I wasn't talking about car electronics. I was talking about the lack of professional education in programming. >Most responsibilities are not concerned with low-level optimizations when javascript in particular typically deals with network connections I have yet to encounter a javascript program that doesn't run on a CPU. Also, javascript is one of the most versatile and widely used languages. It runs on clients, servers, high end machines and embedded systems. So of course performance matters. If it didn't we wouldn't need WASM, asm.js and countless ridiculous JS engine optimizations. The time "saved" having to learn proper programming by using JS is dwarfed by the time wasted in CPU and end user time.

vsareto 7y ago
>That was an analogy. I wasn't talking about car electronics. I was talking about the lack of professional education in programming. Yeah and I'm pointing out that for Javascript dev, there's a lot more knowledge with a higher priority to learn than low-level CPU code. That's why we shouldn't add it to job descriptions unncessarily. >If it didn't we wouldn't need WASM, asm.js and countless ridiculous JS engine optimizations. This is probably why Javascript from the OP was probably the worst language to choose to make an argument. If you want to know the platform, you'll have to learn these things as well. OTOH you can just write your super high performance thing in C or assembly and spend less time learning the extra layers between JS and the CPU. Then the low-level tuning becomes more important and obvious, and its merit is way more understandable. This kind of knowledge is totally okay for jobs in C or assembly. It's not a great idea as a requirement for javascript jobs.
- jolson88 7y ago
  I've been thinking about this topic a lot lately and I find myself in agreement with you vsareto. I'm largely a JS dev by day (working on backend services) but I'm very passionate about low-level programming. I tend to hack around in Rust or C, even starting to hack with assembly language. Heck, I'm even reading the AMD x86_64 architecture books for fun :P. There are so many challenges trying to understand what your Javascript is doing under the hood. Take Node.js development for example. Your code is running on V8, likely running within a Docker container, perhaps even on a Kubernetes node or other distributed cluster. To truly understand what your code is doing at the CPU level is a _very_ difficult thing to do. More often than not, the performance issues I've run into have to do with topics like: slow performing network communication, poorly thought out algorithm design (excessive code), "noisy neighbors" where other containers are causing performance problems unrelated to your own code (for example, one issue we had with excessive times for DNS resolution was caused by the networking stack/tech in our k8s cluster being misconfigured and doing a GC every 60 seconds for 4-5 seconds at a time), or poor database-access patterns that cause excessive times for queries. The JavaScript code itself and inefficiencies of what the resulting machine code is seems to rarely be the case for me. But that may also be due to the domain that I work in (it's actually one of the things that has me super bored with the software I work on these days). To echo your own points, I find myself most often coaching junior developers on data-access patterns and design, minimizing network activity (if you think missing the cache and going to memory is slow for software, just imagine hitting the network and going to different machines), etc. Like I said though, it may just be due to the domains I work in and being on the backend. And all of this from a person who is _loving_ learning more about the internals and playing around with lower-level programming. I feel like the more I have learned at that level has made me a much better programmer as well. I wish I would have learned this stuff 10-15 years ago. So I'm torn.

by emsy 7y ago

vsareto 7y ago

>That was an analogy. I wasn't talking about car electronics. I was talking about the lack of professional education in programming. Yeah and I'm pointing out that for Javascript dev, there's a lot more knowledge with a higher priority to learn than low-level CPU code. That's why we shouldn't add it to job descriptions unncessarily. >If it didn't we wouldn't need WASM, asm.js and countless ridiculous JS engine optimizations. This is probably why Javascript from the OP was probably the worst language to choose to make an argument. If you want to know the platform, you'll have to learn these things as well. OTOH you can just write your super high performance thing in C or assembly and spend less time learning the extra layers between JS and the CPU. Then the low-level tuning becomes more important and obvious, and its merit is way more understandable. This kind of knowledge is totally okay for jobs in C or assembly. It's not a great idea as a requirement for javascript jobs.

jolson88 7y ago
I've been thinking about this topic a lot lately and I find myself in agreement with you vsareto. I'm largely a JS dev by day (working on backend services) but I'm very passionate about low-level programming. I tend to hack around in Rust or C, even starting to hack with assembly language. Heck, I'm even reading the AMD x86_64 architecture books for fun :P. There are so many challenges trying to understand what your Javascript is doing under the hood. Take Node.js development for example. Your code is running on V8, likely running within a Docker container, perhaps even on a Kubernetes node or other distributed cluster. To truly understand what your code is doing at the CPU level is a _very_ difficult thing to do. More often than not, the performance issues I've run into have to do with topics like: slow performing network communication, poorly thought out algorithm design (excessive code), "noisy neighbors" where other containers are causing performance problems unrelated to your own code (for example, one issue we had with excessive times for DNS resolution was caused by the networking stack/tech in our k8s cluster being misconfigured and doing a GC every 60 seconds for 4-5 seconds at a time), or poor database-access patterns that cause excessive times for queries. The JavaScript code itself and inefficiencies of what the resulting machine code is seems to rarely be the case for me. But that may also be due to the domain that I work in (it's actually one of the things that has me super bored with the software I work on these days). To echo your own points, I find myself most often coaching junior developers on data-access patterns and design, minimizing network activity (if you think missing the cache and going to memory is slow for software, just imagine hitting the network and going to different machines), etc. Like I said though, it may just be due to the domains I work in and being on the backend. And all of this from a person who is _loving_ learning more about the internals and playing around with lower-level programming. I feel like the more I have learned at that level has made me a much better programmer as well. I wish I would have learned this stuff 10-15 years ago. So I'm torn.