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

91–100 of 132 posts

Re: What makes Nim practical?

#91

Post by rudolf0 »

beeworker wrote: post #63
xkarga00 wrote: post #9

Earlier quoted context omitted.

Care elaborating on why is it a better Golang?

Just about everything is better than Go. Nim, Rust, OCaml, Haskell... Did you read the submission? And for further enlightenment, the link to the previous post on the blog about what makes Nim special? Here's a link to a rant comparing Go and Rust, which includes some links of its own highlighting further issues with Go: http://www.quora.com/How-do-Go-and-Rust-languages-compare

I like to think of Go as a niche language with excellent tooling for small-medium microservices and various forms of networking clients and servers. When you look at it in that light, it's not a bad language. It's an okay language missing a lot of features (many based on good intentions, some due to what I consider poor design) that could make it a good language.

Rust is objectively much better, but I suspect that for the next 5 years, Rust will only remain popular for systems programming but not application/web dev, and Go will only remain popular for what it's currently doing but not systems programming (with some semi-exceptions like Docker and Kubernetes, though that's not really systems programming).

Re: What makes Nim practical?

#92

Post by jwiley »

Can someone point me to an explanation of "Nim is the only language that leverages automated proof technology to perform a disjoint check for your parallel code"? This is mentioned prominently on the main page...but scanning the docs, the FAQ, Dr. Dobbs, and Googling 'nim disjoint' didnt lead me to a detailed explanation.

Re: What makes Nim practical?

#93

Post by malkia »

I'm assuming "staticExec" is not sandboxed in any way...

It's one thing to make your compile stuck it's head while doing #include "aux" in windows, but completely different to treat source code as "shell"-script.

(I see the point, and it's a great feature, but with too much power).

Re: What makes Nim practical?

#94

Post by fiatjaf »

xkarga00 wrote: post #9
iopq wrote: post #5

I just realized something: Nim is like a faster Python or a better Go lang It's not really competing in quite the same space as say, D or Rust. It's like a statically typed scripting language.

Care elaborating on why is it a better Golang?

I don't know if it is, I use Golang and I never used Nim, but the source code from Nim is way prettier: http://rosetta.alhur.es/compare/nimrod/go

Re: What makes Nim practical?

#95

Post by [deleted] »

beeworker wrote: post #63
xkarga00 wrote: post #9

Earlier quoted context omitted.

Care elaborating on why is it a better Golang?

Just about everything is better than Go. Nim, Rust, OCaml, Haskell... Did you read the submission? And for further enlightenment, the link to the previous post on the blog about what makes Nim special? Here's a link to a rant comparing Go and Rust, which includes some links of its own highlighting further issues with Go: http://www.quora.com/How-do-Go-and-Rust-languages-compare

[deleted]

Re: What makes Nim practical?

#96

Post by dogprez »

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?

I think you got confused when the C standard library was listed as a dependency. What is meant is the resulting binary had a link to a dynamic library (libc). For example if you are on a Mac run "nm /usr/lib/libc.dylib", those are the symbols that it might be referencing in a compiled nim program. I don't know the equivalent in Windows, but the dynamic library is a DLL. It doesn't have a runtime dependency on the compiler.

Re: What makes Nim practical?

#97

Post by jpolitz »

bch wrote: post #83
dogprez wrote: post #48

Earlier quoted context omitted.

Your example isn't exactly true. Clang and GCC both do tail call optimizations. Compiling language functions to C functions doesn't 100% preclude you from TCO. http://david.wragg.org/blog/2014/02/c-tail-calls-1.html

See also: http://www.pipeline.com/~hbaker1/CheneyMTA.html It looks like work/research in this area has been going on for at least ~20 years.

Indeed it has. For a few more examples, see also http://www.ustream.tv/recorded/43777177, and http://www.ccs.neu.edu/racket/pubs/stackhack4.html. Pyret (http://pyret.org) uses similar stack techniques to these to simulate an arbitrarily deep stack while compiling to JS.

Re: What makes Nim practical?

#98

Post by pekk »

iopq wrote: post #5

I just realized something: Nim is like a faster Python or a better Go lang It's not really competing in quite the same space as say, D or Rust. It's like a statically typed scripting language.

Nim can't be a faster Python when it isn't a Python, but a much younger language which lifts a few cosmetic choices but intentionally breaks with Python in large ways. If it is trying to replace Python, many of these breaks are poorly chosen and reflect a lack of understanding of why Python and its ancestors were unique. Aside from this, many of the practical refinements of Python are dropped in favor of fancy and shiny features that are better for arguing on HN than actually using. If I really want macros, Lisp never went away, but they aren't doing Nim's readability any favors.

Go is much more mature than Nim and encapsulates a huge amount of thinking and experience in language and compiler design. Nim would like to be Go. But it isn't.

Re: What makes Nim practical?

#99

Post by pekk »

fiatjaf wrote: post #94
xkarga00 wrote: post #9

Earlier quoted context omitted.

Care elaborating on why is it a better Golang?

I don't know if it is, I use Golang and I never used Nim, but the source code from Nim is way prettier: http://rosetta.alhur.es/compare/nimrod/go

As a Python programmer, I find the Nim version needlessly cryptic, glyph-laden and ALGOL-esque, with many of the unattractive traits of Python from 10-15 years ago. If I get the choice to start out in a codebase which looks like this from brand new, I'll certainly pass. That's sad when "prettier" is really all that's being offered here.

Re: What makes Nim practical?

#100

Post by pekk »

andybak wrote: post #34
wtf_is_up wrote: post #24

Earlier quoted context omitted.

> significant whitespace That's not an advantage

From my personal perspective - it's a major plus when choosing a language - under the general auspices of "readability counts". I find Python-like languages much easier to read and maintain - and significant whitespace is a not-insignificant factor in that.

Indentation helps, but it's a pretty pointless thing when you make a lot of other decisions that hurt readability.
Post reply on HN