Nim version 2.0.0 release candidate • Hacker News Board

Re: Nim version 2.0.0 release candidate

#111

Post by arc776 » Thu, Dec 22, 2022, 10:53 PM UTC

derbOac wrote: post #34

nicoburns wrote: post #24

Earlier quoted context omitted.

I think I agree with Carmack on this. I'm hyper aware of case now, but this was probably the major cause of errors for me when learning (didn't help that tooling was less good then, so there were no linters pointing out my errors).

I guess for me it's one of those things I got tripped up on initially but came to appreciate later. It taught me how to be more precise about characters and reasoning about them in code. There's also cases where case sensitivity should matter in naming in my experience, and it's not possible without it.

> There's also cases where case sensitivity should matter in naming in my experience, and it's not possible without it.

I'm really curious, do you have any examples? I can't think of any that wouldn't be better served by using the type system.

Re: Nim version 2.0.0 release candidate

#112

Post by kaba0 » Thu, Dec 22, 2022, 10:58 PM UTC

mikedelago wrote: post #96

zozbot234 wrote: post #16

Earlier quoted context omitted.

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

Or you know, types. Or too much expressivity.

Re: Nim version 2.0.0 release candidate

#113

Post by moigagoo » Fri, Dec 23, 2022, 4:37 AM UTC

isofruit wrote: post #98

moigagoo wrote: post #92

Earlier quoted context omitted.

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

I'd just save a snippet to a file and wait a second for nimsuggest to highlight the errors :-)

Re: Nim version 2.0.0 release candidate

#114

Post by pyinstallwoes » Fri, Dec 23, 2022, 10:55 PM UTC

arc776 wrote: post #107

pyinstallwoes wrote: post #88

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

I'm a full time Nim developer and have been for over half a decade. It's completely spoiled me for other languages, it is just ridiculously productive. Rather than an ah-ha moment, it was more a gradual transition from "where's the catch?" to "there's no catch!". The simple answer is this: anything I want to do, I can do in Nim easier than other languages, while also having direct access to C/C++/JS ecosystems as wel…

Thank you for your thoughtful reply. Is it fair to say that Nim and Dart share similar mission statements? Any idea of a comparison between the two?

Re: Nim version 2.0.0 release candidate

#115

Post by ReneSac » Fri, Dec 23, 2022, 11:44 PM UTC

posharma wrote: post #38

Are there any products/companies that use Nim in production?

Goodboy Galaxy is a game in development for Game Boy Advance writen in Nim. They did a presentation about coding for GBA in NimConf 2020: https://www.youtube.com/watch?v=sZUM7MhWr88

Re: Nim version 2.0.0 release candidate

#116

Post by ReneSac » Sat, Dec 24, 2022, 12:56 AM UTC

wyldfire wrote: post #15

rayiner wrote: post #9

Nim’s arc and sink/lent annotations seem a lot simpler than Rust’s owned pointers and region annotations. Has anybody had the opportunity to compare the costs and benefits?

> Has anybody had the opportunity to compare the costs and benefits? Heap allocators are very significant cost over stack. Nim's designed for different use cases. Rust statically checks memory usage, and provides Arc for use cases that can only be modeled dynamically.

ARC in Nim does not mean the same thing as in Rust. I'm still not fully up to speed on ARC/ORC nor went very far on Rust, so I might be wrong here, but from what I understand:

In Nim using ARC/ORC the compiler statically checks the memory usage, possibly helped by lent and sink annotations (similar to borrow and lifetime annotations in Rust, but not as powerful yet) and for what can't be proved statically it adds reference counting. And even under ARC you will probably be using stack allocations a lot in Nim.

I think the main difference between Rust and Nim approaches to memory management is opt-in vs opt-out. In Rust you are forced from the start to think about it and be more explicit about it, while in Nim the lifetime annotations are more like optional optimizations that may be added gradually to help the compiler, that might otherwise be adding reference counting and copies behind your back to maintain correctness.

For some use cases, being forced from the start to think in a lower level of abstraction is helpful and makes the performance more predictable and transparent. People still use C partially because of that. But I like Nim's approach where I can use it as productively as an scripting language avoiding premature optimization, but can easily delve as low level as I want to write a keyboard firmware or GBA game.

Re: Nim version 2.0.0 release candidate

#117

Post by ReneSac » Sat, Dec 24, 2022, 3:10 AM UTC

v3ss0n wrote: post #47

synergy20 wrote: post #14

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.

Nim community is pretty much against python developers. The founder is vocal about that.

There is an entire wiki page to welcome developers coming from python, and show where the two languages differ: https://github.com/nim-lang/Nim/wiki/Nim-for-Python-Programm...

Re: Nim version 2.0.0 release candidate

#118

Post by int_19h » Mon, Dec 26, 2022, 2:49 AM UTC

xigoi wrote: post #81

v3ss0n wrote: post #48

Earlier quoted context omitted.

My_function vs myFunction Is fine but do_me vs dome start to differ and do_me vs d_ome vs dom_e start to make things very much different. That's the real problem

Rarely a problem. Why would you have two procedures named do_me and dome with the exact same signature?

Because the other procedure does something with some dome?

Re: Nim version 2.0.0 release candidate

#119

Post by int_19h » Mon, Dec 26, 2022, 2:51 AM UTC

elcritch wrote: post #70

throwaway_au_1 wrote: post #31

Earlier quoted context omitted.

Ironically they reject tabs and require space indentation. Something something the complexity of supporting both. Yet we have style insensitivity..

That actually makes whitespace syntax in Nim much better. Can't recall the number of times I copied Python code snippets and had to track down lurking tabs.

You can't mix tabs and spaces in the same file since Python 3, which completely solves this problem without imposing one or the other choice on the users.

Re: Nim version 2.0.0 release candidate

#120

Post by xigoi » Mon, Dec 26, 2022, 7:33 AM UTC

int_19h wrote: post #118

xigoi wrote: post #81

Earlier quoted context omitted.

Rarely a problem. Why would you have two procedures named do_me and dome with the exact same signature?

Because the other procedure does something with some dome?

Then is should be named doSomethingWithDome.