Live data from Hacker News

Nim 1.4

nim-lang.org

41–50 of 144 posts

Re: Nim 1.4

#41
I was skeptical towards Nim. Then I wrote a small program that uses SDL2, and compared it to the same program written in over 10 other programming languages. Nim has an excellent combination of ease of use and performance.

Re: Nim 1.4

#42
post #41

I was skeptical towards Nim. Then I wrote a small program that uses SDL2, and compared it to the same program written in over 10 other programming languages. Nim has an excellent combination of ease of use and performance.

Can you output WebAssembly/Emscripten project that uses SDL2?

Re: Nim 1.4

#43
post #17
post #12

I played around with Nim a little and was amazed at how small the executables were: 10s of KB for something simple. Even Rust spits out 100s of KB, or even >1MB by default. In the end I still went with Rust, simply because it's more popular, but my initial impression was that Nim is a really fun language to work in, and much much easier to pick up than Rust.

"and much much easier to pick up than Rust." That's my impression so far, too. Previously, I already had some experiences with C, Pascal, and Python. Then learning Nim just feels natural. Not so much with Rust. Well of course it's not surprising, with memory safety as one of its goals.

>Well of course it's not surprising, with memory safety as one of its goals.

Where is this idea coming from that memory safety has to be complicated? Nearly all languages (basically everything except C/C++/Assembler) people are using are memory safe. And usually it's not complicated at all.

Re: Nim 1.4

#44
post #3

There are a lot of gotchas with the new GC that make me nervous about this release: > As far as we know, ARC works with the complete standard library except for the current implementation of async... That's not a great endorsement... > If your code uses cyclic data structures, or if you’re not sure if your code produces cycles, you need to use --gc:orc and not --gc:arc. Seems like this is a big onus to put on the use…

At an ELI5 level, does anyone know why Swift can have ARC and async but Nim's ARC doesn't work with async? Is it just implementation details of Nim's async specifically instead of anything more fundamental to ARC? Just asking out of curiosity.

Re: Nim 1.4

#45
post #41

I was skeptical towards Nim. Then I wrote a small program that uses SDL2, and compared it to the same program written in over 10 other programming languages. Nim has an excellent combination of ease of use and performance.

Nim is my mistress. I work with Elixir and Javascript, but something about Nim is so pure and exact and precise. I love it.

I'm hoping someone builds a great web framework with it, and a library like Ecto for better postgresql access. This language great potential to build faster software.

Re: Nim 1.4

#46
post #43
post #17

Earlier quoted context omitted.

"and much much easier to pick up than Rust." That's my impression so far, too. Previously, I already had some experiences with C, Pascal, and Python. Then learning Nim just feels natural. Not so much with Rust. Well of course it's not surprising, with memory safety as one of its goals.

>Well of course it's not surprising, with memory safety as one of its goals. Where is this idea coming from that memory safety has to be complicated? Nearly all languages (basically everything except C/C++/Assembler) people are using are memory safe. And usually it's not complicated at all.

Well Rust's complication is memory safety and the lack of garbage collector. You see similar issues in a language like Swift, but Swift lets you create a memory leak very easily if you're not aware of the issues. Which can be fine when you're just starting out, you can always learn about it later. But Rust isn't so charitable: you must learn about memory safety upfront. The plus side is that it's significantly more difficult to accidentally create a memory leak.

Re: Nim 1.4

#47
post #17
post #12

I played around with Nim a little and was amazed at how small the executables were: 10s of KB for something simple. Even Rust spits out 100s of KB, or even >1MB by default. In the end I still went with Rust, simply because it's more popular, but my initial impression was that Nim is a really fun language to work in, and much much easier to pick up than Rust.

"and much much easier to pick up than Rust." That's my impression so far, too. Previously, I already had some experiences with C, Pascal, and Python. Then learning Nim just feels natural. Not so much with Rust. Well of course it's not surprising, with memory safety as one of its goals.

I have never seen anyone say that Rust was easier to pick up than Nim...(Famous last words, I know!)

Re: Nim 1.4

#49

NIM and Red (also on HN today) seem both seem to have an interesting and intersecting feature set. Anybody here used or heavily evaluated both that can comment?

Rebol/Red is more like Python/Cython - able to be fast but falling back to an interpreter for dynamic things. As such there are probably more "performance footguns" (though any such thing is ultimately subjective based on programmer awareness). Nim feels more like what C++ (or Python) should always have been. Not sure if this helps. It's kind of a "big" question.

Re: Nim 1.4

#50
post #42
post #41

I was skeptical towards Nim. Then I wrote a small program that uses SDL2, and compared it to the same program written in over 10 other programming languages. Nim has an excellent combination of ease of use and performance.

Can you output WebAssembly/Emscripten project that uses SDL2?

This seems quite possible from everything I've explored, and also is something I want to try soon. It's also interesting to use Nim through JS for a scripting layer for an application written in Nim; where they both communicate through shared data structures or something.

Here's a repo I found: https://github.com/Jipok/Nim-SDL2-and-Emscripten

Post reply on HN