4 ms·

> As the compiler will stop you from borrow checking or something unsafe again and again, you are being distracted constantly by focusing on the language itself

> As the compiler will stop you from borrow checking or something unsafe again and again, you are being distracted constantly by focusing on the language itself instead of the problem you are solving. While anyone is obviously free to use any language he or she likes the whole article comes across to me as someone arguing why they dont want / need seatbelts: "They constrain my movement, I'm a good driver, etc.". These are also the same kind of arguments one could make for wanting to use a weakly typed language instead of a strongly typed language. Personally I like my types strong and my memory safe...

htfy96 8y ago
There are always trade-offs. I mean when I'm writing really low-level stuffs (e.g., optimizing matrix multiplication kernels) I frequently find type system annoying. In that case I would definitely prefer C/asm, because they are simply closer to bare medals.
fulafel 8y ago
Strong typing and memory safety are compatible with his wants. It's just that Rust isn't it. Any of Clojure, F#/C#, Python, or Go might be good here. (Ok, the nil-punning might make the strong arguable on Clojure's point... but otoh you have spec)
- adamnemecek 8y ago
  Most of those langauges don’t have the perf of rust or cpp.
  - sanxiyn 8y ago
    Most programs don't need C++ performance. Java is usually within factor of two and usually fast enough.
    - adamnemecek 8y ago
      Need is relative. If you can get the extra speed, why waste it? Life’s too short to spend it waiting for your computer. And in this case, the author does need cpp speed.
      - sanxiyn 8y ago
        > Need is relative. If you can get the extra speed, why waste it? Because you can be a lot more productive if you are not extremely constrained by speed.
        adamnemecek 8y ago
        That’s a false dichotomy. A language can be both productive and fast.
        sanxiyn 8y ago
        In theory, yes. In practice, Rust at the moment is less productive than GC languages. I am hoping for autoclone mode in the future (sort of like Swift ARC).
      - fulafel 8y ago
        I think the article didn't say anything about performance requirements. The app is Dust3D, a ease-of-use focused mesh editor which deals with simple meshes. Certainly from the blog post you get the impression that programmer productivity is a consideration in his choice of language.
        gmueckl 8y ago
        3d modelling is a problem domain where performance is the most important feature. Without sufficient performance, the tool.is not interactive. And direct interaction with immediate visual feedback is the whole point of these programs.
        fulafel 8y ago
    - adev_ 8y ago
      > Most programs don't need C++ performance. Java is usually within factor of two and usually fast enough. Meshing software is a typical program where you need C++ and where Java is a terrible choice. By nature, meshing makes you play with millions to billions of very small object with mutual interactions. A thing that Java GC absolutely hate. Sorry for the Java fan-boys.
      - fulafel 8y ago
        The billion vertex objects might be a nice torture test benchmark for a gc or malloc implementation, but fortunately things aren't so grim in the real world: Performant mesh manipulation code as a rule deals with largish float arrays (or other similar contiguous layouts, like AoS or SoA or indexed versions thereof). So there are no per-vertex objects to malloc/free or to track in GC. In some algorithms, other data structures such as trees, may be used used as intermediate formats, but there too the options to use malloc/gc allocated nodes vs alternatives is similar in a GC'd vs a non-GC'd language. In general, good GC's often outperform malloc/free. Because GC's are amenable to parallelization in the background, and because malloc/free don't enjoy the bump-allocator style happy case that is used in generational GC's nursery objects.
        gmueckl 8y ago
        I never met a GC that can deal with millions of allocations per second while having several millions of objects in the young generations. Some mesh processing algorithms have a tendency to get you there very quickly if you do not employ custom allocators. At this point you already defeated the GC provided by the language.
        fulafel 8y ago
        You would have to be dealing with a very large number of meshes at once, if you were churning through millions of vertex and uv arrays per second. I can't say what you should use in this scneario. But this is a pretty niche scenario! And you would probably want to focus on parallelism, where C++ again is not the best.
    - otabdeveloper2 8y ago
      > Java is usually within factor of two No. That's on synthetic benchmarks. Run a real server and you see that Java shits its pants while a C++ service is running rings around it. That's because memory/cache fragmentation and usage is vastly more important in 2019 than CPU cycles.
- sanxiyn 8y ago
  I agree. GC is a life saver, and I think if something can be written with GC, it should be.

htfy96 8y ago

There are always trade-offs. I mean when I'm writing really low-level stuffs (e.g., optimizing matrix multiplication kernels) I frequently find type system annoying. In that case I would definitely prefer C/asm, because they are simply closer to bare medals.

fulafel 8y ago

Strong typing and memory safety are compatible with his wants. It's just that Rust isn't it. Any of Clojure, F#/C#, Python, or Go might be good here. (Ok, the nil-punning might make the strong arguable on Clojure's point... but otoh you have spec)

adamnemecek 8y ago
Most of those langauges don’t have the perf of rust or cpp.
- sanxiyn 8y ago
  Most programs don't need C++ performance. Java is usually within factor of two and usually fast enough.
  - adamnemecek 8y ago
    Need is relative. If you can get the extra speed, why waste it? Life’s too short to spend it waiting for your computer. And in this case, the author does need cpp speed.
    - sanxiyn 8y ago
      > Need is relative. If you can get the extra speed, why waste it? Because you can be a lot more productive if you are not extremely constrained by speed.
      - adamnemecek 8y ago
        That’s a false dichotomy. A language can be both productive and fast.
        sanxiyn 8y ago
        In theory, yes. In practice, Rust at the moment is less productive than GC languages. I am hoping for autoclone mode in the future (sort of like Swift ARC).
    - fulafel 8y ago
      I think the article didn't say anything about performance requirements. The app is Dust3D, a ease-of-use focused mesh editor which deals with simple meshes. Certainly from the blog post you get the impression that programmer productivity is a consideration in his choice of language.
      - gmueckl 8y ago
        3d modelling is a problem domain where performance is the most important feature. Without sufficient performance, the tool.is not interactive. And direct interaction with immediate visual feedback is the whole point of these programs.
        fulafel 8y ago
  - adev_ 8y ago
    > Most programs don't need C++ performance. Java is usually within factor of two and usually fast enough. Meshing software is a typical program where you need C++ and where Java is a terrible choice. By nature, meshing makes you play with millions to billions of very small object with mutual interactions. A thing that Java GC absolutely hate. Sorry for the Java fan-boys.
    - fulafel 8y ago
      The billion vertex objects might be a nice torture test benchmark for a gc or malloc implementation, but fortunately things aren't so grim in the real world: Performant mesh manipulation code as a rule deals with largish float arrays (or other similar contiguous layouts, like AoS or SoA or indexed versions thereof). So there are no per-vertex objects to malloc/free or to track in GC. In some algorithms, other data structures such as trees, may be used used as intermediate formats, but there too the options to use malloc/gc allocated nodes vs alternatives is similar in a GC'd vs a non-GC'd language. In general, good GC's often outperform malloc/free. Because GC's are amenable to parallelization in the background, and because malloc/free don't enjoy the bump-allocator style happy case that is used in generational GC's nursery objects.
      - gmueckl 8y ago
        I never met a GC that can deal with millions of allocations per second while having several millions of objects in the young generations. Some mesh processing algorithms have a tendency to get you there very quickly if you do not employ custom allocators. At this point you already defeated the GC provided by the language.
        fulafel 8y ago
        You would have to be dealing with a very large number of meshes at once, if you were churning through millions of vertex and uv arrays per second. I can't say what you should use in this scneario. But this is a pretty niche scenario! And you would probably want to focus on parallelism, where C++ again is not the best.
  - otabdeveloper2 8y ago
    > Java is usually within factor of two No. That's on synthetic benchmarks. Run a real server and you see that Java shits its pants while a C++ service is running rings around it. That's because memory/cache fragmentation and usage is vastly more important in 2019 than CPU cycles.
sanxiyn 8y ago
I agree. GC is a life saver, and I think if something can be written with GC, it should be.