Araq

Support for embedded is indeed getting into focus. I hope to release an article soon how the '--gc:regions' switch works (which is misnamed, it's a way to do memory management, not a GC...) and in the longer run the destructor-based runtime will ensure that memory is freed sooner than a GC would for memory constrained devices.

Having said that, "embedded" is a wide field and sometimes one cannot even afford a heap, no matter if garbage collected or managed manually. But even then Nim can be used, you still get array bounds checking, Ada-inspired strong type checking plus the meta programming goodies.

I agree that 'discard' is usually a code smell, but how would implicitly ignoring the result be any better? It wouldn't be better at all, and that means Nim's discard feature is rather well designed as it improves the status quo.

I'm not following you really. 'discard' is an enforced, explicit statement about that you throw away information/the result of a computation. That's against "nice if you are programming alone" as much as it can get.

That's true and I wouldn't use the Option type for that either. There is a switch that warns about variables that are not initialized explicitly (including the 'result' variable) and an RFC to make this switch non-optional. https://github.com/nim-lang/Nim/issues/7917

We're slowly getting there though. I hope to release a blog post soon about how it might look like in Nim.

> But to ask a pointed question, doesn't that mean Nim gets the worst of both worlds? You have both the overhead of updating reference counts and the (relatively long) garbage collection pauses.

There's a patch of the collector to make the M&S incremental, to avoid pauses for this step too. Of course, whether a deferred RC'ing GC with incremental cycle collector works better in practice than a more conventional generational incremental GC (or just an incremental GC) is an open question. :-)

Nim has garbage collected pointers (ref) and raw pointers (ptr). You can use 'ptr' to break up cycles manually and disable the M&S. I suppose it's very much comparable to Swift except that Nim's RC overhead is much lower since it's deferred RC.

> There are other ways to address this issue. You can do what Swift does and call into libclang so that you can pull out the structure definitions, for instance.

Sure and you only need to call libclang for each different platform. Or is it on every platform? ;-)

Compiling to C vs using LLVM is a complex design tradeoff. For example, the Posix standard specifies a C interface. Quote: "The stat structure shall contain at least the following members..." This means you can wrap 'struct stat' in Nim once and be done with it (since the mapping to C is by generating C code) whereas for eg Rust you need to wrap it once for every different OS (and potentially even for every OS version+CPU combination), since the offsets and sizes can differ. So yes, porting to other platforms really is easier when you have a C code generator.

Good questions. I'm afraid the documentation is seriously out of date about the GC: It used to implement a variant of "trial deletion" so that "never scans the whole heap" used to refer to the fact that it doesn't use traditional mark&sweep, but only scans the subgraph(s) leading to the cycles. Of course you can always create a "subgraph" that spans the whole heap, so even for trial deletion it is a dubious claim.

Since version 0.14 (iirc) however, Nim uses a traditional mark&sweep backup GC to collect cycles. Reasons: Trial deletion in practice is much slower.

For all versions of the GC is stack is scanned conservatively as precise stack scanning is simply too expensive when C is your main target.

> The manual even says that just calling printf is actually unsafe as the cstring could be GC'd (but it probably won't).

The manual tries very hard to mention corner cases since it's evolving into a proper spec. Calling printf is safe, it's C functions that take ownership of the char* pointer that are inherently unsafe.

> Maybe Nim should have an unsafe directive to make sure any unsafe user code is clearly marked?

That's a common misunderstanding, Nim doesn't need this. Instead of an ``unsafe`` keyword, Nim has ``addr`` and ``cast`` as keywords, these are the unsafe building blocks of the language. There are other corner cases that introduce unsafety, but they are all known and can be solved in time.

> I also coulda sworn there was some part of the manual or site that was discussing a feature with a limitation due to the difficulty of expressing it in C.

Well these things certainly are everywhere, but the issue here is not the difficulty of expressing it in C, but a desire to have very good C interop. Rust actually has all the same design constraints even though Rust builds on top of LLVM because the constraints come from the "systems programming" problem domain: Control over memory layouts, the stressed difference between heap and stack, etc. LLVM's IR is very close to C, so what is difficult to map to C is difficult to map to LLVM too.

> And there's no strong sense of design and elegance. It very much comes off as "here's a bunch of ideas thrown together with the restriction that they all must somehow compile to C".

But C is Turing-complete, so there is no restriction here. It's also not a "bunch of ideas thrown together" anymore than Haskell or Scala or Rust is. Nim focuses on 3 things:

* Metaprogramming via a hygienic AST-based macro system.

* An effect system to make the type system simpler to use. (The compiler infers an awful lot of useful information for you, the docgen shows the results for everybody to look at.)

* GC'ed thread local heaps where each GC can comply with soft-realtime requirements. Hard realtime is being worked on.

Any modern statically typed language also needs to have generics, closures, inheritance, exceptions or workarounds of the same complexity, so yeah Nim also has these making Nim instantly a big language. That doesn't mean it's a "bunch of ideas thrown together".

> It doesn't have memory safety as a core goal.

It does and it is reasonably safe (yeah yeah yeah we don't check for 'nil' properly yet, give me a break) with quite some improvements in the pipeline.

Shrug, you left out:

- Conservative GC marking of the stack.

- No stack overflow check in release mode.

Compiling to C is not tricky, it is horrible and we don't do it for the fun of it! That said, clang has lots of options to tame C's undefined behaviour. Guess what, you can enable these too for C code generated by Nim.

Well I did my homework. When you find another language that does it in a somewhat similar fashion, I'll happily change the website. ;-) I didn't think Rust counts, but since it's constantly changing, I will have a fresh look at it.

Disclaimer: I'm the lead designer of Nim.

pcwalton's remark is excellent but "automated proof technology" is not a well defined term. What I mean by this is that it goes beyond what a traditional type checker can do. I don't think Rust can do exactly the same things via its borrow checking and its iterators, but I might be wrong. Note that the very same analysis also proves your index bounds are correct.

Nim's disjoint checker is so experimental that its docs are indeed very terse and we only have a couple of test cases for now. That said, the disjoint checking is restricted to the 'parallel' statement, so its complexity only affects this language construct and not the whole language. You can think of it as a macro that does additional checking.

You cannot do these things easily currently since the assignment operator cannot be overloaded. There are ways around it, you can "fix" the broken builtin assignment with a TR macro, but since TR macros MUST not change semantics (you can disable them on a global level and code shall continue to work!) this is a bad idea.

Thanks for mentioning Nim! :-)

I can't say I agree with anything you say though... So only memory safety is C's problem? Not its type system that's very weak in every aspect (not just memory safety)? Not its missing module system? Not its ambiguous syntax?

You also confuse "simple" with "primitive" and perhaps "familiar". C surely is primitive, but how is it simple? Simple to use? No. Simple to implement? Not really. Has a simple mapping to the underlying hardware? That stopped being true three decades ago.

As the primary author of Nimrod I disagree. ;-) And to be blunt: I know the person has no idea of what he talks about when he uses the word "transpile".

Nimrod solved that... The solution in a nutshell: If a statement list contains a 'return', it enforces a 'void' context for the statement list, otherwise the statement list has the type of the tailing expression e in (s; s; e).

(Disclaimer: I am the creator of Nimrod.)

What you say is entirely correct; however Nimrod's effect system is not tied to any runtime mechanisms like a GC and provides lots of other aspects of safety. For instance you can ensure at compile time that a particular piece of code performs no database operations.

Also the effect system will improve the safety for concurrent programming quite a lot; coming soon in some of the next versions. (Sorry, no papers about it yet.)

Strings should be converted to UTF-8 as part of input validation. For proper input validation we have the taint mode already. Note that often a file does not include any information about the encoding, so you can only use heuristics.

This is very true; however c2nim distinguishes between #def and #define for this reason and this helps a lot. #def means c2nim needs to expand the macro, #define means it's some macro that should be translated into a Nimrod template. Coming up with heuristics to do this #def vs #define distinction automatically seems to be quite easy and might be implemented in a later version of c2nim.

It delivers? Lol. The GC used to suck for 32 bit systems and it still sucks for realtime. As opposed to Nimrod's which pretty much guarantees a maximum pause time of 2 milliseconds -- independent of the heap size. And that's only the start: Go also lacks generics and meta programming in general. And its memory/concurrency model is just as racy as Java's.

Ok, lets see: UTF-16 strings encourage bugs with surrogates. Note that most C# and Java code is notoriously broken wrt those and yet I never hear anybody complain about it.

UTF-32 strings roughly take up 4x more memory than UTF-8 strings and yet hardly solve anything: The proper toUpper("ß") used to be "SS" in German (nowadays there is an upper cased 'ß'). Other languages have other rules; i18n is hard, get used to it.

IMO Nimrod's UTF-8 strings at least make the programming errors easier to spot instead of the "mostly working but fails for edge cases" style that UTF-16 or UTF-32 encourage.

Hello everyone, I'm the designer of Nimrod. I will be glad to answer any questions regarding the language.