13 ms·

Nim in 2020: A Short Recap

189 points by leandot 6y ago

pizza234 6y ago
Very interesting. Is the memory model essentially a middle ground between GC-based and manual memory management?: > Scope-based memory management (destructors are injected after the scope) - generally reduces RAM usage of the programs and improves performance. How does Nim handle references? How similar is this to Rust's lifetimes GC-ed instead of manually managed? Is this essentially like Rust, with the main difference that lifetimes (references) are handled via reference counting? > Shared heap - different threads have access to the same memory and you don’t need to copy variables to pass them between threads - you can instead move them I think this is the same as Rust thread move semantics?
- ampdepolymerase 6y ago
  Swift
- planetis 6y ago
  Previous discussion: https://news.ycombinator.com/item?id=25345770 https://news.ycombinator.com/item?id=25345770
- didibus 6y ago
  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 infer that even though a reference is passed to something else, if it can tell that it isn't used afterwards from the previous place, instead of copying the data, it will share it, bit since it's not used by the previous owner you can think of it as moving it rather then sharing it. If Nim can't be sure this is the case or sees it isn't, then data will be copied. That's what I understood at least. So ya, it does look like some kind of hybrid between statically inferable ownership semantics, reference counting, ARC and GC.
  - k__ 6y ago
    So if I understand that correctly: Nim will try to do a light version of Rust's borrow checking and then gradually move from static to dynamic solutions for memory management. I read that Nim's GC is optional, does this mean it can be deactivated and when the static memory management fails, I can do it manually for the edge cases that would otherwise done by the GC? Hope this makes sense, haha.
    - beagle3 6y ago
      > does this mean it can be deactivated? Sort of. You either deactivate it completely with --gc:none ; or, you do it on per-variable basis by using a "ptr" (pointer) type, which is outside of the GC's realm. Any variable declared "ref" (reference) is within the realm of Nim's GC, and will be tracked by the gc you chose (none, boehm, mark&sweep, arc, orc, ...). Additionally, you can define type bound operators to help the GC do its job, but IIRC (and I'm not sure I understand correctly), that doesn't turn off arc/orc - rather, it tells them how to apply some things.
    - didibus 6y ago
      > So if I understand that correctly: Nim will try to do a light version of Rust's borrow checking and then gradually move from static to dynamic solutions for memory management I think that's an okay way to put it. Though it might be best to think of it the other way around. It'll default to GC and copying data around (pass by value) and will try to optimize things if it can to more deterministic memory management and pass by reference. > I read that Nim's GC is optional, does this mean it can be deactivated and when the static memory management fails, I can do it manually for the edge cases that would otherwise done by the GC? It isn't optional like that. It's more that by default all data is passed by value and allocated on the stack. And if you want to create things on the heap, you need to be explicit about it, at which point you can choose if you want the pointer to be managed by Nim's GC or manually. That's done by having two type of pointers, ref will be under GC, and ptr won't.
      - pjmlp 6y ago
        Which in the Cedar/Oberon/Modula-2+/3 family is known as REF and UNTRACED REF.
- pjmlp 6y ago
  Reference counting with cycle collectors is a well known algorithm, nothing new. Environments like Mesa/Cedar at Xerox PARC already made use of it, back in 1985. https://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/parc/techReports/CSL-84-7_On_Adding_Garbage_Collection_and_Runtime_Types_to_a_Strongly-Typed_Statically-Checked_Concurrent_Language.pdf https://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/parc...
  - planetis 6y ago
    (I can't see the link, its offline) the difference is though, there is no expensive heap scans. That is new (it's called "trial deletion", see the Bacon paper) and makes it "deterministic" due to that, independently from the heap size and suitable for hard real-time systems https://nim-lang.org/blog/2020/12/08/introducing-orc.html https://nim-lang.org/blog/2020/12/08/introducing-orc.html
    - pjmlp 6y ago
      Here is a working link from archive.org https://archive.org/details/bitsavers_xeroxparctddingGarbageCollectionandRuntimeTypestoa_1765837 https://archive.org/details/bitsavers_xeroxparctddingGarbage...
- nimmer 6y ago
  Nim has multiple memory management strategies with very different trade-offs. ORC provides performance comparable to Rust but without having to write the boilerplate. https://nim-lang.github.io/Nim/gc https://nim-lang.github.io/Nim/gc https://nim-lang.org/blog/2020/12/08/introducing-orc.html https://nim-lang.org/blog/2020/12/08/introducing-orc.html
leandot 6y ago
In what cases is Nim a better option than Rust? Would be great if anyone with more experience can share more information.
- jononor 6y ago
  The relative simplicity of the language is a feature. I can imagine introducing Nim to embedded/microcontroller firmware developers that only know/use C99 now. I cannot imagine introducing Rust - while a great language, it is C++ level complexity - and that is not always warranted.
  - elcritch 6y ago
    Nim fits great on microcontrollers! Benefit is that it compiles to C and therefore can run anywhere C can. It also lets you reuse all the rest of the embedded C environment and build tools, which given the nature of embedded toolchains is handy for hitting the ground running. Rust's standard library/runtime binaries are really heavy compared to Nim's.
    - weitzj 6y ago
      How are your esp32 Nim deployments holding up? Do you have futur plans for the new esp32 riscv processors?
      - elcritch 6y ago
        > 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 Nim, but it's a resilient system design. If the same were to happen to Rust or Crystal, for example, you'd have issues keeping the compiler up to date with LLVM, etc. Compiling to C gives a lot of stability for embedded work. Sort of similar to how Delphi Pascal is still useable today. One surprise came when I had to do some optimizations and went from `-d:debug` to `-d:release`. The debug code added enough overhead it fixed some timing issues with the high end ADC we're using. Moving to release mode made it too fast and required adding the required delay (it was in the ADC datasheet but forgot it). Easy to solve, but it's worth noting. > Do you have futur plans for the new esp32 riscv processors? If a risc-v processor supports C, then it already supports Nim! The real question is libraries and/or build support for the target. An afternoon of work can get the Nim build setup to work with almost any C/C++ build system. Really, Nim on risc-v just requires a target board and someone to sit down for a few hours. It's a fun "hacking exercise" :-) As a side tangent, I'd like to make a first class "pure" FreeRTOS library as it's the most widely used RTOS. That's after dealing with a lot of annoying race conditions in the `esp-idf` and seeing the incredible amount of hacky C code in embedded systems. Building on FreeRTOS but introducing esp32-like libraries for vfat/files/networking/etc that'd work across microcontrollers would make for an incredibly productive environment (for embedded work). There's also the possibility of using DrNim [1] to add formal verification for certain algorithms! Nim's effect system is very flexible. Really useful would be using the "guards and locks" [2] to write and prevent deadlocks (and maybe avoid locks?) when writing resource management and device drivers. A lot of the esp-idf issue I've run into are race conditions or slow speed since even `echo`/`printf` must have a lock to protect the system UART. Those are open questions/problems, and I'm starting a new job next month so it depends on what the needs there end up being. 1: https://nim-lang.org/docs/drnim.html https://nim-lang.org/docs/drnim.html 2: https://nim-lang.org/docs/manual_experimental.html#guards-and-locks https://nim-lang.org/docs/manual_experimental.html#guards-an...
runald 6y ago
Too bad nim uses a whitespace-sensitive syntax like python, something I personally dislike.
- echelon 6y ago
  You're free to use Golang or another language. Nim has a great feature set and will be a good fit for Python or Ruby teams wanting a more performant language. At the same time, it's more expressive than Golang and will fill a niche Golang couldn't meet. I like that we now have Golang, Rust, Swift, Nim, and Kotlin. They're all doing new things and excelling at their own niches.
  - gideon13 6y ago
    Zig?
  - pjmlp 6y ago
    Best of all, they also provided that required punch in the Java and .NET design room to force them to revisit not having a proper AOT toolchain available since version 1.0.
  - runald 6y ago
    I already use golang for work, and now I'm just doing a little toy project in nim. What I like most about nim is that it has generics, and produces binaries with small size. I'm creating a graphical program with a http server running in the background, and mixing asynchttp with UI threads is a bit of a pain in the posterior. Granted, I'm new to the language, I'm considering using channels, maybe that will make it easier to share state between threads. At least compared to golang, nim hasn't been a smooth experience yet when it comes to threads. Anyways, I'm just voicing my personal gripe with the use of whitespace-sensitive syntax. Nim is a overall a good language to use.
    - dom96 6y ago
      > I'm creating a graphical program with a http server running in the background, and mixing asynchttp with UI threads is a bit of a pain in the posterior. Granted, I'm new to the language, I'm considering using channels, maybe that will make it easier to share state between threads. Ideally you shouldn't need to use UI threads and instead integrate the async loop into the UI's event loop or vice versa. Happy to advise more if you can let me know which UI framework you are using :) This being said, I am hoping to implement better support for using `spawn` and channels with async, i.e. the ability to await the result of `spawn` or a channel. I think that will make a lot of use cases much easier.
rattray 6y ago
Wow, 35% growth in the package ecosystem is a great sign!
zubspace 6y ago
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 VSCode (through gdb behind the scenes). But most of the time I had to fall back to simple "echo" debugging because names were sometimes mangled, variables were not displayed or lines in nim did not correspond with lines in the final output, making debugging a chore. Unfortunately someone once started to write an embedded debugger (ENDB) for all platforms, but development stopped. What's your opinion on this? In some way I would love to use Nim more in the future, but I'm afraid, that the larger the codebase gets, the more I'd suffer just because of debugging... [1] https://nim-lang.org/docs/tut1.html https://nim-lang.org/docs/tut1.html
- inbx0 6y ago
  I'm wondering if the JS compile target could be used for debugging, at least in cases where it's the general logic of the app you want to debug and not some native code -specific bug. JS already has pretty good debugger story for VSCode & other editors, that has been tried and tested with other languages that compile to JavaScript. If Nim can output good source maps, the JS debuggers should pretty much just work.
  - longstation 6y ago
    I think this is a very good idea but it may depend on what you are doing. For example, if you are using Nim to talk to some C library, I believe you won't be able to compile the C part into JS for debugging (even if you are not debugging the C part of course).
- planetis 6y ago
  Ah debugging is very simple, just call `writeStacktrace()` (I assume you can guess what it does) It's great!
- mattarm 6y ago
O_H_E 6y ago
A 2021 community survey is available at the end of the page if you want to be off help to the team or voice some opinion.
doteka 6y ago
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 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 about a conference talk from Facebook, who are arguably running the largest web application in the world, regardless what you think about Facebook. Such a lack of humility does not instill confidence in project leadership.
- adenozine 6y ago
  Well, offer up your language of choice, and I'm sure we could work together to find some online comments to assassinate the creators' character. Perhaps instead of trying to drag someone in a public forum you should've reached out to him and brought it to his attention. Gitter is an IRC-esque platform, it's not exactly designed for deep academic discussions and thoughtful prose, it's a chatroom. Also, since you've seen fit to bring up Facebook's project leadership, perhaps you should look at the MANY failings of theirs. Cambridge Analytica is only the most notorious, there are thousands of cases of injustice done for users. For a brand operating behind a mission of "connecting the world," they sure are disconnected from serving some of their users. Facebook runs an impressive ship, sure. They are worthy of much less of my respect than Araq. I've written <1000 lines of Nim, so I'm no expert, but anybody can see that it's his pride and joy. I applaud him for remaining human. Grow up.
  - doteka 6y ago
    That would be a great argument, except I didn't start out with the intention of assassinating anyone's character. The above thread is literally the 3rd search result for "Karax state management". You know, a very reasonable search query when someone's trying to determine whether a frontend framework is ready for production use. This does not bode well. > Well, offer up your language of choice, and I'm sure we could work together to find some online comments to assassinate the creators' character. Yeah, okay, let's play that game: you asked for it. Let's try to search for "Reagent state management", also the foremost frontend framework for a relatively obscure language (Clojurescript). I guarantee you will not find Rich Hickey making an ass of himself on the first page of results. I'm fairly certain you won't find it in the results at all, because he is more mature than that. Let's try again for Scala.js: "Slinky state management". Again, no sign of Martin Odersky acting like an immature jackass anywhere in the search results. Words matter. First impressions matter. If you don't realize that I'm afraid you are in need of growing up yourself.
filipeclduarte 6y ago
Excellent language! I’m using it for scientific computing and like it a lot. There are a few but useful and good libraries. Arraymancer,ggplotnim, alea and stats. Also, great Python integration nimpy library.

189 points by leandot 6y ago

Very interesting. Is the memory model essentially a middle ground between GC-based and manual memory management?: > Scope-based memory management (destructors are injected after the scope) - generally reduces RAM usage of the programs and improves performance. How does Nim handle references? How similar is this to Rust's lifetimes GC-ed instead of manually managed? Is this essentially like Rust, with the main difference that lifetimes (references) are handled via reference counting? > Shared heap - different threads have access to the same memory and you don’t need to copy variables to pass them between threads - you can instead move them I think this is the same as Rust thread move semantics?

ampdepolymerase 6y ago
Swift
planetis 6y ago
Previous discussion: https://news.ycombinator.com/item?id=25345770 https://news.ycombinator.com/item?id=25345770
didibus 6y ago
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 infer that even though a reference is passed to something else, if it can tell that it isn't used afterwards from the previous place, instead of copying the data, it will share it, bit since it's not used by the previous owner you can think of it as moving it rather then sharing it. If Nim can't be sure this is the case or sees it isn't, then data will be copied. That's what I understood at least. So ya, it does look like some kind of hybrid between statically inferable ownership semantics, reference counting, ARC and GC.
- k__ 6y ago
  So if I understand that correctly: Nim will try to do a light version of Rust's borrow checking and then gradually move from static to dynamic solutions for memory management. I read that Nim's GC is optional, does this mean it can be deactivated and when the static memory management fails, I can do it manually for the edge cases that would otherwise done by the GC? Hope this makes sense, haha.
  - beagle3 6y ago
    > does this mean it can be deactivated? Sort of. You either deactivate it completely with --gc:none ; or, you do it on per-variable basis by using a "ptr" (pointer) type, which is outside of the GC's realm. Any variable declared "ref" (reference) is within the realm of Nim's GC, and will be tracked by the gc you chose (none, boehm, mark&sweep, arc, orc, ...). Additionally, you can define type bound operators to help the GC do its job, but IIRC (and I'm not sure I understand correctly), that doesn't turn off arc/orc - rather, it tells them how to apply some things.
  - didibus 6y ago
    > So if I understand that correctly: Nim will try to do a light version of Rust's borrow checking and then gradually move from static to dynamic solutions for memory management I think that's an okay way to put it. Though it might be best to think of it the other way around. It'll default to GC and copying data around (pass by value) and will try to optimize things if it can to more deterministic memory management and pass by reference. > I read that Nim's GC is optional, does this mean it can be deactivated and when the static memory management fails, I can do it manually for the edge cases that would otherwise done by the GC? It isn't optional like that. It's more that by default all data is passed by value and allocated on the stack. And if you want to create things on the heap, you need to be explicit about it, at which point you can choose if you want the pointer to be managed by Nim's GC or manually. That's done by having two type of pointers, ref will be under GC, and ptr won't.
    - pjmlp 6y ago
      Which in the Cedar/Oberon/Modula-2+/3 family is known as REF and UNTRACED REF.
pjmlp 6y ago
Reference counting with cycle collectors is a well known algorithm, nothing new. Environments like Mesa/Cedar at Xerox PARC already made use of it, back in 1985. https://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/parc/techReports/CSL-84-7_On_Adding_Garbage_Collection_and_Runtime_Types_to_a_Strongly-Typed_Statically-Checked_Concurrent_Language.pdf https://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/parc...
- planetis 6y ago
  (I can't see the link, its offline) the difference is though, there is no expensive heap scans. That is new (it's called "trial deletion", see the Bacon paper) and makes it "deterministic" due to that, independently from the heap size and suitable for hard real-time systems https://nim-lang.org/blog/2020/12/08/introducing-orc.html https://nim-lang.org/blog/2020/12/08/introducing-orc.html
  - pjmlp 6y ago
    Here is a working link from archive.org https://archive.org/details/bitsavers_xeroxparctddingGarbageCollectionandRuntimeTypestoa_1765837 https://archive.org/details/bitsavers_xeroxparctddingGarbage...
nimmer 6y ago
Nim has multiple memory management strategies with very different trade-offs. ORC provides performance comparable to Rust but without having to write the boilerplate. https://nim-lang.github.io/Nim/gc https://nim-lang.github.io/Nim/gc https://nim-lang.org/blog/2020/12/08/introducing-orc.html https://nim-lang.org/blog/2020/12/08/introducing-orc.html

leandot 6y ago

In what cases is Nim a better option than Rust? Would be great if anyone with more experience can share more information.

jononor 6y ago
The relative simplicity of the language is a feature. I can imagine introducing Nim to embedded/microcontroller firmware developers that only know/use C99 now. I cannot imagine introducing Rust - while a great language, it is C++ level complexity - and that is not always warranted.
- elcritch 6y ago
  Nim fits great on microcontrollers! Benefit is that it compiles to C and therefore can run anywhere C can. It also lets you reuse all the rest of the embedded C environment and build tools, which given the nature of embedded toolchains is handy for hitting the ground running. Rust's standard library/runtime binaries are really heavy compared to Nim's.
  - weitzj 6y ago
    How are your esp32 Nim deployments holding up? Do you have futur plans for the new esp32 riscv processors?
    - elcritch 6y ago
      > 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 Nim, but it's a resilient system design. If the same were to happen to Rust or Crystal, for example, you'd have issues keeping the compiler up to date with LLVM, etc. Compiling to C gives a lot of stability for embedded work. Sort of similar to how Delphi Pascal is still useable today. One surprise came when I had to do some optimizations and went from `-d:debug` to `-d:release`. The debug code added enough overhead it fixed some timing issues with the high end ADC we're using. Moving to release mode made it too fast and required adding the required delay (it was in the ADC datasheet but forgot it). Easy to solve, but it's worth noting. > Do you have futur plans for the new esp32 riscv processors? If a risc-v processor supports C, then it already supports Nim! The real question is libraries and/or build support for the target. An afternoon of work can get the Nim build setup to work with almost any C/C++ build system. Really, Nim on risc-v just requires a target board and someone to sit down for a few hours. It's a fun "hacking exercise" :-) As a side tangent, I'd like to make a first class "pure" FreeRTOS library as it's the most widely used RTOS. That's after dealing with a lot of annoying race conditions in the `esp-idf` and seeing the incredible amount of hacky C code in embedded systems. Building on FreeRTOS but introducing esp32-like libraries for vfat/files/networking/etc that'd work across microcontrollers would make for an incredibly productive environment (for embedded work). There's also the possibility of using DrNim [1] to add formal verification for certain algorithms! Nim's effect system is very flexible. Really useful would be using the "guards and locks" [2] to write and prevent deadlocks (and maybe avoid locks?) when writing resource management and device drivers. A lot of the esp-idf issue I've run into are race conditions or slow speed since even `echo`/`printf` must have a lock to protect the system UART. Those are open questions/problems, and I'm starting a new job next month so it depends on what the needs there end up being. 1: https://nim-lang.org/docs/drnim.html https://nim-lang.org/docs/drnim.html 2: https://nim-lang.org/docs/manual_experimental.html#guards-and-locks https://nim-lang.org/docs/manual_experimental.html#guards-an...

runald 6y ago

Too bad nim uses a whitespace-sensitive syntax like python, something I personally dislike.

echelon 6y ago
You're free to use Golang or another language. Nim has a great feature set and will be a good fit for Python or Ruby teams wanting a more performant language. At the same time, it's more expressive than Golang and will fill a niche Golang couldn't meet. I like that we now have Golang, Rust, Swift, Nim, and Kotlin. They're all doing new things and excelling at their own niches.
- gideon13 6y ago
  Zig?
- pjmlp 6y ago
  Best of all, they also provided that required punch in the Java and .NET design room to force them to revisit not having a proper AOT toolchain available since version 1.0.
- runald 6y ago
  I already use golang for work, and now I'm just doing a little toy project in nim. What I like most about nim is that it has generics, and produces binaries with small size. I'm creating a graphical program with a http server running in the background, and mixing asynchttp with UI threads is a bit of a pain in the posterior. Granted, I'm new to the language, I'm considering using channels, maybe that will make it easier to share state between threads. At least compared to golang, nim hasn't been a smooth experience yet when it comes to threads. Anyways, I'm just voicing my personal gripe with the use of whitespace-sensitive syntax. Nim is a overall a good language to use.
  - dom96 6y ago
    > I'm creating a graphical program with a http server running in the background, and mixing asynchttp with UI threads is a bit of a pain in the posterior. Granted, I'm new to the language, I'm considering using channels, maybe that will make it easier to share state between threads. Ideally you shouldn't need to use UI threads and instead integrate the async loop into the UI's event loop or vice versa. Happy to advise more if you can let me know which UI framework you are using :) This being said, I am hoping to implement better support for using `spawn` and channels with async, i.e. the ability to await the result of `spawn` or a channel. I think that will make a lot of use cases much easier.

rattray 6y ago

Wow, 35% growth in the package ecosystem is a great sign!

zubspace 6y ago

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 VSCode (through gdb behind the scenes). But most of the time I had to fall back to simple "echo" debugging because names were sometimes mangled, variables were not displayed or lines in nim did not correspond with lines in the final output, making debugging a chore. Unfortunately someone once started to write an embedded debugger (ENDB) for all platforms, but development stopped. What's your opinion on this? In some way I would love to use Nim more in the future, but I'm afraid, that the larger the codebase gets, the more I'd suffer just because of debugging... [1] https://nim-lang.org/docs/tut1.html https://nim-lang.org/docs/tut1.html

inbx0 6y ago
I'm wondering if the JS compile target could be used for debugging, at least in cases where it's the general logic of the app you want to debug and not some native code -specific bug. JS already has pretty good debugger story for VSCode & other editors, that has been tried and tested with other languages that compile to JavaScript. If Nim can output good source maps, the JS debuggers should pretty much just work.
- longstation 6y ago
  I think this is a very good idea but it may depend on what you are doing. For example, if you are using Nim to talk to some C library, I believe you won't be able to compile the C part into JS for debugging (even if you are not debugging the C part of course).
planetis 6y ago
Ah debugging is very simple, just call `writeStacktrace()` (I assume you can guess what it does) It's great!
mattarm 6y ago

O_H_E 6y ago

A 2021 community survey is available at the end of the page if you want to be off help to the team or voice some opinion.

doteka 6y ago

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 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 about a conference talk from Facebook, who are arguably running the largest web application in the world, regardless what you think about Facebook. Such a lack of humility does not instill confidence in project leadership.

adenozine 6y ago
Well, offer up your language of choice, and I'm sure we could work together to find some online comments to assassinate the creators' character. Perhaps instead of trying to drag someone in a public forum you should've reached out to him and brought it to his attention. Gitter is an IRC-esque platform, it's not exactly designed for deep academic discussions and thoughtful prose, it's a chatroom. Also, since you've seen fit to bring up Facebook's project leadership, perhaps you should look at the MANY failings of theirs. Cambridge Analytica is only the most notorious, there are thousands of cases of injustice done for users. For a brand operating behind a mission of "connecting the world," they sure are disconnected from serving some of their users. Facebook runs an impressive ship, sure. They are worthy of much less of my respect than Araq. I've written <1000 lines of Nim, so I'm no expert, but anybody can see that it's his pride and joy. I applaud him for remaining human. Grow up.
- doteka 6y ago
  That would be a great argument, except I didn't start out with the intention of assassinating anyone's character. The above thread is literally the 3rd search result for "Karax state management". You know, a very reasonable search query when someone's trying to determine whether a frontend framework is ready for production use. This does not bode well. > Well, offer up your language of choice, and I'm sure we could work together to find some online comments to assassinate the creators' character. Yeah, okay, let's play that game: you asked for it. Let's try to search for "Reagent state management", also the foremost frontend framework for a relatively obscure language (Clojurescript). I guarantee you will not find Rich Hickey making an ass of himself on the first page of results. I'm fairly certain you won't find it in the results at all, because he is more mature than that. Let's try again for Scala.js: "Slinky state management". Again, no sign of Martin Odersky acting like an immature jackass anywhere in the search results. Words matter. First impressions matter. If you don't realize that I'm afraid you are in need of growing up yourself.

filipeclduarte 6y ago

Excellent language! I’m using it for scientific computing and like it a lot. There are a few but useful and good libraries. Arraymancer,ggplotnim, alea and stats. Also, great Python integration nimpy library.