Live data from Hacker News

Nim version 2.0.0 release candidate

nim-lang.org

91–100 of 121 posts

Re: Nim version 2.0.0 release candidate

#91

Earlier quoted context omitted.

To be fair, python back then didn't have great competitors in its space. I guess Perl, but from what I still remember from Perl before I dropped it like a hot potato a couple days in, it wasn't particularly great. Nim does.

Python vs Ruby seemed like a real fight for a while, especially when there was Rails and python did not really have anything equivalent.

Actually a really good point! I entirely forgot about Ruby! Though in terms of competition that does still seem less crowded of a field as one where your other contenders are C, C++, Rust (and for application and web-development there's also Go, to some degree also Java and Python)

Re: Nim version 2.0.0 release candidate

#92

Any die-hard lovers of Nim? Or heavy users? Why do you use it over other languages? What was your ah-ha moment?

As a Python user, I had my a-ha moment with Nim when I realized I didn't need a repl.

With Python, I used repl all the time. There's bpython, ptpython, ipython, and probably a couple more great repls because repl is really important for Python development.

Nim's INim is no match for those. But here's the great part: with Nim you don't have to test code snippets all the time. I get all my error messages before they happen. This felt liberating after Python.

Re: Nim version 2.0.0 release candidate

#93
post #72

In my understanding, Nim at the moment is really a transpiled language, instead of compiled. Transpiled to C, then tooling uses clang or gcc to do compilation from C to target platforms. It is like TypeScript to JS in C/C++ world. Very clever to stand this way on the shoulders of giants, but the amount of moving parts is staggering and horrifying.

It is a compiled language, how the backend is implemented it is an implementation detail, transpiled was a term the JS community came up with, which you won't find in languages like Eiffel that always compiled to native code via C for the last 30 years. Or C++ and Objective-C in their yearly days, or the P2C Pascal compiler from 40 years ago.

Well, then I have to agree

    the program is nothing more than a sequence of plain characters, stored in a text file. This abstraction is a complete mystery for the computer, which understands only instructions written in machine language. Thus, if we want to execute this program, the first thing we must do is parse the string of characters of which the high-level code is made, uncover its semantics—figure out what the program seeks to do—and then generate low-level code that reexpresses this semantics using the machine language of the target computer. The result of this elaborate translation process, known as compilation, will be an executable sequence of machine language instructions.
    Of course, machine language is also an abstraction—an agreed upon set of binary codes. To make this abstraction concrete, it must be realized by some hardware architecture. And this architecture, in turn, is implemented by a certain set of chips—registers, memory units, adders, and so on. Now, every one of these hardware devices is constructed from lower-level, elementary logic gates. And these gates, in turn, can be built from primitive gates like Nand and Nor. These primitive gates are very low in the hierarchy, but they, too, are made of several switching devices, typically implemented by transistors. And each transistor is made of—Well, we won’t go further than that, because that’s where computer science ends and physics starts.
Excerpt from https://www.nand2tetris.org/book

Re: Nim version 2.0.0 release candidate

#94
post #73

Earlier quoted context omitted.

The name is confusing, but Nim's Arc is not the same as Rust's: https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc... . Rust (and apparently Swift) uses Arc to refer to atomic reference counting, whereas Nim's means automatic . There's still overhead, but it would be more comparable to Rust's Rc, I believe.

Swift uses ARC to mean automatic, and its use comes from Objective-C's ARC.

Huh, the Nim blog post appears to be wrong, then, or I misunderstood it.

Re: Nim version 2.0.0 release candidate

#95

In my understanding, Nim at the moment is really a transpiled language, instead of compiled. Transpiled to C, then tooling uses clang or gcc to do compilation from C to target platforms. It is like TypeScript to JS in C/C++ world. Very clever to stand this way on the shoulders of giants, but the amount of moving parts is staggering and horrifying.

> In my understanding, Nim at the moment is really a transpiled language, instead of compiled. Transpiled to C, then tooling uses clang or gcc to do compilation from C to target platforms.

If I understood correctly, like the Vala language: https://vala.dev/ (Note: Vala is strongly integrated with GObject).

Re: Nim version 2.0.0 release candidate

#96

among nim, zig and rust, I'm most likely to learn nim, it has been there for a while and it is solid and has so many good stuff in it, it just needs more 'marketing'. in particular, python really should help its popularity as their syntax are similar and both are very expressive.

Is syntax really that big of an obstacle to learning a first programming language? The semantics of a C-like language like Nim could hardly be more different to Python's, they're pretty much at opposite ends in the stack.

Syntax is pretty much the entire reason that people stay away from languages like Erlang and Lisp

Re: Nim version 2.0.0 release candidate

#97

I am pleased to see a language that focuses on good multithreaded support. I tend to use Java and C for multithreaded problems but having the availability of Nim which looks similar to Python is really promising.

If you want good multithreaded support and don't care much about ensuring perfect thread-safety at all times, you can't beat Go for real-world use.

Elixir fits in here as well, if the workload is thread-bound and not computation bound.

I think Elixir's syntax and idioms are better than Go's, but that's personal preference.

Re: Nim version 2.0.0 release candidate

#98

Any die-hard lovers of Nim? Or heavy users? Why do you use it over other languages? What was your ah-ha moment?

As a Python user, I had my a-ha moment with Nim when I realized I didn't need a repl. With Python, I used repl all the time. There's bpython, ptpython, ipython, and probably a couple more great repls because repl is really important for Python development. Nim's INim is no match for those. But here's the great part: with Nim you don't have to test code snippets all the time. I get all my error messages before they ha…

Agree to disagree, I use inim all the time to test out those code snippets folks post in nim's discord to see what's broken in them :-P

Re: Nim version 2.0.0 release candidate

#100

Any die-hard lovers of Nim? Or heavy users? Why do you use it over other languages? What was your ah-ha moment?

For me, the biggest advantage of Nim compared to other hagh-performance languages (C, C++, Rust, …) is that it doesn't overcomplicate simple things. I wrote an article about it: https://xigoi.neocities.org/nim-doesnt-get-in-the-way.html

The syntax is very pleasant to write and read, even I have some small issues with it. No unnecessary noise like braces and semicolons, no misusing the less-than and greater-than signs as brackets.

Also, it uses terminology more correctly than other languages. Procedures are procedures, not “functions”. Resizable arrays are called sequences, not “vectors”. Immutable variables are immutable variables, not “constants”.

The standard library is quite good (though it could use improvements) and extensive enough that you don't get hundreds of dependencies per project like in JavaScript or Rust.

Post reply on HN