Live data from Hacker News

Nim in 2020: A Short Recap

nim-lang.org

111–120 of 121 posts

Re: Nim in 2020: A Short Recap

#111
post #11

Earlier quoted context omitted.

Seems Nim will do some static analysis where if it can infer a reference is locally scoped in some way, it will deterministically inject a call to the destructor at the end of the scope. If not, it will do reference counting which will also have (if using orc) an extra cycle detection pass so that the references count references can also handle cycles. Finally, Nim will also do some static analysis, and if it can inf…

Refcounted refs have copy and destruct semantics, and then what you're talking about is basically move semantics over those refs. Refcount increments be elided if the ref is "moved." The increment is only needed on copy. Additionally, a moved-from value doesn't need to be destructed (in the case of a refcounted ref -- decrementing the count and deallocating the pointed-at memory if count goes to zero). A talk about s…

> Refcounted refs have copy and destruct semantics

You're talking accross threads I believe. But accros scopes they are passed by reference I believe.

Re: Nim in 2020: A Short Recap

#112

I've used Nin for this years advent-of-code challenge. Never used Nim before but there are some great tutorials [1]. It's a nice language with a great standard library. Implicit static typing is great after a bit of getting used to. Some things like tuples or "Object Variants" are fun to use. The only thing I'm missing is strong debugging support. You can use GDB and there is even some basic support for debugging in…

"The most effective debugging tool is still careful thought, coupled with judiciously placed print statements." - Brian W. Kernighan

https://twitter.com/codewisdom/status/867818359840280576

Sometimes I think if you’re spending too much time in a debugger, you’re already lost. Your program is doing something that you didn’t correctly plan for, or build tolerances to handle gracefully.

And if you’re using a debugger to fiddle with variable manipulation at that level, then you’ll probably just make your program even more unstable.

But granted, sometimes you do need a debugger, when you’re using someone else’s library.

Re: Nim in 2020: A Short Recap

#113
post #95
post #94

Earlier quoted context omitted.

> There really is a lot more to Nim than just this I've actually just been skimming some tutorials and docs, and wow, you're not wrong! I'm impressed - Nim seems to be rammed with features, but also easy to get started with (as long as you ignore some of the more advanced stuff). I've recently been trying to find time and motivation to start learning Rust, but I have to say that (even with horrible indentation syntax…

If a little CLI app to do something useful (instead of say, some shell script/batch file or something) is your entry point then you might try cligen [1]. Everyone is different, but from many and varied reports (e.g. in this very thread [2]), it is hugely more probable that you get up & running with some basic skills in like 30 minutes to 4 hours or so with Nim than you would with Rust. Nim really seems to "scale up g…

Nim’s available argument parser library needs some more maturity, as compared to Python.

Python has a great argparse library, and it would be good if Nim could emulate that.

Re: Nim in 2020: A Short Recap

#114
post #92

Earlier quoted context omitted.

> the lack of explicit start/end markers for code blocks is a very unfortunate choice. > It was a bold choice by Python, but in my experience it turned out to be a poor choice Could you explain why? I've heavily used languages with explicit block delimiters as well as Python, in collaborative environments, and the significant whitespace in Python does not really cause me any trouble. There is some slight overhead of…

Just to give a bit of context, I've been programming for almost 30 years, using many different languages. I've worked on many things, but of particular relevance I was part of a small team for several years which amongst other things had a 100kloc Python project that I did significant work on. I continue to use Python for all sorts of smaller projects, and for the most part enjoy it a lot. I've worked on large C++ co…

Thanks a lot for explaining your perspective. It's interesting to me, since all the things you mention are not part of my experience at all, despite working with Python a lot. Even diffing, as you said, is easy because of the "ignore whitespace" you mention. Anyway, it's good for me to get a reminder that I can't so easily generalize from myself. :)

Re: Nim in 2020: A Short Recap

#115
post #77

I've used Nin for this years advent-of-code challenge. Never used Nim before but there are some great tutorials [1]. It's a nice language with a great standard library. Implicit static typing is great after a bit of getting used to. Some things like tuples or "Object Variants" are fun to use. The only thing I'm missing is strong debugging support. You can use GDB and there is even some basic support for debugging in…

I wouldn't consider interactive step debugging an essential feature in large programs. My experience with C++ is that once program becomes "large" or makes enough use of threads, gdb falls over anyway and you're stuck with logging and "print" debugging anyway.

Sorry but that is just more an example of lack of knowledge of gdb capabilities than anything else.

Not only there are graphical frontends that provide that kind of information, gdb supports scripting and tracepoints.

Re: Nim in 2020: A Short Recap

#116
post #95

Earlier quoted context omitted.

If a little CLI app to do something useful (instead of say, some shell script/batch file or something) is your entry point then you might try cligen [1]. Everyone is different, but from many and varied reports (e.g. in this very thread [2]), it is hugely more probable that you get up & running with some basic skills in like 30 minutes to 4 hours or so with Nim than you would with Rust. Nim really seems to "scale up g…

Nim’s available argument parser library needs some more maturity, as compared to Python. Python has a great argparse library, and it would be good if Nim could emulate that.

Well, cligen is pretty mature/featureful, less work to use and well maintained and is the most common recommendation in Nim. If you happen to like more verbosely specified CLI interfaces like Python's argparse there are at least two pretty close to the Python argparse -- therapist [1] and nim-argparse [2]. There is much more to any programming language than its stdlib. { If you find these insufficiently "drop-in compatible", well, you can write your own port of argparse.py that is closer. :-) That is probably a good exercise. }

[1] https://maxgrenderjones.bitbucket.io/therapist/latest/therap...

[2] https://www.iffycan.com/nim-argparse/argparse.html

Re: Nim in 2020: A Short Recap

#117
post #116

Earlier quoted context omitted.

Nim’s available argument parser library needs some more maturity, as compared to Python. Python has a great argparse library, and it would be good if Nim could emulate that.

Well, cligen is pretty mature/featureful, less work to use and well maintained and is the most common recommendation in Nim. If you happen to like more verbosely specified CLI interfaces like Python's argparse there are at least two pretty close to the Python argparse -- therapist [1] and nim-argparse [2]. There is much more to any programming language than its stdlib. { If you find these insufficiently "drop-in comp…

I did entertain that idea. But it would’ve detracted my efforts from my actual goal.

therapist looks interesting. I’ll take a look at this. Thanks.

Re: Nim in 2020: A Short Recap

#118
post #86

Earlier quoted context omitted.

How are your esp32 Nim deployments holding up? Do you have futur plans for the new esp32 riscv processors?

> How are your esp32 Nim deployments holding up? They're doing great! Nim has proven surprisingly stable, which was a fear I had at first. The core team has improved compiler support and I've not run into any issues updating so far. It bolster's my confidence in Nim. Even if Nim development were to suddenly "stop" tomorrow, it'd easily be useable for embedded for a decade or more. There's improvement to be made in Ni…

That’s very insightful. Thank you. Some more questions since you are the person which shows up for esp32 and nim in the whole wide world :)

Did you try out the esp-idf 4.3 release yet? I think you mentioned somewhere to not use 4.2. but 4.3 gives you the esp-managed Mqtt service on Aws (rainmaker)

Do you have any thoughts on Freertos vs Zephyr whilst using Nim?

Re: Nim in 2020: A Short Recap

#119
post #118

Earlier quoted context omitted.

> How are your esp32 Nim deployments holding up? They're doing great! Nim has proven surprisingly stable, which was a fear I had at first. The core team has improved compiler support and I've not run into any issues updating so far. It bolster's my confidence in Nim. Even if Nim development were to suddenly "stop" tomorrow, it'd easily be useable for embedded for a decade or more. There's improvement to be made in Ni…

That’s very insightful. Thank you. Some more questions since you are the person which shows up for esp32 and nim in the whole wide world :) Did you try out the esp-idf 4.3 release yet? I think you mentioned somewhere to not use 4.2. but 4.3 gives you the esp-managed Mqtt service on Aws (rainmaker) Do you have any thoughts on Freertos vs Zephyr whilst using Nim?

> That’s very insightful. Thank you. Some more questions since you are the person which shows up for esp32 and nim in the whole wide world :)

You're welcome. lol, no one else did it so there you are.

> Did you try out the esp-idf 4.3 release yet?

No, my work requires stability so I haven't tried any of the new esp-idf releases. Nesper does compile with 4.2 if you pass the flag for it, but it's not well tested. If none of the major API's have changed 4.3 should work.

It would be good to wrap the mqtt aws service. Don't know if I'll have time for it though. But it's really not too hard to wrap using `c2nim` on the header files. PR's welcome! :-)

> Do you have any thoughts on Freertos vs Zephyr whilst using Nim?

I would like to try Zephyr sometime. FreeRTOS is used by AWS and the esp32 so it seemed a good start.

Re: Nim in 2020: A Short Recap

#120
post #73

I’d love to give Nim a shot, but comments like these from the author make sure I’ll never be able to take the language seriously: (Context: gitter thread about frontend state management/immutable data structures, https://gitter.im/nim-lang/Nim?at=59722654bc46472974112028 ) Araq: meh, I cannot watch these hipsters talk Araq: as soon as I hear “business logic” I stop listening He felt compelled to make these comments a…

glad subjects like you are getting filtered by themselves
Post reply on HN