isofruit

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

Actually a really good point! I entirely forgot about Ruby! Though in terms of competition that does still seem less crowded of a field as one where your other contenders are C, C++, Rust (and for application and web-development there's also Go, to some degree also Java and Python)

I only know a hand full of languages so make of that what you will. I came from a python background and hadn't learned a compiled language before, so I wanted to experiment. Tried Rust for quite a while, but found the syntax not clicking with me though a lot of ideas seemed intriguing (pattern matching and Result types). Didn't want to try C/C++ because I wasn't that hard into figuring out how memory works and at the same time was pretty shocked at how C considers types.

That only leaves go after that, which I heard about around the same time as nim. I started out with nim and I liked it enough so I stuck with it.

Why I use it over other languages? I feel like I can express myself in english readable sentences (which gives it the python vibe for me) and at the same time I have static typing, a really nice type system in general and very little chance of crap like nullpointers occurring.

My first ah-ha moment was pretty much 3 hours in when I noticed I could already already write simple stuff and only needed to consult the std lib docs here and there. The second was when I reimplemented a webserver backend that I previously had in Django (not for practical reasons, just to see how fast it could go even very little optimization) and found it performing roughly 2-5 times faster (measured by looking at request response time), despite having optimized Django's ORM to as few queries as physically possible to get the data I needed. (For reference: That's quite surprising given a decent chunk of that time is literally just network latency)

It can be. I would've loved to pick up Rust, the patterns for code structuring etc. that are evolving from it seem interesting to me. But getting the syntax right is just fairly difficult compared to other languages and at some point you just lose your patience. At the same time there's not enough learning material that works for me to dive into the deeper contexts to make it "click" for me.

Contrasting that to my experience with nim, I could get going almost immediately and thus didn't get held up much with the basics, which gave me more time to dive into more interesting concepts that it provides, like templates, compile-time-evaluation (new for me as a pythonista back then), macros etc.. I still got stuck here and there, mind you, but that was for more complex question than "How do I get a config from place X without the compiler yelling at me", and the discord was very helpful for that.

I am looking forward to them supporting distinct DateTime types (basically used-defined clones of the DateTime type with custom behaviour). Currently using the constructor package to do the same thing, but being able to throw out a dependency is always nice.

Given I used to be a python dev myself before I picked up nim and since then have helped out a fair bit of python-folks picking up nim, I'm not sure what that's based on.

The fact that nim doesn't have exactly the same stdlib defined as python (though there's a package for that)? That Araq has said that nim isn't a variation of python?

To be fair, python back then didn't have great competitors in its space. I guess Perl, but from what I still remember from Perl before I dropped it like a hot potato a couple days in, it wasn't particularly great.

Nim does.

To be fair, you can tell your IDE to just turn tabs into spaces and call it a day, that's an issue for all of 5 minutes.

What you can't do is tell your IDE to interpret camel-case as snake-case if you want (or vice versa), just because this package you really need uses camel-case and you want to use snake-case.

Imo it goes beyond that. You have folks from Java etc. coming over with their camel-case as well as python folks with snake-case. Now despite both of them writing in their own styles, their code can interact, because when the java-programmer gives you a `validateObject` procedure from their package, the python developer can just use it as `validate_object`.

Not being forced into other people's style choices is a really nice boon to me.

Given that you tend to use linters in those environments as well and that you can turn it off anyway, I'd disagree on that one. There are other factors that would make me hesitate in a professional environment much more, such as community size and talentpool.

Agree to disagree. I don't want to force my users to use snake-case just because I use camel-case and vice versa.

There's options to turn it off, options to turn it into a warning when you have style issues so you can make them consistent and it prevents similar names that shouldn't exist in the first place by causing compiler errors (if you have is_ok you should not have isOk in the same scope, what are you doing). It is just not a big deal, at all. And as stated, it is not hard to ensure consistency within your codebase by heeding compiler warnings/errors.

I do not have any experience with C++ and thus none about its python interop, which makes it hard for me to compare it to nim's python interop which I do have some experience with.

Given that, I'm curious what bits of C++/python interop are easier.

I'm mostly asking because my experience of nim-python interop consisted of: Compile nim module with nimpy imported. Put compiled nim module somewhere where your python can find it. write `import <Name_of_module>` in the python file Done, you now have access to the exported functions and symbols defined in the nim module.

Is it that C++ wouldn't need any additional imports to make it work that makes it more seamless?

Yeh, that tracks with my experience. I'd imagine nim to be a somewhat nice learning experience if one already is used to python and the indentation. And with nimpy the integration into existing python codebases is pretty smooth sailing.

Full agreement here. My past experience in the bioinformatics field taught me pretty much that "scientists" at large are just as afraid of the terminal as the average person. The science-folks more specialized on informatics typically are folks focusing on being able to use one language. Not use it well, mind you, just able to produce functional, untested code.

Given that, I highly doubt any of them are even aware of languages beyond python and java and maybe they're aware that C and C++ exists but are scary.