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

201–210 of 308 posts

Re: Nim 1.0

#201

Post by galangalalgol »

nimmer wrote: post #176
peteforde wrote: post #151

Congrats to the Nim team. One thing that is frustrating for anyone hearing about Nim for the first time is that it's really hard to look at what appears to be yet another slightly different take on Rust or Go and intuitively understand why it exists. There is absolutely a grid that can be populated: who started this, is it corporately affiliated, what languages is it similar to, what is the motivation of its creators…

> appears to be yet another slightly different take on Rust or Go Nim is nowhere close to that. Most people describe it as a very fast statically typed Python.

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."

Re: Nim 1.0

#202

Post by fithisux »

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.

Re: Nim 1.0

#203

Post by littlestymaar »

peteforde wrote: post #151

Congrats to the Nim team. One thing that is frustrating for anyone hearing about Nim for the first time is that it's really hard to look at what appears to be yet another slightly different take on Rust or Go and intuitively understand why it exists. There is absolutely a grid that can be populated: who started this, is it corporately affiliated, what languages is it similar to, what is the motivation of its creators…

> most importantly, if we all got in the same room, would I want to hang out with the people excited about this language?

Interesting, I wouldn't even thought someone could consider it a criterium for a language choice. Now I wonder if most people care about it like you do.

Re: Nim 1.0

#204

Post by peteforde »

narimiran wrote: post #164
peteforde wrote: post #151

Congrats to the Nim team. One thing that is frustrating for anyone hearing about Nim for the first time is that it's really hard to look at what appears to be yet another slightly different take on Rust or Go and intuitively understand why it exists. There is absolutely a grid that can be populated: who started this, is it corporately affiliated, what languages is it similar to, what is the motivation of its creators…

> yet another slightly different take on Rust or Go From Wikipedia article of each language: Rust: First appeared July 7, 2010; 9 years ago Go: First appeared November 10, 2009; 9 years ago Nim: First appeared 2008; 11 years ago

While I'm happy to be informed after being clearly misinformed, I promise you that I'm a full-time developer working with reasonably bleeding edge stuff and I've never heard of it before last night.

I'm lucky to have folks here to set me straight. :)

Re: Nim 1.0

#205

Post by marble-drink »

arc776 wrote: post #194
peteforde wrote: post #151

Congrats to the Nim team. One thing that is frustrating for anyone hearing about Nim for the first time is that it's really hard to look at what appears to be yet another slightly different take on Rust or Go and intuitively understand why it exists. There is absolutely a grid that can be populated: who started this, is it corporately affiliated, what languages is it similar to, what is the motivation of its creators…

I would say metaprogramming (and maybe the excellent FFI) is the huge stand-out feature for Nim. However whilst you can compare all these languages and find a particular niche or set of features that sell them, Nim is just good at pretty much everything. I know that sounds pretty bombastic, but you can practically pick any task and know that Nim will let you get there rapidly and performantly. That's it's ultimate st…

Talk of metaprogramming intrigues me. I'd like to hear what a Lisp user makes of it because I find non-Lisp users are usually amazed by any metaprogramming at all and can't be as critical about it.

Re: Nim 1.0

#206

Post by peteforde »

littlestymaar wrote: post #203
peteforde wrote: post #151

Congrats to the Nim team. One thing that is frustrating for anyone hearing about Nim for the first time is that it's really hard to look at what appears to be yet another slightly different take on Rust or Go and intuitively understand why it exists. There is absolutely a grid that can be populated: who started this, is it corporately affiliated, what languages is it similar to, what is the motivation of its creators…

> most importantly, if we all got in the same room, would I want to hang out with the people excited about this language? Interesting, I wouldn't even thought someone could consider it a criterium for a language choice. Now I wonder if most people care about it like you do.

Yes. A thousand times, yes.

https://en.wikipedia.org/wiki/Yukihiro_Matsumoto (see the first paragraph)

A huge part of the reason that people love Ruby even when there's so many Elixirs/Elms/Crystals/a hundred more around is simple: it's a community full of nice, smart, interesting people with varied interests that extend beyond coding.

Re: Nim 1.0

#207

Post by littlestymaar »

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…

> using `func` to declare pure functions and `proc` for others

What's the limit used by Nim in its definition of a “pure function”? Is function that allocate memory considered a impure one? (technically it is, but it really reduces the usefulness of such keyword if it's too restrictive, that why Rust don't have it for instance).

Re: Nim 1.0

#208

Post by kalekold »

The binary sizes that Nim produces are as usual misrepresented. D and C will blow it out of the water. Here's some D code:

    import core.stdc.stdio;

    extern(C) void main()
    {
        printf("Hello, World!\n");
    }
Compile with:

    $ dmd -betterC main.d
    $ ls -h main

    -rwxrwxr-x 1 user group 8.5K Sep 24 12:39 main

Re: Nim 1.0

#209

Post by littlestymaar »

deorder wrote: post #184
neverartful wrote: post #133

Earlier quoted context omitted.

Replying to my own post to provide better formatting of execution times. 1. C++ 0.04 (gcc version 5.4.0) 2. Rust 0.11 (version 1.37.0) 3. Go 0.13 (version 1.12.7) 4. D 0.16 (tied with Pascal) (DMD64 D Compiler v2.073.2-devel) 5. Pascal 0.16 (tied with D) (fpc 3.0.2) 6. C# 0.25 (mono 4.8.1) 7. Nim 0.50 (1.0.0) 8. Kotlin 0.81 (Kotlin version 1.3.50-release-112, JRE 1.8.0_222) 9. Java 0.95 (openjdk version "1.8.0_131")…

I am pretty sure it should be very close to or the same as C++. Ask around on the Nim forum.

And the x2 difference between C++ and Rust looks suspicious too.

Re: Nim 1.0

#210

Post by uryga »

ptx wrote: post #76
perturbation wrote: post #4

Congrats guys!!! This has been much-anticipated and I'm very excited. I personally wish that the owned reference stuff ( https://nim-lang.org/araq/ownedrefs.html ) had been part of 1.0, but I think that at some point shipping 1.0 >> everything else. I've been following (and evangelizing) Nim for a while, this will make it easier to do so.

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)

Post reply on HN