3 ms·

There is also "Rust is fine once you know how to not get burnt by the type system, and if you carefully choose your dependencies it will maybe still be able to

There is also "Rust is fine once you know how to not get burnt by the type system, and if you carefully choose your dependencies it will maybe still be able to start a build of your project a month from now, and if you're lucky it will build in less than a lifetime". Or "Java is fine if your fingers aren't sore yet and if you don't mind the latency spikes for your interactive application or if you're basically programming like C with training wheels and less performance". ;-)

earwaxauditor 6y ago
At least “this code doesn’t compile” isn’t a potential security vulnerability.
- jstimpfle 6y ago
  Sure, and projects that never ship aren't either.
  - earwaxauditor 6y ago
    I think you should lighten up ;)
- wffurr 6y ago
  That's exactly the point I was trying to make.
kaba0 6y ago
As for the latter: Or you know, most applications don’t need manual memory management because more often than not, programmers WILL get it wrong. Unless you really need that level of control over the hardware, you ARE better off with a good runtime env
- jstimpfle 6y ago
  That may be, but personally I am interested in those applications - GUI work, signal processing, low-latency networking.
  - elcritch 6y ago
    Nim, with the new ARC garbage collector works well for those situations now (well within a few percent usually). Especially with the `move` and `sink` semantics. I'm using it in embedded devices and needed a few tight loops a week or two back. With a bit of work and a few odd contortions, I got it to compile to almost the exact type of C code I'd write by hand to run a fast inner loop using preallocated arrays, etc. It turns out that code wasn't noticeably faster than more idiomatic Nim code with a few tweaks to ensure move's were able to be used. So I ended up going back to the more readable/idiomatic version while still roughly doubling the overall speed. The new `move` semantics with Nim's ARC system really do help make it easier to write fast code. Now I understand why the C++ ecosystem is so bullish on `move` in the C++ stdlib now. It really can take code which looks like straightforward C code but performs closer to painstakingly optimized C code. Mainly since it result in less copying of objects/structs and reducing the number of malloc's. Overall it means less effort to design a fast system.

earwaxauditor 6y ago

At least “this code doesn’t compile” isn’t a potential security vulnerability.

jstimpfle 6y ago
Sure, and projects that never ship aren't either.
- earwaxauditor 6y ago
  I think you should lighten up ;)
wffurr 6y ago
That's exactly the point I was trying to make.

kaba0 6y ago

As for the latter: Or you know, most applications don’t need manual memory management because more often than not, programmers WILL get it wrong. Unless you really need that level of control over the hardware, you ARE better off with a good runtime env

jstimpfle 6y ago
That may be, but personally I am interested in those applications - GUI work, signal processing, low-latency networking.
- elcritch 6y ago
  Nim, with the new ARC garbage collector works well for those situations now (well within a few percent usually). Especially with the `move` and `sink` semantics. I'm using it in embedded devices and needed a few tight loops a week or two back. With a bit of work and a few odd contortions, I got it to compile to almost the exact type of C code I'd write by hand to run a fast inner loop using preallocated arrays, etc. It turns out that code wasn't noticeably faster than more idiomatic Nim code with a few tweaks to ensure move's were able to be used. So I ended up going back to the more readable/idiomatic version while still roughly doubling the overall speed. The new `move` semantics with Nim's ARC system really do help make it easier to write fast code. Now I understand why the C++ ecosystem is so bullish on `move` in the C++ stdlib now. It really can take code which looks like straightforward C code but performs closer to painstakingly optimized C code. Mainly since it result in less copying of objects/structs and reducing the number of malloc's. Overall it means less effort to design a fast system.