Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What makes Nim practical?

hookrace.net

Post reply on HN
Print view View original

71–80 of 132 posts

Re: What makes Nim practical?

#71

Post by xtrumanx »

def- wrote: post #60
xtrumanx wrote: post #52

> That means you end up with a single binary that depends solely on the standard C library, which we can take for granted on any operating system we're interested in. What exactly does that mean? Does the end-user of my binaries require a C compiler? Which operating systems are "we" interested in. I'm interested in Windows and specifically Windows CE.

That means if programs written in C work on your OS, so do the ones in Nim.

Sorry if this is a silly question but I've always thought of C as generating machine code and it had compilers available in any imaginable platform besides perhaps really niche stuff.

Were my assumptions accurate?

Re: What makes Nim practical?

#72

Post by dom96 »

joelthelion wrote: post #66
bpicolo wrote: post #62

Earlier quoted context omitted.

Let's be realistic. If you have somebody naming variables: foo_bar = blah foobar = blah fooBar = blah That's someone you really don't want to be coding anywhere near, because it leads to really, really confusing code. So nim is just enforcing not being able to do it it as a language.

It still means you can't reliably grep code for an identifier. Strikes me as a really stupid wart in an otherwise great language. go format is a much better solution to the same problem.

You can with NimGrep: http://nim-lang.org/nimgrep.html

Re: What makes Nim practical?

#73

Post by quotemstr »

CyberShadow wrote: post #29

Nim has some good ideas but I can't get over the syntax: - Significant whitespace, but tabs are forbidden - No block comments, save for `discard """ ... """` - Identifiers are case and underscore-insensitive (FOO_BAR === fooBar === fo_ob_ar)

Underscore insensitivity is unforgivable: it makes grep work poorly. I guess I'll have to strike Nim from the list of languages I might want to use.

Re: What makes Nim practical?

#74

Post by quotemstr »

dom96 wrote: post #72
joelthelion wrote: post #66

Earlier quoted context omitted.

It still means you can't reliably grep code for an identifier. Strikes me as a really stupid wart in an otherwise great language. go format is a much better solution to the same problem.

You can with NimGrep: http://nim-lang.org/nimgrep.html

If a language's lexical structure is so tortured that I need a special tool to grep it, I'm going to skip it and go back to the sanity of C++.

Re: What makes Nim practical?

#75

Post by mVChr »

bpicolo wrote: post #62
mVChr wrote: post #58

Earlier quoted context omitted.

> - Identifiers are case and underscore-insensitive (FOO_BAR === fooBar === fo_ob_ar) In the language design stages who in the world thought this would be a good idea? Even PHP doesn't do that.

Let's be realistic. If you have somebody naming variables: foo_bar = blah foobar = blah fooBar = blah That's someone you really don't want to be coding anywhere near, because it leads to really, really confusing code. So nim is just enforcing not being able to do it it as a language.

How about distinguishing between public, private and protected properties? How about being able to quickly identify classes versus instances? How about explicit is better than implicit?

Re: What makes Nim practical?

#76

Post by falcolas »

falcolas wrote: post #22
def- wrote: post #18

Earlier quoted context omitted.

As unwind suggested, they just get transformed down to global functions with unique names. Here's the actual C code generated: https://gist.github.com/def-/0fe87bf1d35102c62d3b#file-nest-...

Nice. Not the most compact code I've seen, but it makes sense considering it's the output of a compiler, and can thus take advantage of optimizations from clang/gcc/what_have_you. EDIT: Actually this raises the question of how it handles closures, since the generated code does not seem to provide for preserving the surrounding environment data. Though I may just need to dive in now that it's catching my interest.

And answered:

http://nim-lang.org/manual.html#closures

Re: What makes Nim practical?

#77

Post by pjmlp »

pcwalton wrote: post #54
def- wrote: post #6

Earlier quoted context omitted.

Why would you say it's not competing with D and Rust? Performance-wise Nim should be in the same ball-park, and you can do systems programming in it. For me Nim is a universal language which I can use for almost anything.

Nim does not have the memory safety without garbage collection features of Rust. If you want memory safety in Nim, you have to use the garbage collector (which, last I looked, is not thread safe either, although I see that Boehm is now an option). It's easy to write (a) an unsafe language that has no GC, or (b) a safe language that relies on GC for safety. It's also easy to write a language that is in category (b) bu…

I think it is a matter of what is safe.

While Ada doesn't provide the parallelism safety mecanisms from Rust, is is pretty much a safe systems programming language, specially the SPARK dialect.

And I do conceed that using RAII or memory pools is a bit more cumbersome than in Rust.

EDIT: Forgot to add that for me systems programming safety has been for a long time what Modula-3, Oberon and Ada offer. Only recently it became clear to me that Rust safety module is more broad.

Re: What makes Nim practical?

#78

Post by pjmlp »

moe wrote: post #2

I love how these new languages compile into a static binary and thereby avoid the deployment nightmares of Ruby/Python. More of that please!

If Common Lisp, Scheme or Dylan had been adopted by mainstream programmers, dynamic languages with JIT/AOT compilers would already be a common practice instead of only available to a few that care to look around.

Re: What makes Nim practical?

#79

Post by pcwalton »

pjmlp wrote: post #77
pcwalton wrote: post #54

Earlier quoted context omitted.

Nim does not have the memory safety without garbage collection features of Rust. If you want memory safety in Nim, you have to use the garbage collector (which, last I looked, is not thread safe either, although I see that Boehm is now an option). It's easy to write (a) an unsafe language that has no GC, or (b) a safe language that relies on GC for safety. It's also easy to write a language that is in category (b) bu…

I think it is a matter of what is safe . While Ada doesn't provide the parallelism safety mecanisms from Rust, is is pretty much a safe systems programming language, specially the SPARK dialect. And I do conceed that using RAII or memory pools is a bit more cumbersome than in Rust. EDIT: Forgot to add that for me systems programming safety has been for a long time what Modula-3, Oberon and Ada offer. Only recently it…

Yeah, Ada/SPARK is safe too. But as I understand it achieves that by removing deallocation (from a single untyped heap) entirely, which is pretty limiting, though sufficient for a lot of embedded work.

Re: What makes Nim practical?

#80

Post by geoelectric »

xtrumanx wrote: post #71
def- wrote: post #60

Earlier quoted context omitted.

That means if programs written in C work on your OS, so do the ones in Nim.

Sorry if this is a silly question but I've always thought of C as generating machine code and it had compilers available in any imaginable platform besides perhaps really niche stuff. Were my assumptions accurate?

Simplified, but yeah. It generates intermediate object code, which is transformed to machine code.

And as you say, pretty much every platform in existence has a C compiler targeting it. In many cases, you use what's a called a cross-compiler, which lets you generate code for, say, Arduino using tools run on, say, Linux. But one way or the other there'll be a way to compile for it.

Net result is that as long as the code isn't doing something that is specific to the platform (memory layout assumptions, asm blocks, Windows API, etc.) the same C code will run on many different platforms. You'll have to recompile it for each one, but you won't have to change the source (much).

If I understand correctly, Nim ultimately generates C source (among other options) which then goes through the above process. So it has the same level of portability.

Post reply on HN