8 ms·

I absolutely hate Nim for spoiling pretty much all other programming languages for me. I wish it gained more traction. Congratulations on your book and keep up

I absolutely hate Nim for spoiling pretty much all other programming languages for me. I wish it gained more traction. Congratulations on your book and keep up the great work, Araq. You did an outstanding job with Nim and I wish you all the best!

danielvaughn 4y ago
Care to give a brief overview of what you find appealing? I've never looked into the language before.
- davidkunz 4y ago
  Other comments already gave great examples but for me personally: - Concise syntax - Elegant language constructs (e.g. method call syntax) - Great macro system - You have control over what GC you use - Great performance - Everything is simple, it's easy to read other people's code
- frigid 4y ago
  I particularly like, from the syntax side: - Python-style syntax with significant indentation - Uniform Function Call Syntax: a.len() == a.len == len(a) - Fully unqualified imports by default: which might seem scary to Python programmers, but works great in practice because of static typing - All of the above makes code readable and succinct And from a language features side: - Compiles to C with all the architectural targets that come with it - Compilation to C also allows for easy C interop: wrap function signatures and types and you're done - This, in turn, means that Nim libraries can bootstrap off of the massive C ecosystem, while adding nicer APIs on top - Extremely performant GC by default: optional Rust-style annotations can further improve performance, and you can remove all overhead and manually manage memory with C-style pointers if you'd like - Useful compile-time templates and macros that can directly change the AST The community is also active and helpful on IRC/Matrix/Discord/Gitter (bridged together)
  - frigid 4y ago
    One really important thing I forgot to mention is how extendable Nim is - first class support for macros and AST manipulation is very powerful. This cuts back significantly on the amount of functionality that needs compiler magic. So you'll see alternative (or new) implementations of core language features like async, threading, DSLs, typeclasses, traits, etc available as external packages, with just about the same user experience as if they were built into the stdlib or compiler.
  - vegai_ 4y ago
    >- Uniform Function Call Syntax: a.len() == a.len == len(a) a.len() == len(a) seems like a good idea, but I'm not so sure about a.len... Isn't that a bit ambiguous?
pddpro 4y ago
Even Rust?
- winrid 4y ago
  Nim gives you like 85% of the performance of Rust without having to worry about a borrow checker. It also solves concurrency problems via its use of Channels, like Go. So it's just hard to justify using Rust, for me. Unless you're writing a DB or something where a GC is a no go. But Nim's memory management seems pretty good, and many things are stack allocated.
  - elcritch 4y ago
    Its nice being able to go all the way from fully GC reliant cyclic data-types with closures all the way to memory control-freak every byte and microsecond matters by using stack objects and 'var' parameters. Often you can keep 90% of the code and just tweak a few slow points.
  - warangal 4y ago
    Even though Nim by default works with a GC to manage memory, I regularly use Nim to work with direct-memory/raw-pointers and can still have increased memory safety by using HOOKS and ARC. I have written about my experience here[1], in case somebody is curious. 1. https://ramanlabs.in/static/blog/raw_memory_management_patterns_in_nim_language.html https://ramanlabs.in/static/blog/raw_memory_management_patte...
  - tsoj 4y ago
    And for the stuff that matters, it is usually possible to tinker around enough to get it pretty much as good as Rust or C++.
brightball 4y ago
That’s how I feel about Elixir. Everything else just feels wrong now. I’d be curious to get your Nim highlights.
- cultofmetatron 4y ago
  thats exactly how I feel when it comes to web frameworks. nothing else has anything good enough to give up all the nice toys elixir gives me. haskell's types are cool vuetify makes me consider nuxt but only elixir has otp, immutable data structures, intercluseter message passing, channels, good performance, ease of use and descent ecosystem out of the box. rust is the only other new language Im looking at but for things outside web development
  - jasfi 4y ago
    Elixir is indeed the most loved web framework according to the latest StackOverflow survey. I'll be looking to Elixir for ideas for Nexus (web framework).
    - jasfi 4y ago
      I meant Phoenix, which is built on Elixir.
      - cultofmetatron 4y ago
        a lot of what makes phoenix amazing is directly inherited from elixir which are sub-derived from beam. Beam really is a marvel. copy one write and immutable data structures mean you ca have garbage collection reserved for the termination of a thread whihc would be a nontrivial task in languages that encourage mutability cough go cough Beam processes are a blessing its also extremely tuned for creating threads that are super lightweight. consequently, scaling strategies that are optimal in elixir would be a TERRIBLE idea in other languages. You could make a dynamic cluster of node/go instances that communicate over rabbitmq and have a supervisor process that can keep track of their state and resurrection in case of a crash. Its going to be error prone and take weeks of fiddling to get right. beam gives you that out of the box. Its not perfect but its more than good enough for your first 10000 customers. This benefit extends all the way up to Phoenix. because threads are trivial to create and the overhead is low, its a viable strategy to generate a stateful process for every user as they interact with the system, this is what allows liveview to be so powerful. Each channel connection gets its own thread as well. A single machine can handle thousands of threads this way with full isolation. one thread crashing won't affect your other connections. nodejs cannot provide that. if a web-socket connection crashes a node instance, it ends the connection for every customer currently connected to that node. Every attempt I've seen outside beam to recreate this revolve around OS level process which have a higher overhead and then they still need to create a mesasge passing protcol and supervision system. since OS threads are epensive, it wouldn't be a. good idea to try creating something like liveview as you'll overload your machine. So you might say, "ok, I'll craete a multicluster virtual machine optimized for immutable data structures with a built in intra process messaging protocol for communication as well as a higher level super vision process. at that point, I'll say "congratulations, you just reinvented the beam, lets see if we can port other languages to it!" anyways, if you're looking for something a little smaller for now, I highly recommend really understanding ecto and how it has you interact with databases. its easily the best database library I've worked with. precisely because it isn't a orm. It maps sql rows to elixir records which has much less of an impedance mismatch. its achieves almost zero friction between your database and your api.
jasfi 4y ago
I totally agree, Nim is great but it really needs more traction. I'm developing a web framework for Nim with batteries included (an ORM, for one), Nexus: https://github.com/jfilby/nexus https://github.com/jfilby/nexus
- giancarlostoro 4y ago
  Nice one of the projects I want to work on is a simple text editor that lets you build and run. I think back to some of my favorite niche languages like Processing and Racket although I dont use them a ton when I do I love their interactive editors. I am getting ahead of myself since I am still learning the language but I am coming from Python and various other languages so it has not been a complex transition.
  - jasfi 4y ago
    Nim also needs lots of example code for people to learn from. Even if people don't use Nexus, it's at least one more Nim project out there.
- rishav_sharan 4y ago
  jasfi, I am actually following your project and wanted to take this moment to ask a couple of questions. How are you planning to solve for Postgres drivers/clients with async and pipelining support? I had added nim std lib to the Techempower benchmarks, and while Nim shines in the plain text and other non db related requests, it comes at the very bottom as far as tests like Fortune go. When I did the work, there were no maintained/active Postgres drivers with async and pipelining support. And IMO, that wa the biggest reason why Nim hasn't had great benchmarking scores.
  - jasfi 4y ago
    Glad to hear you're interested in Nexus. The ORM currently uses db_postgres (from Nim's stdlib) only. I'm going to implement support for db_mysql and db_sqlite as well, it should be easy enough given how similar the API for the stdlib DB drivers are. Actual work on DB drivers is out-of-scope for me though. I noticed there is an async Postgres driver available: https://github.com/treeform/pg https://github.com/treeform/pg. I don't know how well tested this driver is, and no mention of pipelining support. It would be great to see Nim's web frameworks higher up on the Techempower benchmarks. Lack of such DB driver features usually comes down to time. The support for those features in stdlib would be a good bounty issue.

danielvaughn 4y ago

Care to give a brief overview of what you find appealing? I've never looked into the language before.

davidkunz 4y ago
Other comments already gave great examples but for me personally: - Concise syntax - Elegant language constructs (e.g. method call syntax) - Great macro system - You have control over what GC you use - Great performance - Everything is simple, it's easy to read other people's code
frigid 4y ago
I particularly like, from the syntax side: - Python-style syntax with significant indentation - Uniform Function Call Syntax: a.len() == a.len == len(a) - Fully unqualified imports by default: which might seem scary to Python programmers, but works great in practice because of static typing - All of the above makes code readable and succinct And from a language features side: - Compiles to C with all the architectural targets that come with it - Compilation to C also allows for easy C interop: wrap function signatures and types and you're done - This, in turn, means that Nim libraries can bootstrap off of the massive C ecosystem, while adding nicer APIs on top - Extremely performant GC by default: optional Rust-style annotations can further improve performance, and you can remove all overhead and manually manage memory with C-style pointers if you'd like - Useful compile-time templates and macros that can directly change the AST The community is also active and helpful on IRC/Matrix/Discord/Gitter (bridged together)
- frigid 4y ago
  One really important thing I forgot to mention is how extendable Nim is - first class support for macros and AST manipulation is very powerful. This cuts back significantly on the amount of functionality that needs compiler magic. So you'll see alternative (or new) implementations of core language features like async, threading, DSLs, typeclasses, traits, etc available as external packages, with just about the same user experience as if they were built into the stdlib or compiler.
- vegai_ 4y ago
  >- Uniform Function Call Syntax: a.len() == a.len == len(a) a.len() == len(a) seems like a good idea, but I'm not so sure about a.len... Isn't that a bit ambiguous?

pddpro 4y ago

Even Rust?

winrid 4y ago
Nim gives you like 85% of the performance of Rust without having to worry about a borrow checker. It also solves concurrency problems via its use of Channels, like Go. So it's just hard to justify using Rust, for me. Unless you're writing a DB or something where a GC is a no go. But Nim's memory management seems pretty good, and many things are stack allocated.
- elcritch 4y ago
  Its nice being able to go all the way from fully GC reliant cyclic data-types with closures all the way to memory control-freak every byte and microsecond matters by using stack objects and 'var' parameters. Often you can keep 90% of the code and just tweak a few slow points.
- warangal 4y ago
  Even though Nim by default works with a GC to manage memory, I regularly use Nim to work with direct-memory/raw-pointers and can still have increased memory safety by using HOOKS and ARC. I have written about my experience here[1], in case somebody is curious. 1. https://ramanlabs.in/static/blog/raw_memory_management_patterns_in_nim_language.html https://ramanlabs.in/static/blog/raw_memory_management_patte...
- tsoj 4y ago
  And for the stuff that matters, it is usually possible to tinker around enough to get it pretty much as good as Rust or C++.

brightball 4y ago

That’s how I feel about Elixir. Everything else just feels wrong now. I’d be curious to get your Nim highlights.

cultofmetatron 4y ago
thats exactly how I feel when it comes to web frameworks. nothing else has anything good enough to give up all the nice toys elixir gives me. haskell's types are cool vuetify makes me consider nuxt but only elixir has otp, immutable data structures, intercluseter message passing, channels, good performance, ease of use and descent ecosystem out of the box. rust is the only other new language Im looking at but for things outside web development
- jasfi 4y ago
  Elixir is indeed the most loved web framework according to the latest StackOverflow survey. I'll be looking to Elixir for ideas for Nexus (web framework).
  - jasfi 4y ago
    I meant Phoenix, which is built on Elixir.
    - cultofmetatron 4y ago
      a lot of what makes phoenix amazing is directly inherited from elixir which are sub-derived from beam. Beam really is a marvel. copy one write and immutable data structures mean you ca have garbage collection reserved for the termination of a thread whihc would be a nontrivial task in languages that encourage mutability cough go cough Beam processes are a blessing its also extremely tuned for creating threads that are super lightweight. consequently, scaling strategies that are optimal in elixir would be a TERRIBLE idea in other languages. You could make a dynamic cluster of node/go instances that communicate over rabbitmq and have a supervisor process that can keep track of their state and resurrection in case of a crash. Its going to be error prone and take weeks of fiddling to get right. beam gives you that out of the box. Its not perfect but its more than good enough for your first 10000 customers. This benefit extends all the way up to Phoenix. because threads are trivial to create and the overhead is low, its a viable strategy to generate a stateful process for every user as they interact with the system, this is what allows liveview to be so powerful. Each channel connection gets its own thread as well. A single machine can handle thousands of threads this way with full isolation. one thread crashing won't affect your other connections. nodejs cannot provide that. if a web-socket connection crashes a node instance, it ends the connection for every customer currently connected to that node. Every attempt I've seen outside beam to recreate this revolve around OS level process which have a higher overhead and then they still need to create a mesasge passing protcol and supervision system. since OS threads are epensive, it wouldn't be a. good idea to try creating something like liveview as you'll overload your machine. So you might say, "ok, I'll craete a multicluster virtual machine optimized for immutable data structures with a built in intra process messaging protocol for communication as well as a higher level super vision process. at that point, I'll say "congratulations, you just reinvented the beam, lets see if we can port other languages to it!" anyways, if you're looking for something a little smaller for now, I highly recommend really understanding ecto and how it has you interact with databases. its easily the best database library I've worked with. precisely because it isn't a orm. It maps sql rows to elixir records which has much less of an impedance mismatch. its achieves almost zero friction between your database and your api.

jasfi 4y ago

I totally agree, Nim is great but it really needs more traction. I'm developing a web framework for Nim with batteries included (an ORM, for one), Nexus: https://github.com/jfilby/nexus https://github.com/jfilby/nexus

giancarlostoro 4y ago
Nice one of the projects I want to work on is a simple text editor that lets you build and run. I think back to some of my favorite niche languages like Processing and Racket although I dont use them a ton when I do I love their interactive editors. I am getting ahead of myself since I am still learning the language but I am coming from Python and various other languages so it has not been a complex transition.
- jasfi 4y ago
  Nim also needs lots of example code for people to learn from. Even if people don't use Nexus, it's at least one more Nim project out there.
rishav_sharan 4y ago
jasfi, I am actually following your project and wanted to take this moment to ask a couple of questions. How are you planning to solve for Postgres drivers/clients with async and pipelining support? I had added nim std lib to the Techempower benchmarks, and while Nim shines in the plain text and other non db related requests, it comes at the very bottom as far as tests like Fortune go. When I did the work, there were no maintained/active Postgres drivers with async and pipelining support. And IMO, that wa the biggest reason why Nim hasn't had great benchmarking scores.
- jasfi 4y ago
  Glad to hear you're interested in Nexus. The ORM currently uses db_postgres (from Nim's stdlib) only. I'm going to implement support for db_mysql and db_sqlite as well, it should be easy enough given how similar the API for the stdlib DB drivers are. Actual work on DB drivers is out-of-scope for me though. I noticed there is an async Postgres driver available: https://github.com/treeform/pg https://github.com/treeform/pg. I don't know how well tested this driver is, and no mention of pipelining support. It would be great to see Nim's web frameworks higher up on the Techempower benchmarks. Lack of such DB driver features usually comes down to time. The support for those features in stdlib would be a good bounty issue.