Based on my surface-level understanding of Nim, Go is much more comparable to Nim than it is Rust. I never understood the Rust-Go comparisons, since Rust is a serious systems programming language. I would never use Go or Nim to replace C or C++ usage as I would Rust, but I might use Nim in place of Go or Java.
Does anyone with significant Nim experience care to lend some opinions? I don't want to start a flame war--I'm genuinely curious.
Historical accident: they started surfacing around the same time, Go was originally described as a systems language (which it never was according to the usual meaning of the term) and Rust had more application-level features (built-in "GC pointer", green threads). As incorrect as it was, the initial… impression? — it's probably the wrong term but I don't have a better one — remained.
Probably doesn't help that Rust also has a number of features Go is criticised for lacking (generics, non-nullable references, immutability support, …)
> Go was originally described as a systems language (which it never was according to the usual meaning of the term)
Fun fact! Go has roots in the Limbo[0] programming language, which runs in a VM, is garbage collected, has communication channels, and was used to write the Inferno[1] operating system, which is sort of a successor to Plan 9 (which is itself sort of a successor to Unix).
Nim compiles to very efficient C or C++ (or js) and most benchmarks shows Nim programs performance being almost the exact same as C/C++ - and often better than Rust.
So... why not using it to replace C and C++? Since I have worked with Nim (and I use it to implement my own language) I would say "hell yes"! It is such an immensely better language and it integrates perfectly with those eco systems. The GC is a good one (or well, there are 5 to choose from) and it is for many, many applications not an issue.
And before pcwalton drops in with his endless spamming about Nim not being safe, Nim being undefined etc etc (it's getting quite annoying), please spare us this time.
> And before pcwalton drops in with his endless spamming
about Nim not being safe, Nim being undefined
Well, it is, isn't it? Is he wrong about Nim not being safe when not using Boehm GC? Does it not segfault when sending GC pointers between threads?
He only jumps in, when someone claims Nim is safe or the sweet spot, or something equally wrong. Nim's pretty syntax comes with a price, just like Rust's safety comes with a different kind of price.
> Is he wrong about Nim not being safe when not using Boehm GC? Does it not segfault when sending GC pointers between threads?
If he has said that, yes, then that would be wrong [1, 2] in that you cannot send GCed references between threads in the first place. For example, the following code results in an error:
var s = "foo"
proc foo {.thread.} =
echo s
createThread(foo)
Compiling this results in:
test.nim(3, 6) Error: 'foo' is not GC-safe as it accesses 's' which is a global using GC'ed memory
The problem here is one of expressiveness in that it is difficult for threads to share data (outside the limited and still experimental `parallel` construct). I've proposed a mechanism (shared, individually lockable heaps) modeled after Eiffel's SCOOP approach to remedy this, but so far this is just a proposal.
[1] Modulo any remaining compiler bugs, of course, or using explicitly unsafe features.
[2] Also, are you maybe confusing this with Go, which does have such a problem?
Does Nim deep copy messages between threads now (i.e. serializes entire object graphs)? If so I'm glad to see it and yes, it would of course be safe, as it would basically be Erlang. (It wasn't thread-safe when I last looked a year-plus ago.)
It has always done that [1]. You can only send refs through channels or via the spawn primitive where they are serialized/deep copied (or as arguments to threads upon creation, where that happens implicitly).
[1] It may have been that using global variables to share refs between threads did only trigger a warning at some point, not an error. I'm not 100% sure about that. But the serialization has been there since the early days of multi-threading support in 2011.
Thank you for clearing that up - I have always been confused when pcwalton has written (a bunch of times) that "Nim's GC isn't thread safe" - since... I knew about the deep serialization and couldn't for my life understand why it wouldn't be safe then.
But how could the segfaults then happen? Aha, you mean the test code perhaps shared via globals?
> Personally I am quite sick and tired of that particular "take" on Nim - why not for once criticize other parts of the language? :)
Because I'm not interested in criticizing languages as a whole—that would be language warring for no reason. Claims of memory safety are what are important to me, just as, for example, claims of correct crypto constructions are important to crypto people.
Anyway, I see no reason to go further here, given that nobody has claimed anything is memory safe.
Great! Thing is, Rust and Nim are very different. Just as I wouldn't put Rust down for not having GC (I love languages moving the art forward) I just wish we could look at Nim as a language with different design goals than Rust. I know several things in Nim worth discussing, it doesn't have to be warring.
It seems to me that a) Nim is (or at least is meant to be, but bugs can sidestep it) memory safe if you stay within the rules for it, and b) Nim is not throwing around vague claims of safety that are not documented in the language manual.
> It seems to me that a) Nim is (or at least is meant to be, but bugs can sidestep it) memory safe if you stay within the rules for it
That's completely worthless. C is also memory-safe if you stay within the rules for memory safety.
> Nim is not throwing around vague claims of safety that are not documented in the language manual.
Of course not since nim is not posting on HN (as it's not a sentient being prone to procrastination) it's obviously nim supporters making claims about nim's safety.
IMHO it's not worthless. Nim has ptr and addr, but they are explicitly described as unsafe and only used "when you have to", like interfacing with C/C++ etc. I have never used them outside of C/C++ integration. Rust also has unsafe, but I presume you don't think that invalidates safety.
> That's completely worthless. C is also memory-safe if you stay within the rules for memory safety.
It's really not any weaker of a guarantee than Rust makes, being memory-safe if you stay within the rules of not saying `unsafe`. Or opening /proc/self/mem for writing, anyway.
I'd also feel a lot better about Rust's moral highground of memory safety if its undefined behavior was actually spelled out a bit more rather than just punting the hard parts to llvm docs. I don't think every Rust user knows how to avoid aliasing problems between `&mut` and `*mut` either.
Well, I think there's a very big practical difference between being unsafe in general and unsafe only within clearly delimited boundaries (that you can forbid with a lint). The latter is pretty much necessary for any language other than strictly sandboxed ones like JavaScript, while the former is something I think all languages in 2016 should take as sacrosanct from the get-go. (We've been trying and failing for about 45 years to prove that programmers will avoid making the same basic memory management mistakes if they're just trained better; I think it's well past time to give up and delegate these checks to the machine.)
That said, I don't agree with the claim that Nim is less safe than Rust because Nim uses "ptr" types and Rust uses "unsafe" blocks to mark unsafe regions. I prefer Rust's approach, but it's pretty much just a question of UI, not anything substantive.
Even with the threading/memory management issues fixed by enforcing shared-nothing, Nim isn't memory safe unless the undefined behavior issues that come from compiling to C (for example, dereferencing a null pointer) are sorted out.
As I understand things, though, solving them is a work in progress.
Thanks for the link. The top comment's explanation, esp on GC, makes a lot of sense. Both specific keywords and a module-level declaration are rational ways of handling it. So long as it's clear to a person or program analyzing safety properties of a module then they can do what they need to do.
And you asked why this happens, and I answered, because Nim claims it is secure. Not more not less.
It's like saying OpenSSL is perfectly (or as good as it gets) secure, and there aren't any known vulnerabilities. That statement is going to get a strong reaction from anyone that specializes in security and reads HN (for example tpatcek).
I don't like or dislike Nim. I did like Nim's macro system, although I fear its too powerful (it seems like macros would be really easy solution in many cases).
Just curious since I must have missed it - where is this claimed? On nim-lang.org? And yes, Nim is not 1.0 yet so some areas are still evolving. And no, I don't think I asked anything?
Generally across HN? Nim's forum? There isn't a single source, I've also found a bunch of Rust/Nim comparison that eventually state something along the lines of Rust is equally safe as Nim[1] and it then gets reiterated on HN.
I still don't see it. You wrote "Nim claims it's secure" and I wonder where Nim does that. What I do see is careful explanations in the language manual what is safe and what is not. I am not even remotely as sharp as pcwalton, Araq or Jehan/rbehrends when it comes to these things, but my perception of what "Nim says" is basically "if you use these things, you should be ok. If you use these other things, you are in C country." Then of course modulo bugs and wip stuff. It is perhaps a different philosophy at play.
But I am genuinely interested in where this claim is made, perhaps we need to adjust some documentation or make things more clear - so do point us to it if you find it again.
It didn't come off as an insult to me. Anyone saying C++ or Nim tends to result in a counter from pcwalton. He usually says similar things as he has a consistent stance. Countering such a stance before they speak is OK given you already know what it is. In in a moral sense anyway.
However, that he stopped in his own comment to bring it up and drop a counter says more about him than pcwalton. Shows a strong bias for and protectiveness of Nim while also disregarding the entire reliability or security aspects of the language. That's really something for a C++ alternative given its safety focus. ;)
Sure, and I can apologize for my wording in advance too! But I do stand by my opinion that he doesn't have to drop that in every single time Nim is mentioned. Evidently Go-people feel the same I noticed.
I assume the distinction you are making about "serious" is around manual memory management and the GC?
In which case, I think you are probably right in your bias. That said and while i have no experience with it, Nim claims to have a real-time GC mechanism builtin. That is they support a max pause time parameter. There have been other real-time GC systems out there before and they tend to work well for other definitions of "serious".
I have the feeling, that "in the wild" most people replace JavaScript (Node.js), Python and Ruby with Go. Rust seems to be more of a C/C++ replacement.
It would be really interesting if someone could collect statistics on which languages are used to replace code written in which others, in practice and not just in theory. Something that crawls GitHub, maybe, but I'm not sure exactly how to specify what it should look for. Any ideas?
Can't anybody from the rust community take over this site? Creating a completely new site might be a fallback, but arewewebyet is referenced / linked very often and ranks high.
Can you say something about those points? I mean there aren' many...
HTTP Server?
DB Drivers?
Frameworks?
E-Mail?
I mean on Node.js I use Hapi (+a few plugins) and Sequelize, which does pretty much everything for me. I would guess, that everything besides the DB drivers is available in Rust too...
It's not just about how many, but how mature they are. There's been a lot of work in the last year.
For servers, there's rotor and hyper. Database drivers, we have very good Postgres and MongoDB options, with some SQlite bindings too. Possibly others, I don't pay too much attention to this space. We have multiple ORMs, one of which is being written by the maintainer of Rails' ActiveRecord. As for frameworks, we don't have a ton of full-stack ones, but a number of the smaller ones, iron, nickel, etc. I haven't explored email yet, but I know that there's some work there.
Email - homemade email servers is a good way to go into blacklists, so mandrill/postman is the much better choice.
"Several hundred thousand things about the place" - not actual anymore, there are rare things which are not covered by crates. Just open crates.io and type name of thing you need.
Agreed. That site was a good rundown at one point, but now it seems like a hurtful distraction.
Are there any other good references for what the current state of these sorts of capabilities have reached? There are any number of crates out there for this sort of thing, but assessing usefulness seems dodgy at this point.
Sorry, I had no idea. Will update my comment. It's a pity, though. I really liked checking on the status of the latest work for web development in Rust from a single place.
edit: It seems that I can't edit that comment anymore.
But... generally, I would say all these languages can replace each other (well, ok, perhaps not C) given the right circumstances. Nim has one nice thing going for it - and that is very good C/C++ integration. Rust has it's safety focus and novel memory model. Go has simplicity and tooling, and popularity. Java has enterprise-focus. All have good performance.
In its most basic form, yes, but because of Rust's safety guarantees it's not quite that simple. C functions can only be called from unsafe blocks and there is a lot to be desired when you have to pass strings back and forth (I don't know how well Nim handles this). It's also a bit harder to debug an FFI wrapper in Rust when you tell the compiler your code is safe but then make a mistake in how you use the unsafe C api.
I strongly prefer Rust's safety but it's not quite the same as a blind FFI like Nim.
> It's also a bit harder to debug an FFI wrapper in Rust when you tell the compiler your code is safe but then make a mistake in how you use the unsafe C api.
Can you elaborate on to how not having to type unsafe makes debugging of this easier?
Note though that C++ is something very different. And c2nim can produce C++ wrappers, see for example Urhonimo, a Nim wrapper of Urhod3D. Of course this is a benefit from going via C/C++ offsetting the disadvantage. Btw, I am not negative towards Rust, although I prefer Nim for my use cases (but eventually I will try Rust) - I just wish people could view and critique languages from their respective design goals.
Does anyone with significant Nim experience care to lend some opinions? I don't want to start a flame war--I'm genuinely curious.