At work I have 19,435 lines not including blank or comments. Feels great. No issues.
For my active open source stuff, 21,689 no blanks or comments. Feels great. No issues.
My previous language was coffeescript and python. Nim wins:
Nim does have some cons though. My main issues with nim are:
Those are minor issues. I like nim a lot.
My experience in large(r) projects with Nim is very positive. Two things I found particularly helpful are the module system and the "on the fly" documentation. As for compile time I've never had reason to complain but I'm not a speed fanatic; moreover Nim (modularity) allows for simple test builds using 'when isMainModule', so each developer can deliver his code in a state known to compile.
About the only thing to complain about is Nim's "weird" names in the resulting C code because that makes it harder to annotate it for statical analysis. But then it seems that @Araq has plans to build SA capabilities in Nim itself; I'm not sure how soon though.
nimble dependency management, its annoying to have go to github to tag releases all the time, just to make nimble happy.
You don't have to go to GitHub to do this at all. You can do that using git: git tag v0.2.0 && git push --tags
I think Nim is great in any domain. It's cool that you don't need to switch between different languages to do stuff. Templates and macros helps a lot in domain specific areas. It's normal in gamedev to have engine side on C++ and scripting side on C#/Lua/whatever.
Although it's joy to write in Nim and it gives so much freedom ( I'm fine with that ) that it's harder then in C# to follow strict guidlines.
After C# it's looks kinda naive. The biggest issue is that while technically you can hide some parts of the library from user it's inconvenient. There is no internal namespace scope where I can easily separate lib functionality from the users code. Again, Nim is not C#, I understand that, but particulary organization of code in C# feels easier. I spend a lot of time thinking how to organize stuff in Nim ( heck, more time then actually writing the code XD ) This is the biggest issue for me at the moment.
In overall Nim is outstanding for me. All problems are solvable and I look at them as challenges. But I know at least one C# programmer that dropped learning Nim because of last issue I described ( No internal/protected scope )
hello,
In your import module if you don't want an accessible function
()accessible
* ()the same in
HIDEN * = object # ----> accessible
name: string # is not accessible
reftyp: REFTYP # / ALPHA ... SWITCH
text *: string
switch *: bool
but these are not spaces in C ++ terms
Forward declaration of types in C++ is very limited. You can say class T; and even forward declare a function that takes a pointer to the type foo(T*) but not much more. You cannot forward declare class methods, etc. Regarding *.h and *.c files nothing prevent you from having header file foo_h.nim in addition to foo.nim. One can even simulate include guards with const FOO_H=true in foo_h.nim and when defined(FOO_H): in foo.nim.
Regarding the Nim's file scope, I am not sure I understand. Symbols can be exported from modules to the global scope. I know that all these solutions are suboptimal, but they worked in C/C++ land for decades.
Forward declaration of types in C++ is very limited.
It is? I think it just does what it's supposed to do -- say that there's a named type that will be populated later.
even forward declare a function that takes a pointer to the type foo(T*) but not much more.
Forward function declarations in C++ can have parameters of any type, even forward-declared value types that do not have implementations yet.
nothing prevent you from having header file foo_h.nim in addition to foo.nim
foo.nim could not access private fields from foo_h.nim. Also, since you still can't forward declare types, you'd run back into the same problem if foo_h.nim and bar_h.nim needed to be cyclic in any way.
I don't want this to devolve into a C++ vs Nim thing, but C++ definitely has ways to support cyclic references and Nim doesn't. For the record, I do not love the C++ approach (Rust's, for example, is way better), but it gets the job done.
On the circular imports issue, I'm coming from f#, where the lack of circular imports is seen as a feature rather than a bug. It encourages (even forces) a good onion design with the pure code at the centre of the project and the impure code (files/databases/networks) on the periphery.
Given that f# is mainly used for large, complex projects in the finance industry, it's clear that there's no reason why circular dependencies can't be refactored out of a project. It should be all the better for it.
This is well explained here by the admirable Scott Wlaschin:
I checked F# on github, the most popular project has 2.8k stars.
Maybe I'm missing something, I never heard about any production usage of F#, especially in finance industry...
It's quite well known in the finance industry in London. At least one recent survey showed that F# developers have the highest average salary of any language - so you may be missing out on something :-)
It's basically a modern ML with an expressive algebraic type system. It's cross-platform, open source, well documented, funded by Microsoft, included in the default .Net 5 distribution, natively supported in Visual Studio, and interops painlessly with the whole .Net ecosystem, which is why you don't see that many native OS libs.
It was held back in recent times because the team were tied up porting it to Core, but that's been shipped and they have an ambitious roadmap.
It's basically the most practical of the strongly typed functional languages. I can't see much case for OCaml now, and it's far more pragmatic than Haskell.
It's a very nice language and well worth a look. Deserves a far higher profile.