Live data from Hacker News

Nim: Scripting Ease in a Compiled Language

junglecoder.com

131–140 of 169 posts

Re: Nim: Scripting Ease in a Compiled Language

#131
post #114

One thing I find annoying about Nim is the case insensitivity [0]. There was no strong reason for this "feature" and literally no mainstream language does it. Moreover it makes code search a pain. [0] https://nim-lang.org/docs/manual.html#lexical-analysis-ident...

It's shocking how people whine about case insensitivity without bothering to try using Nim for a while. Case insensitivity is a feature and it's meant to allow easy interfacing with C. And it also encourages clean code. With other languages you can have variables called "startdate", "start_date" and "startDate" in the same scope leading to bugs - especially when using completion in an editor - and poor readability. I…

Some of us work in regulated industries where coding standards are not strong suggestions but unconditional requirements. Unambiguous names and identifiers precludes the use of Nim as a tool in any of those fields just by an improper design decision. Sounds very bad and completely avoidable to me.

There is a reason old languages were many times case insensitive but not anymore.

Re: Nim: Scripting Ease in a Compiled Language

#132
post #3

Is there anyone using Nim either in side projects or in production that can comment on how they like it? I keep hearing about Nim and it sounds interesting, but I'm not sure I have the mental capacity right now to do a deep dive into the language and build something with it. I'd like to at some point soon though.

I'm using Nim in production since .18 with zero issues. I spent many years in Qt/C++ and was reasonably quick, but not as quick as I was with D. But then, in an evening, from a cold start, using nothing more than the two Nim Tutorial pages that I happened to have cached in my browser (I was away from a network connection) I was able to redesign and reimplement the bulk of my application in Nim that had taken me one w…

I'm curious, what do you use as an alternative to Qt for Nim?

Re: Nim: Scripting Ease in a Compiled Language

#133
post #61

Earlier quoted context omitted.

Right, and that's the point, aside from the fact those 2 are actually different in nim. I see what you are doing there, but that would have been very confusing when I started programming. Question is, should the language enforce you giving your variables a better name, or should convention? I think there are reasonable arguments for both.

But does a language with Python-like syntax really have to try to be so "beginner-friendly" that it enables inconsistent casing? The language itself can't enforce better variable names, at least not this way - Nim doesn't stop me from using "abcd" or "a0, a1, ... a100" as variable names even though it's usually a very bad idea. No, I think a language should help keeping the code consistent in the long term - and havi…

> I think a language should help keeping the code consistent in the long term - and having this strange case insensitivity doesn't help there in my opinion.

Not at all. Style insensitivity encourages good variable naming and there are both formatters and also the simple text completion in editors to guarantee consistency.

Re: Nim: Scripting Ease in a Compiled Language

#134
post #95

How do data scientists feel about Nim? It feels very pythony, but way faster - could be a really cool language for them, similar to what Julia is trying to be. Curious if anyone in a DS role has tried it out. I'm certainly tempted to try it out, I'm sure I'm losing lots of performance in parts of my analytics pipeline due to Python being garbage slow.

I am trying to improve Nim data science ecosystem with https://github.com/mratsim/Arraymancer . I think today the best way to try Nim is for slow Python utilities vi nimpy: https://github.com/yglukhov/nimpy You can also use Nim in Jupyter the following way: https://github.com/apahl/nim_magic My next step would be to improve interop between Arraymancer tensors and Numpy ndarrays.

Very cool work! Thanks for the links.

Re: Nim: Scripting Ease in a Compiled Language

#135
post #47

How do data scientists feel about Nim? It feels very pythony, but way faster - could be a really cool language for them, similar to what Julia is trying to be. Curious if anyone in a DS role has tried it out. I'm certainly tempted to try it out, I'm sure I'm losing lots of performance in parts of my analytics pipeline due to Python being garbage slow.

The options in python to speed up your code are vast without really having to do much, on a fundamental level. My outdated experience with Nimrod told me that it was a tad too opinionated E.g. Everything is a string in dbs is mentioned in the article. It was an interesting language, for me it felt like a stepping stone to something better. But the docs were really bad,

> The options in python to speed up your code are vast without really having to do much

This does not match my experience. The #1 way I see to optimize Python is to not write Python at all, and instead to FFI out.

Re: Nim: Scripting Ease in a Compiled Language

#136
post #3

Is there anyone using Nim either in side projects or in production that can comment on how they like it? I keep hearing about Nim and it sounds interesting, but I'm not sure I have the mental capacity right now to do a deep dive into the language and build something with it. I'd like to at some point soon though.

I use Nim in production. I been using it for more than 1 year in production. I like it. For me, it started out as a faster python that prevents typos. But it has really grown on me. I really like that I can share libs on server (compiling to c) and client side (compiling to plain javascript). Basically any C library is also a Nim library with a tiny wrapper. That's a huge ecosystem! I also like how Nim can integrate…

I'm curious as to which projects you use it in.

Do you use it in Pushbullet?

Re: Nim: Scripting Ease in a Compiled Language

#137
post #131
post #114

Earlier quoted context omitted.

It's shocking how people whine about case insensitivity without bothering to try using Nim for a while. Case insensitivity is a feature and it's meant to allow easy interfacing with C. And it also encourages clean code. With other languages you can have variables called "startdate", "start_date" and "startDate" in the same scope leading to bugs - especially when using completion in an editor - and poor readability. I…

Some of us work in regulated industries where coding standards are not strong suggestions but unconditional requirements. Unambiguous names and identifiers precludes the use of Nim as a tool in any of those fields just by an improper design decision. Sounds very bad and completely avoidable to me. There is a reason old languages were many times case insensitive but not anymore.

I'm confused how unconditional requirements would preclude Nim? If anything, this allows you to use your "house style" internally and still interact with libraries who don't. I haven't used Nim, but I imagine that was the intention because that's when I've had to mix styles in other languages. To keep your own code consistent you just need your own linter/formatter, which if you have a strict style you're probably already doing.

Re: Nim: Scripting Ease in a Compiled Language

#138
post #86

Earlier quoted context omitted.

I use Nim in production. I been using it for more than 1 year in production. I like it. For me, it started out as a faster python that prevents typos. But it has really grown on me. I really like that I can share libs on server (compiling to c) and client side (compiling to plain javascript). Basically any C library is also a Nim library with a tiny wrapper. That's a huge ecosystem! I also like how Nim can integrate…

I have some code duplication between android, iOS and a webapp / PWA. How realistic is it to look at something like nim for codesharing?

Sharing code between Desktop and Mobile still a bit rough. I have done some experiments and it looks promising: https://forum.nim-lang.org/t/5197

Does not appear to be any harder then sharing C or C++ libraries.

Re: Nim: Scripting Ease in a Compiled Language

#139

Earlier quoted context omitted.

Main reason for this feature is that Nim is big as a glue language. Many C/C++ libraries don't have consistent naming conventions between them. I don't want my code to look like a patch work of `__APICALL__(system_call.inspectSomething())` I just want it to look like Nim code: `apiCall(systemCall.inspectSomething())`. This is just a consistent standard on how to turn names in one style into another style backed into…

apiCall = __APICALL__ done

Then you are writing or auto generating these giant 1000s of lines long files with renames... why?

Re: Nim: Scripting Ease in a Compiled Language

#140

I've been considering getting into Nim for a while now as something more lightweight/terse to write thin CLI utilities in. I'm glad to hear that it's performing well for this usecase. It's a very attractive alternative to Rust for it's simplicity and terseness. I still haven't gotten around to picking it up though, these days I just use QuickJS for anything that needs to be reasonably portable and thin. Maybe next si…

Nim is great for knocking out commandline apps, I recommend "cligen" for quick and clean options, or "docopt" for friendlier cli options. They feel "scripty" when you can begin with a couple lines and grow it up from there. I found it the easiest to learn. And difficulties getting my other favorite, D, on embedded and Haiku and OS/2 (which also have poor javascript support) was my prompt to give it a try. I found cross-compiling easy. But just as easy was having Nim installed on all my platforms.
Post reply on HN