5 ms·

> has to prove itself not just superior to C++, but superior to Rust ... and Zig and Nim and D, I guess? None of them are seeing enough usage to even score the

by pron 7y ago

> has to prove itself not just superior to C++, but superior to Rust ... and Zig and Nim and D, I guess? None of them are seeing enough usage to even score them meaningfully against C++. The incumbents are C/C++, and there's no one else within two orders of magnitude. Just experiments at various stages; some are still in the lab, others have started some field trials, but that's about it.

whb07 7y ago
As I'm writing this, I spent X hours trying to find where my C project was leaking memory. Turns out one of the openssl pointers needed to be freed explicitly, which was my fault from having just seen their docs and them not explicitly showing so. Point is, with Rust this wouldn't be a thing. I wouldn't have to compile my program with a number of clang flags and then run the sanitizers and try to fish out where this could possibly be happening. That is just 1 clear obvious productivity win for Rust. Have you written any recent C/C++ and have used/played with Rust?
- pron 7y ago
  Yes, and Rust doesn't protect you from memory leaks, BTW, although it does make them less likely. The overall value of a language can only be evaluated after years and many projects. My personal favorite to replace C/C++ is, by far, Zig, but I can't claim that it's the one to beat because it's years away from proving its worth, as are Nim, Rust, and, well, Bosque, I guess. Fashion forums like HN can pass judgment quickly -- that's what fashion forums are for, and why they're good entertainment but not to be taken too seriously -- but the real world of the software industry takes much, much longer, and has a far higher bar for evidence.
  - whb07 7y ago
    Let me clarify, in this actual case it would have. In Rust, memory that gets allotted in a function are freed when they go out of scope. So function returns -> stuff gets freed unless explicitly telling compiler not to. I haven't seen Zig and I'll check it out. But some of the "fanfare" is necessary to get people involved and things built. Many other langs and projects that are technically worthwhile never get any of it and just languish.
    - pron 7y ago
      I don't have a problem with the fanfare, but let's not drink our own kool-aid, yeah? If there's a new language that wants to try its luck, it still only needs to beat the incumbent, not the rest of the wannabes (one or some of which may well one day be the incumbent, but none are anywhere near that yet).
  - pjmlp 7y ago
    Indeed, at the end of the day there are certain domains where they are unavoidable, and regardless of countless rants from our side, those are the tools that get picked when one of said domains needs to be addressed. Given your line of work, why not Java itself, on an hypothetical future where Valhalla is done, and AOT is a standard feature in equal footing with JIT capabilities/performance?
    - pron 7y ago
      Maybe, but I'm allowed to like more than one language, no? :) But seriously, I don't think AOT can ever match a JIT on peak performance without reducing the abstraction level and significantly increasing programmer burden, and much of Java's design is around "we automatically turn RAM into speed." It's a great value proposition for huge swathes of the software industry, but I don't think it's necessarily the best strategy for niches that require performance and are RAM-constrained. I like Java and I like low-level programming even though it requires more effort regardless of language.
      - pjmlp 7y ago
        Sure, just curious. :) Currently I am on a mix of .NET (C# F#) alongside C++. I agree with the performance part, that is why the best is to be able to have both around, AOT + JIT.
- alexhutcheson 7y ago
  If the library were written in modern C++, then it also wouldn't be a problem. It would have given you a std::unique_ptr, ownership would have been clear, and deletion would have been handled automatically.
benibela 7y ago
... and Pascal ! Many languages are superior to C/C++ C/C++ just wins from the amount of available libraries and high-quality implementations.
- gnulinux 7y ago
  I don't understand what people are trying to categorize when they say C/C++. They're incredibly different languages. It's hard to find similarities between C and modern C++ (C++2x flavor). If we put C and C++ under the same umbrella, why not put Java there too? I just think when you say C/C++ you need to clarify what exactly do you mean by that.
  - pjmlp 7y ago
    C/C++ => C and C++, simple plain English grammar simplification. Used all over the place in ISO C++ papers, official documentation from all compiler vendors, long gone famous magazines like 'The C/C++ Users Journal', reference books well respected in the C++ community,.... Yet a couple of people still insist into making a point out of it, but don't start one when Java/C, Java/C++, C#/C++, Python/C,..., gets written somewhere.
- AnimalMuppet 7y ago
  Maybe I'm too much of a pragmatist, but to me, the amount of available libraries and the quality of the implementations is part of what "superior" means. You may think that Pascal is superior on paper (that is, just the language specification). If we were programming on paper, that might matter. But we aren't.
  - megameter 6y ago
    It's very task-dependent. If your needs are towards "indie software" that needs a snappy native UI and can make use of subprocesses to cover major dependencies, the Pascal options are really good and time-tested. It's probably underused for games in particular, in fact. Fast iteration times for game projects are a great selling point for contemporary use of Pascal, if you can justify the investment in engine code. If you are writing server backends, there is nothing interesting going on in Pascal and you will be scraping around to find the bindings to do what you need. Likewise with a number of other common industry tasks.
littlestymaar 7y ago
You can't really compare Rust to Zig & Nim anymore. 2016 is over, Rust is deployed in the wild on millions of computers (Dropbox, VSCode, and obviously Firefox), there are dozens of Rust packages in Debian apt repositories and it's being used by many companies (Microsoft, Amazon, Facebook, Google, etc. even Nike!). Of course it's incomparable to C and C++, and it will never replace them, but comparing it to Nim and Zig makes no sense either.
- pron 6y ago
  The difference between 0.000001% and 0.001% is much less important than between 0.001% and 20%. Rust has less penetration than Haskell and Erlang, and regardless of what you think of their merits, influential as they may be, none of them are factors in the software ecosystem. Languages with 10x more use and 10x more exposure than Rust disappeared with little impact over a very short period of time. Of course, Rust could become a serious force one day, as could Zig or Nim.
  - littlestymaar 6y ago
    > The difference between 0.000001% and 0.001% is much less important than between 0.001% and 20%. Even if your math is pretty much arbitrary, there is the big difference between having libraries and not having them, and having jobs or not having them. > none of them are factors in the software ecosystem It will probably disappoint you, but C and C++ aren't really “relevant factors in the software ecosystem” anymore, and they haven't been for the past two decades. It's been PHP, Java, JavaScript, and some C#, all over for the past 20 years. And Rust won't change anything in that hierarchy even in the best case scenario, neither will Zig or Nim. And that's completely fine. Yet, Rust has reached a significant existence, which means you can build stuff without having to build all the necessary libs by yourself, you can hire people knowing it, or even people who don't know it yet but will become proficient reasonably quickly because there are tons of learning material. You can find a job at some company already using it or use it for an internal project at your current company because you can show your manager that this isn't too much of a risk. All that even if you don't live in the bay area but in Europe. None of it was possible in 2016 for Rust, and none of it is in 2020 for Nim (and Zig isn't even stable, so it's more comparable to what Rust was in 2013 or something). If everything goes well for them, it could become the case by 2025, but not today. (First, they really need to bring more core contributors to the language, as they are still mainly developed by a single lead: at this point Andrew Kelley still has authored 50% o fall Zig commits, while Andreas Rumpf is responsible for one third of Nim's. The bus/burnout factor of both languages are still pretty much 1).

by pron 7y ago

whb07 7y ago

As I'm writing this, I spent X hours trying to find where my C project was leaking memory. Turns out one of the openssl pointers needed to be freed explicitly, which was my fault from having just seen their docs and them not explicitly showing so. Point is, with Rust this wouldn't be a thing. I wouldn't have to compile my program with a number of clang flags and then run the sanitizers and try to fish out where this could possibly be happening. That is just 1 clear obvious productivity win for Rust. Have you written any recent C/C++ and have used/played with Rust?

pron 7y ago
Yes, and Rust doesn't protect you from memory leaks, BTW, although it does make them less likely. The overall value of a language can only be evaluated after years and many projects. My personal favorite to replace C/C++ is, by far, Zig, but I can't claim that it's the one to beat because it's years away from proving its worth, as are Nim, Rust, and, well, Bosque, I guess. Fashion forums like HN can pass judgment quickly -- that's what fashion forums are for, and why they're good entertainment but not to be taken too seriously -- but the real world of the software industry takes much, much longer, and has a far higher bar for evidence.
- whb07 7y ago
  Let me clarify, in this actual case it would have. In Rust, memory that gets allotted in a function are freed when they go out of scope. So function returns -> stuff gets freed unless explicitly telling compiler not to. I haven't seen Zig and I'll check it out. But some of the "fanfare" is necessary to get people involved and things built. Many other langs and projects that are technically worthwhile never get any of it and just languish.
  - pron 7y ago
    I don't have a problem with the fanfare, but let's not drink our own kool-aid, yeah? If there's a new language that wants to try its luck, it still only needs to beat the incumbent, not the rest of the wannabes (one or some of which may well one day be the incumbent, but none are anywhere near that yet).
- pjmlp 7y ago
  Indeed, at the end of the day there are certain domains where they are unavoidable, and regardless of countless rants from our side, those are the tools that get picked when one of said domains needs to be addressed. Given your line of work, why not Java itself, on an hypothetical future where Valhalla is done, and AOT is a standard feature in equal footing with JIT capabilities/performance?
  - pron 7y ago
    Maybe, but I'm allowed to like more than one language, no? :) But seriously, I don't think AOT can ever match a JIT on peak performance without reducing the abstraction level and significantly increasing programmer burden, and much of Java's design is around "we automatically turn RAM into speed." It's a great value proposition for huge swathes of the software industry, but I don't think it's necessarily the best strategy for niches that require performance and are RAM-constrained. I like Java and I like low-level programming even though it requires more effort regardless of language.
    - pjmlp 7y ago
      Sure, just curious. :) Currently I am on a mix of .NET (C# F#) alongside C++. I agree with the performance part, that is why the best is to be able to have both around, AOT + JIT.
alexhutcheson 7y ago
If the library were written in modern C++, then it also wouldn't be a problem. It would have given you a std::unique_ptr, ownership would have been clear, and deletion would have been handled automatically.

benibela 7y ago

... and Pascal ! Many languages are superior to C/C++ C/C++ just wins from the amount of available libraries and high-quality implementations.

gnulinux 7y ago
I don't understand what people are trying to categorize when they say C/C++. They're incredibly different languages. It's hard to find similarities between C and modern C++ (C++2x flavor). If we put C and C++ under the same umbrella, why not put Java there too? I just think when you say C/C++ you need to clarify what exactly do you mean by that.
- pjmlp 7y ago
  C/C++ => C and C++, simple plain English grammar simplification. Used all over the place in ISO C++ papers, official documentation from all compiler vendors, long gone famous magazines like 'The C/C++ Users Journal', reference books well respected in the C++ community,.... Yet a couple of people still insist into making a point out of it, but don't start one when Java/C, Java/C++, C#/C++, Python/C,..., gets written somewhere.
AnimalMuppet 7y ago
Maybe I'm too much of a pragmatist, but to me, the amount of available libraries and the quality of the implementations is part of what "superior" means. You may think that Pascal is superior on paper (that is, just the language specification). If we were programming on paper, that might matter. But we aren't.
- megameter 6y ago
  It's very task-dependent. If your needs are towards "indie software" that needs a snappy native UI and can make use of subprocesses to cover major dependencies, the Pascal options are really good and time-tested. It's probably underused for games in particular, in fact. Fast iteration times for game projects are a great selling point for contemporary use of Pascal, if you can justify the investment in engine code. If you are writing server backends, there is nothing interesting going on in Pascal and you will be scraping around to find the bindings to do what you need. Likewise with a number of other common industry tasks.

littlestymaar 7y ago

You can't really compare Rust to Zig & Nim anymore. 2016 is over, Rust is deployed in the wild on millions of computers (Dropbox, VSCode, and obviously Firefox), there are dozens of Rust packages in Debian apt repositories and it's being used by many companies (Microsoft, Amazon, Facebook, Google, etc. even Nike!). Of course it's incomparable to C and C++, and it will never replace them, but comparing it to Nim and Zig makes no sense either.

pron 6y ago
The difference between 0.000001% and 0.001% is much less important than between 0.001% and 20%. Rust has less penetration than Haskell and Erlang, and regardless of what you think of their merits, influential as they may be, none of them are factors in the software ecosystem. Languages with 10x more use and 10x more exposure than Rust disappeared with little impact over a very short period of time. Of course, Rust could become a serious force one day, as could Zig or Nim.
- littlestymaar 6y ago
  > The difference between 0.000001% and 0.001% is much less important than between 0.001% and 20%. Even if your math is pretty much arbitrary, there is the big difference between having libraries and not having them, and having jobs or not having them. > none of them are factors in the software ecosystem It will probably disappoint you, but C and C++ aren't really “relevant factors in the software ecosystem” anymore, and they haven't been for the past two decades. It's been PHP, Java, JavaScript, and some C#, all over for the past 20 years. And Rust won't change anything in that hierarchy even in the best case scenario, neither will Zig or Nim. And that's completely fine. Yet, Rust has reached a significant existence, which means you can build stuff without having to build all the necessary libs by yourself, you can hire people knowing it, or even people who don't know it yet but will become proficient reasonably quickly because there are tons of learning material. You can find a job at some company already using it or use it for an internal project at your current company because you can show your manager that this isn't too much of a risk. All that even if you don't live in the bay area but in Europe. None of it was possible in 2016 for Rust, and none of it is in 2020 for Nim (and Zig isn't even stable, so it's more comparable to what Rust was in 2013 or something). If everything goes well for them, it could become the case by 2025, but not today. (First, they really need to bring more core contributors to the language, as they are still mainly developed by a single lead: at this point Andrew Kelley still has authored 50% o fall Zig commits, while Andreas Rumpf is responsible for one third of Nim's. The bus/burnout factor of both languages are still pretty much 1).