Mirror of forum.nim-lang.org

5212 :: Tried to learn NIM some feedback

• alexeypetrushin (orginal) [2019-09-23T19:10:34+02:00] view original

  I'm looking for a language that I can use on both server and client, it should be simple, productive and robust (help me with catching errors). I'm currently using TypeScript mostly. Also in past used Ruby (Ruby on Rails) and Java.

  Pluses:

  • Types, even requiring to explicitly dismiss fn() if return is not used, nice.
  • Flexible syntax - everything is expression and ability to use obj.fn(v) or fn(obj, v) and even omit parenthesis - ending up in very clean and nice code.
  • Function override - nice.
  • Constants, even function argument constants - nice.
  • There are some projects written in Nim - nim site using forum written in nim himself.
  • And also many others, nice docs etc. in general - positive impression, looks nice and pleasant to use.

  Minuses:

  • Proc are not dynamically dispatched. Red flag. There are some methods etc. And even for methods you need to supply special command line argument to enable multiple dispatch. Huge red flag. That feels like this (extremely important in my opinion) feature - multiple dispatch is not actively promoted. Also - extra complexity - I should think if I want it to be multiple dispatched or not. Feels too complicated, don't like it.
  • No clean docs about null-safety I don't know if Nim support it or not.
  • Even there are some real projects, like Nim forum, still not much real projects done with Nim.
  • Unclear what's the multicore performance.
  • Extra complexities about pointers. I never used pointers in TypeScript and in Java not sure if they should be mentioned at all in beginner-level tutorials. Maybe it's good for performance but the cost is - simplicity, it adds complexity and I'm not sure if I ever need it.

  So far the impression - feels like Nim trying to find a balance between simplicity and performance. In my personal preferences - I would like to shift it in the side of simplicity. It looks good, but as for me - I never needed advanced performance in the past and probably never need it in the future, so I don't want to sacrifice simplicity for performance I never need.

---

• Araq (orginal) [2019-09-23T19:44:46+02:00] view original

  Thanks for this feedback. However, the issues that you bring up cannot be changed much.

  Proc are not dynamically dispatched.

  Static binding should be the default and many modern languages actually agree on this, see C#, Rust, etc.

  No clean docs about null-safety I don't know if Nim support it or not.

  We have "not nil" annotations but these are still under-developed. We're slowing getting there though.

  Unclear what's the multicore performance.

  It's not any more unclear than what Nim's "single core performance" is. And the very next paragraph you say that you don't care about speed much anyway. ;-)

  Extra complexities about pointers.

  Pointer semantics are the foundation for TypeScript and Java too as they only give you pointers/references to objects. Pointers are also essential for interop with other native languages and for "systems programming". Again, this is not something that can be simplified, even Go makes this distinction.

---

• alexeypetrushin (orginal) [2019-09-23T20:47:19+02:00] view original

  Thanks for the reply. I guessed that most of Nim decisions are probably have good reasons behind.

  Static binding should be the default and many modern languages actually agree on this, see C#, Rust, etc.

  There are system languages and application languages. Rust is a system language and performance has higher priority than simlicity. C# universal, and seems also valuing performance more.

  It's not any more unclear than what Nim's "single core performance" is. And the very next paragraph you say that you don't care about speed much anyway. ;-)

  Ha-ha, you caught me. I don't care about best possible performance, it's ok to be 3-5 times slower than C. But multicore is kinda must nowadays.

  Pointer semantics are the foundation for TypeScript and Java too

  Yes. What I meant is there's no strict distinction between pointers and values. But maybe it's ok, it's just me not being used to that.

---

• juancarlospaco (orginal) [2019-09-23T22:17:07+02:00] view original

  You are not forced to use all the things you mention, for the use case you mention.

  ...at least initially :)

---

• alexeypetrushin (orginal) [2019-09-23T23:16:00+02:00] view original

  By the way, congratulations with the v1 release! Huge work!

---

• mratsim (orginal) [2019-09-24T00:20:44+02:00] view original

  Ha-ha, you caught me. I don't care about best possible performance, it's ok to be 3-5 times slower than C. But multicore is kinda must nowadays.

  Nim is as fast as C, this post has plenty of examples from scientific computing, raytracing and multithreaded runtime: https://forum.nim-lang.org/t/5157#32409.

  Regarding multicore performance as shown by my experiments in Project Picasso, nothing prevents Nim to reach competitive or even better performance than OpenMP or Intel TBB, but it still needs some refactoring to make it production ready.

  Currently you can use:

  • OpenMP, via the || iterator
  • Nim Threads via createThread which are very thin wrapper on top of pthreads or Windows Fibers
  • Nim threadpool which gives you an API similar to async/await with spawn/^
  • A third-party threadpool like https://github.com/yglukhov/threadpools

  Also regarding your feedback in general, unfortunately people comes to Nim with very different backgrounds. Many comes from C or C++ as evidenced by the number of game developers. Static dispatch, stack allocation, control over memory and pointers are very important there.

  Ultimately, the best way forward is to have a "Nim for the Typescript developer" wiki similar to what we have for C, or Python

---

• ffred60 (orginal) [2019-09-24T08:25:17+02:00] view original

  A third-party threadpool like https://github.com/yglukhov/threadpools

  do you really think that newcomers on Nim will be using a package with not even a simple readme file ? when I find something like that on Github, I don't even look at the code or search for anything more, I go away..!

---

• mratsim (orginal) [2019-09-24T12:03:09+02:00] view original

  Fair. The main point is that if you are unhappy with Nim's threading, you can write your own.

---

• juancarlospaco (orginal) [2019-09-24T16:43:51+02:00] view original

  But lots of packages has the Docs built-in as documentation comments, including runnableExamples.

---

• ffred60 (orginal) [2019-09-24T20:32:54+02:00] view original

  But lots of packages has the Docs built-in as documentation comments, including runnableExamples.

  so you think that a simple - even small - readme file telling what the package is or can do is not necessary ? why would I take time to look at the code if there's not even a few words telling me what I could find there.... sorry but more generally in that case there's no more doc inside the code.

---