Hacker News Reader

Comment by magnio | Hacker News Reader

I cannot think of any mainstream language that is AOT-compiled and create standalone executable for the three major platforms other than Rust and Go* (Zig is not stable yet), which are precisely the two languages that are used for most newer JS toolings. For Python you only have Rust, as you need C FFI. Maybe one day we will see more software in Nim, Crystal, and Janet, but they are far, far from mainstream.

What specific languages do you have in mind?

*and C and C++ but writing tools in them is like self-lobotomy.

View on HN

C# is getting there.

EDIT: And Dart (which is not that mainstream).

Go is in no way comparable to the other two. It may seem deceptively simple but it lacks crucial low level primitives and features C# has.

>"...and C and C++ but writing tools in them is like self-lobotomy."

C is a lower level language than Rust so sure it is harder to write complex tools. Modern C++ - writing tools is at worst as easy than Rust and way better in practice because of a huge amount of libraries to suit every taste and C++ being more expressive / supporting more programming paradigms.

Statement like yours are not doing any service to Rust. Rust advocacy can do very much without such "help". Hopefully it does not represent culture of Rust community in general.

I am not advocating for Rust and don't care at all if these tools are written in Assembly or C++; as long as they exist and work well, I am happy.

When I wrote that statement, I didn't really mean C++ the language, but C++ the developer experience. I have tried to write a few command-line utilities in C++, and while the language proper is quite capable, dealing with CMake, package management, header files, and testing is just more headache-inducing than in Rust for me. Most of it probably stems from my lack of experience with C++, but it doesn't change the fact that despite C++ being 20 years older than Rust and having an order of magnitude more users, most of new JS toolings are not written in it.

Feel free to prove me wrong by pointing me to good tooling projects in C++. I actually want to learn more C++ best practices for working with another language.

I mainly use CLion by JetBrains for development. It does use CMake.

I can't point you for particular tooling C++ project. The only 3rd party source code I use are some C++ libraries. All it takes in my particular case is adding couple of lines in CMakeLists.txt file and I am very far from being CMake expert.

CMake is actually a perfect demonstration of how annoying C++ development tooling can be.

The documentation is massively verbose but doesn’t really say anything helpful. There’s basically no “Modern CMake” examples that anyone can agree upon. (I do see that there’s some GitHub repos these days that maybe do show some of it). There’s very little information on “The CMake way of doing things”. You really need to learn by examination, and your assumptions in the end will very likely be wrong.

Even just adding a package fetch in CMake is infuriating. What is the currently accepted way to do this? (I admit that I haven’t used CMake in a while, but as of a year ago, the internet and CMake docs did not agree on the correct way, even internally)

We must be living in a different world. It literally takes me seconds to create new executable project.

>"Even just adding a package fetch in CMake is infuriating."

I am not sure how to do it because I do not let build process / environment fetch things from the Internet. I always download / deploy / update manually upon real need. I would agree that having IDE do it for you is convenient but since I only use very few libs there is no need for me to do it at all.

If I need to create new project I just copy a template, fire up CLion IDE and it all takes few seconds from the - I am going to do it, to start actual coding.

Using external libraries is important because it lets you focus on what's important for your project. C++'s lack of a proper package manager means we're all reinventing the wheel because adding dependencies is non-trivial.

Cargo/Rust and Go show how compiled languages can have drastically superior development experiences. CMake is primitive in comparison. Its only upside is its flexibility, which I reckon isn't worth it for most cases.

A while back I needed to write a small library in C++.

It took me about the same amount of time to write few dozen lines of CMake (to get build working with all the external libraries), as it took me to write few thousands lines of C++.

I wasted way too much time dealing with CMake.

>"few dozen lines of CMake (to get build working with all the external libraries), as it took me to write few thousands lines of C++."

I claim BS unless those "thousands lines" were cut'n paste.

No, but it was a rewrite of C# code. Using MSVC compiler, targeting Windows and Linux. C++20 with modules. External libraries: libsodium, lmdb, roaring & rocksdb. First time using CMake.

>"Using external libraries is important because it lets you focus on what's important for your project"

Well thank you. I just trying to guess where did you get the idea that I am not using 3rd party libs.

>"C++'s lack of a proper package manager means we're all reinventing the wheel because adding dependencies is non-trivial."

I think it is trivial. Here is particular example for cpp-http library that I use in some of my projects:

  a) download from github
  b) add add_subdirectory("./3rd-party/cpp-httplib") into CMakeLists.txt file

That is it. Ready for use.

That’s fine, but most modern tooling “automates” this for you and gives you easy tooling to manage versions as well.

Additionally, you get a nice list in a simple spot of exactly what you need that isn’t just documentation. Anyone can easily pull your project and contribute.

Being able to easily manage deps has issues (such as a tendency to trend toward left-pad), but there’s also significant benefits as well that become readily apparent when you compare cargo with CMake (I understand they’re not completely comparable)

The Professional Cmake book is an indispensable, fantastic resource I've used on a couple of work projects, I highly recommend it to anyone working with Cmake.

That being said, Cmake is a far cry from the ease of use of cargo (albeit with potentially much more flexibility).

https://crascit.com/professional-cmake/

> Statement like yours are not doing any service to Rust. Rust advocacy can do very much without such "help". Hopefully it does not represent culture of Rust community in general.

Ugh. You’re disagreeing about which languages are best for some task. Are either one of you being-an-advocate? That’s up to interpretation.

It’s not fair to say that someone who vouches for Rust is being-an-advocate while someone who vouches for C++ is just arguing normally. What basis is there for that?

I could say that you are not doing any service to Rust-naysayers. That I hope that the culture of Rust-naysayers are not represented by people like you. Would that be fair?

The Rust ecosystem is much more coherent than the C++ ecosystem, broadly speaking. Starting from cargo, which isn't perfect but is a fantastic tool.

As the main author of cargo-nextest, I'd challenge you to write a tool with a similar complexity and quality level in C++. I got so much leverage from being able to use the Rust ecosystem, including being able to port to new platforms with literally zero code changes. (Be sure to get the signal handling exactly right.)

Reply on news.ycombinator.com