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

221–230 of 308 posts

Re: Nim 1.0

#221

Post by nimmer »

orthoxerox wrote: post #91
nfrankel wrote: post #20

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

It occupies more or less the same space as Go: it produces fast standalone binaries with garbage collection. However, unlike Go, it isn't shy to give more features to the programmer to play with. The cons are its lack of enterprise backing, its smaller community and its syntax, if you don't like either Pascal or Python.

No: you can create system libraries in Nim, unlike Go.

You can also entirely disable the GC or replace implementation.

Nim can run without OS and on microcontrollers.

Re: Nim 1.0

#222

Post by squarefoot »

nimmer wrote: post #182
neverartful wrote: post #112

Earlier quoted context omitted.

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…

There are many other benchmarks around where Nim is usually quite close to C. Perhaps Nim was not compiled in release mode.

or possibly was a line-to-line translation of the original test without using any peculiarities of Nim.

Re: Nim 1.0

#223

Post by mwcampbell »

leorize wrote: post #140
mwcampbell wrote: post #116

I noticed that Araq's personal post about v1.0 mentioned a powerful macro system as a top priority. I wonder if Nim's macro system is now expressive enough that a front-end web framework like Svelte [1] could be implemented using Nim macros, as opposed to Svelte's HTML template language and custom compiler. COuld be useful for developing isomorphic web apps with something lighter than Node on the server side. [1]: ht…

I think this is what you're looking for: https://github.com/pragmagic/karax

Not quite. Karax has a virtual DOM, and Svelte's creator argues that this is pure overhead [1].

[1]: https://svelte.dev/blog/virtual-dom-is-pure-overhead

Re: Nim 1.0

#224

Post by narimiran »

egeozcan wrote: post #215
_0ffh wrote: post #95

Earlier quoted context omitted.

For me, personally, the biggest points for Nim are: - "Transpiled" to C, with some options regarding runtime library, which means you can target any uController out there - Good metaprogramming support - Static and _strong_ typing - Consequently, precise type aware function dispatch - Type inference - Good generics Also, more stuff like covariants and contravariants and... maybe you just have a look-see? ;-)

There are "concepts" which are like generics but still experimental. Are there any other generic programming facilities in nim? https://nim-lang.org/docs/manual_experimental.html#concepts

> Are there any other generic programming facilities in nim?

https://nim-lang.org/docs/manual.html#generics

Re: Nim 1.0

#225

Post by squarefoot »

jhbadger wrote: post #173
wiz21c wrote: post #163

Why Nim ? As someone who put a lot of efforts in some personal project and understands what it takes to build a new language, I wonder why did the Nim's authors did it in the first place ? Just for the sake of it ? To make money ? For the fun ? I'd like to know (as Nim doesn't seem to be backed by big dollars)

Basically it is a compiled language that feels like a scripting language -- typically compiled languages have so much boilerplate code -- but Nim doesn't. If you just looked at a Nim program, you might even think it is in some scripting language you haven't seen before. I see Nim and Crystal filling a similar niche -- Nim feels more like Python and Crystal more like Ruby.

"Nim feels more like Python and Crystal more like Ruby"

Agreed. To me Crystal is a bit easier to grasp because I already used Ruby a long ago, but it has the non trivial disadvantage of being bootstrapped (ie, it requires itself to compile itself) so that it is slower to port to different architectures.

Re: Nim 1.0

#226

Post by littlestymaar »

uryga wrote: post #210
ptx wrote: post #76

Earlier quoted context omitted.

I don't quite understand the definition of "memory safety" in that document. If deallocation can cause other objects to end up pointing to the wrong thing and the wrong data, how is that different from memory corruption? If your filesystem suddenly starts returning the contents of notepad.exe when asked for user32.dll and vice versa, is that not filesystem corruption? If an admin user object can suddenly start pointi…

i guess the argument is that you'll never read random garbage instead of a well-formed object; and given that random garbage could result in pretty much arbitrary "undefined behavior", it should at least guarantee that your program will behave roughly as intended, even if giving incorrect results (i'm not convinced that's a useful thing myself)

> and given that random garbage could result in pretty much arbitrary "undefined behavior"

Nitpick: UB doesn't come from reading random garbage, it's quite the opposite: UB could result in reading random garbage, but it could also result in many worse things.

Re: Nim 1.0

#227

Post by narimiran »

fithisux wrote: post #202

While Nim is a much better python, you cannot use python modules with Nim (pushing strings to a python interpreter does not count as such), so you need some man-years to build a reasonable software collection. Haxe had another approach. Create a library and transpile it to be used with Lua/Python/ Java and other options.

Have you seen Nimpy[0]?

It allows for a nice integration between Nim and Python. At least for the examples I have tried, it could be used in place of Cython, when there's a need for extra speed in some hot loops and similar situations.

[0] https://github.com/yglukhov/nimpy

Re: Nim 1.0

#228

Post by mumblemumble »

stakhanov wrote: post #162
peteforde wrote: post #150

Earlier quoted context omitted.

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

Well: Nim is similar to Python in many respects, it's just not "C-flavored Python". It has significant whitespace like Python. But since it has a lot of language constructs that are different from Python, it's a bit tedious to try to otherwise compare the syntax a great deal, and it has many elements to its syntax that are quite unique. Saying that Nim is statically typed whereas Python is dynamically typed is exactl…

I'm not sure I should be getting involved, here, but I haven't had my morning tea yet, so what the hey --

It seems like you're hyper-focused on a rather skewed interpretation of my first sentence, to the point that you largely ignore the second sentence. Or at least you seem to ignore everything after the word "but", which, given what the word "but" is often used for, is a rhetorical move that has a way of enabling interpretations that tend to be close to the opposite of whatever was originally intended.

Parent poster has it right. I picked that initial comparison to Python by way of introducing one of the more popular summarizations of Nim, so that I could say why I don't think it's a good summary. If I didn't put it emphatically enough to satisfy you, I apologize. I apparently don't have anywhere near as strong of feelings on the subject; Nim's just a language I like to program in sometimes.

Re: Nim 1.0

#229

Post by Phillips126 »

peteforde wrote: post #211
galangalalgol wrote: post #201

Earlier quoted context omitted.

Also nim came first, also, rust and go aren't even targeting the same use cases. Rust is for performant systems coding or webasm with far fewer footguns than c or c++. Go is for back end software with less cruft or boilerplate or latency than java but about the same throughput as java. It sounds like nim is "i just wan to get this working but I'm worried python wont run fast enough."

Okay, but you're ignoring the thrust of my question, which is "why do I care". Your name is nimmer so it's safe to say we understand why you care, but help me understand why I care about the 3rd-runner: https://trends.google.com/trends/explore?geo=US&q=%2Fm%2F09g... I'm only comparing it to those languages because of the direct comparisons many others have many in this thread. And popularity != quality, but age is al…

Had Nim been developed by or had funding from a large company (Google, Mozilla) I'm sure that chart would be much different. Instead, Nim is built by a group of volunteers contributing to a language they love.

I am not a contributor, but I also quickly fell in love with the language. I felt incredibly productive and being able to build tiny binaries that were cross platform was awesome compared to my old Golang binaries which tend to be heavy (bundling everything into a single binary). Also coming from a web background with little system/application programming knowledge I was able to pick it up really quick. It really is a "better python" in my opinion. The language is incredibly easy to read and write, has really good JSON support (which is a big plus for me) and is incredibly fast. To add more reasons to try, Visual Studio Code has a really good plugin for the language.

Re: Nim 1.0

#230

Post by galangalalgol »

peteforde wrote: post #211
galangalalgol wrote: post #201

Earlier quoted context omitted.

Also nim came first, also, rust and go aren't even targeting the same use cases. Rust is for performant systems coding or webasm with far fewer footguns than c or c++. Go is for back end software with less cruft or boilerplate or latency than java but about the same throughput as java. It sounds like nim is "i just wan to get this working but I'm worried python wont run fast enough."

Okay, but you're ignoring the thrust of my question, which is "why do I care". Your name is nimmer so it's safe to say we understand why you care, but help me understand why I care about the 3rd-runner: https://trends.google.com/trends/explore?geo=US&q=%2Fm%2F09g... I'm only comparing it to those languages because of the direct comparisons many others have many in this thread. And popularity != quality, but age is al…

Nimmer was the parent. I actually like rust more. Though all three are distant in popularity to java or python, so popularity is probably not going to be the distinguishing characteristic between them. The reason i chimed in is precisely because people keep directly comparing rust and go and they ar all horribly misguided. Sure, you vould write a web backend in rust (or just the slow bits like dropbox did) but you do it because go turned out to be too slow, not because that is a primary use case for rust. And while you could probably write drivers in go, why?
Post reply on HN