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

Nim 1.0

nim-lang.org

Post reply on HN
Print view View original

141–150 of 308 posts

Re: Nim 1.0

#141

Post by PMunch »

neverartful wrote: post #112
TylerE wrote: post #104

Earlier quoted context omitted.

Nim performance is really really good. Like, maybe C - 5%. Comparable with stuff like Rust or D... way way faster than Go or anything interpreted.

I think it depends on the nature of the code. For a side project of mine, I recently re-wrote the same code in a dozen or so languages. The application reads input data from text file and does a bunch of conversions to integers and floats (atoi and atof). It then runs through an algorithm that does calculations and identifies proper actions. Finally, it writes the output data as formatted text file. Regardless of imp…

Surprised to see Nim that slow, typically it ranks much higher in benchmarks. But without looking at the code and compiler options its hard to tell if it is simply the problem or the implementation that's to blame.

Re: Nim 1.0

#142

Post by dual_basis »

mratsim wrote: post #86
nfrankel wrote: post #20

Question (genuine, not trolling): what's the use-case for Nim regarding other languages? What are its pros/cons?

I'm from Status, Nim's main sponsor and a blockchain company that is doing Ethereum 2.0 research and implementation in Nim. Nim had the following appeal for us: - Ethereum research is done in Python, we actually started our code with a tool called py2nim to convert a 50k lines Python codebase to Nim in less than a month (and remove cruft for 3 months but that's another story). - Nim allows us to use a single language…

I like Nim very much, however I do not think it will solve the 2 language problem. One of the things I lean on heavily in Python when experimenting and researching is the dynamic nature of the language. I believe this is also a strong factor for others.

For me, Julia completely addresses the 2 language problem. In practice I think it now simply needs a stronger ecosystem, better static analysis, and bug fixes, but I am very happy with the language design.

Re: Nim 1.0

#143

Post by PMunch »

daemon_beard wrote: post #63
PMunch wrote: post #55

Earlier quoted context omitted.

Nitpick, but it actually compiles down to C. Nim works at a higher abstraction and the compilation is a one-way street. But what is more important is that it generates efficient C code, it looks ugly, and it's not something you would ever dream of writing yourself, but it's been optimised to give fast run-times. Often times in benchmarks the Nim code with optimisations comes out as fast as the C code with optimisatio…

Since you seem to know how this works -- I hope you won't mind if I ask you a slightly on-topic question about this... I've been trying to find out if I can take the generated C code that nim produces and, for example, compile it on some exotic architecture (say an ancient solaris/sparc system or some aix/power thing, or some mips microcontroller with linux) however I can't find any examples of people doing this... I…

As the others have said it should be possible. Nim is already pretty good at cross-compiling, but it is also able to just spit out the C files it generates and allow you to play with those.

Re: Nim 1.0

#144

Post by muktabh »

dom96 wrote: post #38

Shameless plug, but by a nice coincidence, Manning has a discount on all printed books today. Among them is my book, Nim in Action, available for $25. If you're interested in Nim it's a great way to learn :) It was published in 2017 but we've ensured Nim is compatible with it (all book examples are in Nim's test suite), so apart from some minor deprecation warnings all examples should continue to work. Grab a copy he…

I bought a copy of the book a few months back (and haven't yet found time to read it fully, I can write a lot of programs just after reading a first few chapters), will Manning upgrade it for a newer version for Nim 1.0 ?

Re: Nim 1.0

#145

Post by dvfjsdhgfv »

PhilippGille wrote: post #128
nathcd wrote: post #8

Congratulations Nim team! :D I've had Nim installed on my laptop for a long time and I've always enjoyed tinkering around with it over the years. Maybe now it's time to find a bigger project to try it out on. This is a tiny thing, but just to highlight something unique I like about Nim, using `func` to declare pure functions (and `proc` for others) has been a small, but really nice quality of life improvement. It's s…

"V" would also fit into that list I think. https://vlang.io/

I was really excited when I saw V for the first time. Then as I was checking the claims one by one it turned out the author was only half honest. That was bad, really bad. I don't feel like visiting this website again and wonder if any of these claims are true or just a kind of strange marketing in order to collect donations.

Re: Nim 1.0

#146

Post by tomp »

Varriount wrote: post #139
tomp wrote: post #132

What’s Nim’s concurrency story? Since it’s compuled via C, I suspect the answer is “shitty” as in I expect it to inherit all of C’s issues with undefined behaviour, values out of thin air, and so on...

That's kinda jumping the gun - just because something is compiled to C, doesn't mean that it has all of the characteristics of C. That's like saying that because something is compiled to assembly, it has all the complexities and dangers of assembly. For example, take a look at Cython, CGo etc. Regarding concurrency, Nim has cross-platform thread support in the standard library. Concurrency, at least right now, is mor…

> and memory from one thread's heap cannot be referenced by another thread's heap without use of unsafe pointers

Are you sure about that? Your statement seems to conflict Nim's manual, which says

> Each thread has its own (garbage collected) heap and sharing of memory is restricted to global variables.

This does suggest it inherits all of C's memory (un)safety characteristics.

Re: Nim 1.0

#147

Post by hota_mazi »

p5a0u9l wrote: post #113

But why do they have to use camelCase? I don't know why it bothers me so, but I see that in a language or a repo and immediately and irrationally despise it. Is it just me?

More of a personal preference, but to me, typing all these underscores all the time would probably give me carpal tunnel syndrome within just a few years.

Re: Nim 1.0

#148

Post by PMunch »

tachyonbeam wrote: post #114
p5a0u9l wrote: post #113

But why do they have to use camelCase? I don't know why it bothers me so, but I see that in a language or a repo and immediately and irrationally despise it. Is it just me?

Camel case is extremely common, but it's funny that they use it given that the language is case insensitive: https://github.com/nim-lang/Nim/wiki/Unofficial-FAQ#why-is-i... Sidenote: not a Nim user, but this seems like it could get in the way of interoperability with C (and most other languages)?

Not really, when you want to import things from C you simply name them what you like and then you can call them in a case-insensitive fashion. When writing code that should be imported into C code it will either have its name exactly as typed, or you can specify a name for it yourself.

Re: Nim 1.0

#149

Post by PMunch »

p5a0u9l wrote: post #113

But why do they have to use camelCase? I don't know why it bothers me so, but I see that in a language or a repo and immediately and irrationally despise it. Is it just me?

As other have mentioned Nim is style insensitive. This might sound odd at first, but it allows you to use snake_case in your code even though the standard library is camelCase. It also allows me to use your snake_case library in my camelCase code without ending up in mixed_Case hell like you often end up in Python.

Re: Nim 1.0

#150

Post by peteforde »

stakhanov wrote: post #41
mumblemumble wrote: post #29

Earlier quoted context omitted.

At first blush, it's easy to describe Nim as C-flavored Python, but I'm not sure that quite captures it. The syntax is similar, but that's about where the similarities end - Python is deeply, fundamentally a dynamic language, and Nim one of the more firmly statically typed non-functional languages out there. You could also describe it as being competitive with Rust, but with more compromises for the sake of developer…

I disagree in quite a few respects. I think there's not much merit in discussing "C-flavored Python" as a description of nim, as that description seems just wrong. Aside from significant whitespace, I don't find that many similarities with Python syntax. Describing Nim as non-functional is misleading. Nim does have functional constructs and is a mixed-paradigm language involving both procedural and functional element…

In fairness, Python is the first language the Nim team compares itself to in the first paragraph of their homepage.
Post reply on HN