3 ms·

This is all good and everything but: Who uses Nimrod? Who are the people behind Nimrod? Will they still be/stand behind Nimrod in 5-10 years from now? I didn't

This is all good and everything but: Who uses Nimrod? Who are the people behind Nimrod? Will they still be/stand behind Nimrod in 5-10 years from now? I didn't know Nimrod has a Javascript backend. This makes it even more interesting. The multitude of backends and the presumably small size of the core developer group makes me wonder though how well they are tested.

girvo 13y ago
Nimrod's already been around and quite heavily worked on since 2006, if I recall correctly. I chatted to a guy who is using it in production at his work, too, and there are some neat repositories and quite well done applications on GitHub. It's surprisingly far along, and I was amazed at how it skipped my radar up until this year.
a8da6b0c91d 13y ago
The problem with D/Nimrod/Go/Rust is the kind of people who would use them have already invested heavily in coping with the pain of C++ and have solid tools. As languages the alternatives are only maybe 2X better than C++, which is almost entirely countered by the fact that you will hit compiler and library bugs that you wouldn't when using mature C++ components and tools. As soon as you waste a day writing your own library wrapper that you would have taken off the shelf in C++, the relative elegance of Nimrod becomes moot. It seems like the alternative languages need years more to build steam.
- dragonwriter 13y ago
  > The problem with D/Nimrod/Go/Rust is the kind of people who would use them have already invested heavily in coping with the pain of C++ and have solid tools. I don't know about D or Nimrod, but I always got the impression that Go and Rust had quite a bit of appeal to the kind of people that aren't heavily invested in C++, but instead are more currently focussed in dynamic languages like Python or Ruby, but forced to spend time writing modules/extensions in other languages (likely C) for performance.
  - kibwen 13y ago
    This is me. By day I write Javascript, Python, and PHP; by night, Rust is my vessel for teaching myself systems-level programming. It's something I've always wanted to learn, but I just don't have the time nor the energy to memorize the seemingly-inexhaustible trivia of C++.
- danieldk 13y ago
  The problem with D/Nimrod/Go/Rust is the kind of people who would use them have already invested heavily in coping with the pain of C++ As someone who has written C++ for eight years now, I don't agree that life works like that. Two jobs back, I worked on a system in Prolog plus C/C++. There, I couldn't have switched to Go or D if I wanted to, binding Prolog with those language runtimes would be a big hassle (for everyone). However, in my current job, I couldn't write C++ if I wanted to. All the work is done on the top of the JVM, so a JVM language is what one has to live with :). In other words: the set of languages that can be used depend highly on the employer and the project. The larger barrier against the success of these new languages is inertia of your co-workers, employer, etc. And that's for a good reason you touch upon: C++, Java, the JVM, .NET, etc. are all reliable languages tools used by a large community.
- pcwalton 13y ago
  No tool in existence can make C++ memory-safe. If there were such a tool, then we wouldn't have had any reason to create Rust. But C++ is so fundamentally unsafe that making it safe requires a new language, as far as anyone can tell. You do give up maturity and the ecosystem when using an alternative language, but there are some features that are critical for certain application domains that C++ can never have without massive incompatible changes.
  - angersock 13y ago
    but but but boost c++11 lambdas c++14 do you even program in cpp

girvo 13y ago

Nimrod's already been around and quite heavily worked on since 2006, if I recall correctly. I chatted to a guy who is using it in production at his work, too, and there are some neat repositories and quite well done applications on GitHub. It's surprisingly far along, and I was amazed at how it skipped my radar up until this year.

a8da6b0c91d 13y ago

The problem with D/Nimrod/Go/Rust is the kind of people who would use them have already invested heavily in coping with the pain of C++ and have solid tools. As languages the alternatives are only maybe 2X better than C++, which is almost entirely countered by the fact that you will hit compiler and library bugs that you wouldn't when using mature C++ components and tools. As soon as you waste a day writing your own library wrapper that you would have taken off the shelf in C++, the relative elegance of Nimrod becomes moot. It seems like the alternative languages need years more to build steam.

dragonwriter 13y ago
> The problem with D/Nimrod/Go/Rust is the kind of people who would use them have already invested heavily in coping with the pain of C++ and have solid tools. I don't know about D or Nimrod, but I always got the impression that Go and Rust had quite a bit of appeal to the kind of people that aren't heavily invested in C++, but instead are more currently focussed in dynamic languages like Python or Ruby, but forced to spend time writing modules/extensions in other languages (likely C) for performance.
- kibwen 13y ago
  This is me. By day I write Javascript, Python, and PHP; by night, Rust is my vessel for teaching myself systems-level programming. It's something I've always wanted to learn, but I just don't have the time nor the energy to memorize the seemingly-inexhaustible trivia of C++.
danieldk 13y ago
The problem with D/Nimrod/Go/Rust is the kind of people who would use them have already invested heavily in coping with the pain of C++ As someone who has written C++ for eight years now, I don't agree that life works like that. Two jobs back, I worked on a system in Prolog plus C/C++. There, I couldn't have switched to Go or D if I wanted to, binding Prolog with those language runtimes would be a big hassle (for everyone). However, in my current job, I couldn't write C++ if I wanted to. All the work is done on the top of the JVM, so a JVM language is what one has to live with :). In other words: the set of languages that can be used depend highly on the employer and the project. The larger barrier against the success of these new languages is inertia of your co-workers, employer, etc. And that's for a good reason you touch upon: C++, Java, the JVM, .NET, etc. are all reliable languages tools used by a large community.
pcwalton 13y ago
No tool in existence can make C++ memory-safe. If there were such a tool, then we wouldn't have had any reason to create Rust. But C++ is so fundamentally unsafe that making it safe requires a new language, as far as anyone can tell. You do give up maturity and the ecosystem when using an alternative language, but there are some features that are critical for certain application domains that C++ can never have without massive incompatible changes.
- angersock 13y ago
  but but but boost c++11 lambdas c++14 do you even program in cpp