8 ms·

Why not just use Nim? The language is rapidly converging on an ownership model similar to rust anyway and has better metaprogramming, more compile targets and a

by arc619 6y ago

Why not just use Nim? The language is rapidly converging on an ownership model similar to rust anyway and has better metaprogramming, more compile targets and a high development velocity (plus faster compile times). Rust has a bigger ecosystem of course, but Nim's is pretty decent and you can use C, C++ and JS libs natively for anything else.

fwsgonzo 6y ago
We really need a simpler language that has the same ownership model. I like Nim because I can compile it without threading support, and for RISC-V (albeit 64-bit, wish it had 32-bit support too..). Overall, I like it, but I could not justify using it in an enterprise setting without knowing that the direction of the language is going towards what is now the established minimum safety, which is borrow checking and no UB.
- gameswithgo 6y ago
  if you have borrow checking, you are going to inherit a lot of complexity in order to deal with the limitations it imposes. you could be simpler than rust, for sure, but bot as simple as say C or Go. Zig might be a language you are interested in. Simple like C with sensible ways of dealing with UB and bounds checking, as well as options instead of Nulls.
  - planetis 6y ago
    Zig is interesting but still very immature. Its memory model is manual management thus has no advantages over rust or nim. So it's marketed as better C (not any more than that).
- pizza234 6y ago
  > We really need a simpler language that has the same ownership model Can you mention which part of the Rust language you found complicated (in real world), excluding the ownership/memory management area (which includes: bck, lifetimes, smart pointers, traits related to synchronization)? I read a lot of comments about Rust's complexity, and while nobody doubts the complexity of the ownership/memory management, there's a very common lack of details when it comes to the rest of the language.
  - pjmlp 6y ago
    The rest of the language is just fine if you are used to the ML language family, maybe that is the issue for those coming from more mainstream languages.
k__ 6y ago
"The language is rapidly converging on an ownership model similar to rust " Nice. Do you have more resources on that? Also, does Nim have a WASM target?
- sp33der89 6y ago
  Here are some handy links (for me) that might help you out too: https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc... https://www.youtube.com/watch?v=aUJcYTnPWCg https://www.youtube.com/watch?v=aUJcYTnPWCg https://github.com/stisa/nwasm https://github.com/stisa/nwasm You can also go an Emscripten route: https://hookrace.net/blog/porting-nes-go-nim/ https://hookrace.net/blog/porting-nes-go-nim/
  - planetis 6y ago
    Latest presentation is https://www.youtube.com/watch?v=zPlBZkWvuug https://www.youtube.com/watch?v=zPlBZkWvuug It has updated information.
- atombender 6y ago
  Nim is apparently getting support for owned pointers [1]. There's a proposal [2]. The proposal PR has since been closed, but it's apparently still being worked on. [1] https://nim-lang.org/araq/ownedrefs.html https://nim-lang.org/araq/ownedrefs.html [2] https://github.com/nim-lang/RFCs/issues/144 https://github.com/nim-lang/RFCs/issues/144
  - planetis 6y ago
    I had played with and really liked "owned". However there was design issues with it and that feature was forgotten.
  - beagle3 6y ago
    Most of those semantics are now tracked automatically without needing annotation in arc/orc.
- 6y ago
Xevi 6y ago
I don't know much about Rust, and even less about Nim, but does this mean that Nim will have the same safety guarantees that Rust has? Also, can you really just add something like that down the line and ensure that the whole ecosystem works correctly? I was under the impression that Rust's strength was that it's been designed from the start to use an ownership model.
- beagle3 6y ago
  Nim’s arc/orc mode (introduced in 1.4 and likely to become default in 2.0) does borrow checking but does nit enforce it in the same way Rust does: instead, you’ll get a compiler warning “i can’t just borrow here, so I am making a copy” which you can prevent by making your type uncopyable (which will make this an error). The semantics are not equivalent to rust, but they are similar. Nim stops race conditions by controlling data passage among threads (disallowing shared data between threads, in general) and always has. I am not familiar enough with Rust to say that everything rust can do and assure is indeed covered in Nim; however, plain Nim without using the escape hatches (which like Rust unsafe code, exist for those times you must use them) is safe.
  - Xevi 6y ago
    That's awesome. I'm currently studying Rust, but I'm looking forward to giving Nim a try in a year or two. I really like the syntax, and if it can offer the same safety and performance as Rust, then I see a bright future for it.
simias 6y ago
Nim is nice but "better metaprogramming" is going to be very contentious I think. "Different metaprogramming" for sure, but the rest is a matter of preference frankly. Nim macros are a lot nicer than Rust's, but Rust's trait system is very powerful and expressive. Sure, you can do something like that with Nim's macros, but you can't expect that all third party code is going to play nice. That's the problem with the macro approach: it's great because it's ultra-flexible, but it also sucks because it's ultra-flexible. Everybody ends up doing their own little DSL that fits their use case or their personal taste, and it adds friction at the interfaces.
- nikki93 6y ago
  Is this based on having used Nim in practice in projects and observing the code of many Nim projects and collecting data / insights; or without having used Nim and on speculation / general thoughts about macros / DSLs (or somewhere along the spectrum)? Just so it's clear how to contextualize. Because having tried to explore these questions by studying Nim projects, going through a book and working on a game engine in it the past months; I've found that ufcs+overloading covers the static traits scenario, and it feels like the runtime traits object scenario is better self-rolled (I don't really want the compiler impl'ing vtables underneath me, save deciding to reuse a static dispatch feature for a dynamic one; if I want a struct of func ptrs I will make a struct of func ptrs.) at least for my usage. Various Nim code I come across is usually pretty readable, and I don't need to invent macros willy nilly. ufcs feels more elegant than needing to decide whether to namespace a function inside a struct or not (or which one), which is what most langs (including Rust) seem to do.
- planetis 6y ago
  There is no "friction" with macros, sure lot's of packages implement their own utility macros but most can be hidden under ordinary procs. Macros CAN be called like ORDINARY procs, check syntactic sugar module [1], though not all macros are designed this way. Unless we are talking about public DSLs. But I don't really understand what's the problem with them. [1] https://nim-lang.github.io/Nim/sugar.html https://nim-lang.github.io/Nim/sugar.html
  - 6y ago
zinclozenge 6y ago
No algebraic datatypes + pattern matching, yes I'm aware of libraries that implement it via metaprogramming, but that's not good enough for me.
- kevin_thibedeau 6y ago
  Try using Rust without any macros.
- arc619 6y ago
  > No algebraic datatypes Not sure what you mean there, there's product types with tuples and objects, and sum types as object variants. > Pattern matching Eh, I mean it's just sugar over a case statement. let num = 5 str = case num of 1: "One!" of 2, 3, 5, 7, 11: "This is a prime" of 13..19: "A teen" else: "Unknown" # Compile error if all cases arent covered. As you say there's libraries that let you deconstruct and partially match more complex types if you need that. Being able to create things like pattern matching, async, and novel multithreading runtimes as a library in Nim shows how powerful (and useful) the metaprogramming is. Enums in Rust are more interesting, but again nothing you can't do with an object variant.

by arc619 6y ago

fwsgonzo 6y ago

We really need a simpler language that has the same ownership model. I like Nim because I can compile it without threading support, and for RISC-V (albeit 64-bit, wish it had 32-bit support too..). Overall, I like it, but I could not justify using it in an enterprise setting without knowing that the direction of the language is going towards what is now the established minimum safety, which is borrow checking and no UB.

gameswithgo 6y ago
if you have borrow checking, you are going to inherit a lot of complexity in order to deal with the limitations it imposes. you could be simpler than rust, for sure, but bot as simple as say C or Go. Zig might be a language you are interested in. Simple like C with sensible ways of dealing with UB and bounds checking, as well as options instead of Nulls.
- planetis 6y ago
  Zig is interesting but still very immature. Its memory model is manual management thus has no advantages over rust or nim. So it's marketed as better C (not any more than that).
pizza234 6y ago
> We really need a simpler language that has the same ownership model Can you mention which part of the Rust language you found complicated (in real world), excluding the ownership/memory management area (which includes: bck, lifetimes, smart pointers, traits related to synchronization)? I read a lot of comments about Rust's complexity, and while nobody doubts the complexity of the ownership/memory management, there's a very common lack of details when it comes to the rest of the language.
- pjmlp 6y ago
  The rest of the language is just fine if you are used to the ML language family, maybe that is the issue for those coming from more mainstream languages.

k__ 6y ago

"The language is rapidly converging on an ownership model similar to rust " Nice. Do you have more resources on that? Also, does Nim have a WASM target?

sp33der89 6y ago
Here are some handy links (for me) that might help you out too: https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc... https://www.youtube.com/watch?v=aUJcYTnPWCg https://www.youtube.com/watch?v=aUJcYTnPWCg https://github.com/stisa/nwasm https://github.com/stisa/nwasm You can also go an Emscripten route: https://hookrace.net/blog/porting-nes-go-nim/ https://hookrace.net/blog/porting-nes-go-nim/
- planetis 6y ago
  Latest presentation is https://www.youtube.com/watch?v=zPlBZkWvuug https://www.youtube.com/watch?v=zPlBZkWvuug It has updated information.
atombender 6y ago
Nim is apparently getting support for owned pointers [1]. There's a proposal [2]. The proposal PR has since been closed, but it's apparently still being worked on. [1] https://nim-lang.org/araq/ownedrefs.html https://nim-lang.org/araq/ownedrefs.html [2] https://github.com/nim-lang/RFCs/issues/144 https://github.com/nim-lang/RFCs/issues/144
- planetis 6y ago
  I had played with and really liked "owned". However there was design issues with it and that feature was forgotten.
- beagle3 6y ago
  Most of those semantics are now tracked automatically without needing annotation in arc/orc.
6y ago

Xevi 6y ago

I don't know much about Rust, and even less about Nim, but does this mean that Nim will have the same safety guarantees that Rust has? Also, can you really just add something like that down the line and ensure that the whole ecosystem works correctly? I was under the impression that Rust's strength was that it's been designed from the start to use an ownership model.

beagle3 6y ago
Nim’s arc/orc mode (introduced in 1.4 and likely to become default in 2.0) does borrow checking but does nit enforce it in the same way Rust does: instead, you’ll get a compiler warning “i can’t just borrow here, so I am making a copy” which you can prevent by making your type uncopyable (which will make this an error). The semantics are not equivalent to rust, but they are similar. Nim stops race conditions by controlling data passage among threads (disallowing shared data between threads, in general) and always has. I am not familiar enough with Rust to say that everything rust can do and assure is indeed covered in Nim; however, plain Nim without using the escape hatches (which like Rust unsafe code, exist for those times you must use them) is safe.
- Xevi 6y ago
  That's awesome. I'm currently studying Rust, but I'm looking forward to giving Nim a try in a year or two. I really like the syntax, and if it can offer the same safety and performance as Rust, then I see a bright future for it.

simias 6y ago

Nim is nice but "better metaprogramming" is going to be very contentious I think. "Different metaprogramming" for sure, but the rest is a matter of preference frankly. Nim macros are a lot nicer than Rust's, but Rust's trait system is very powerful and expressive. Sure, you can do something like that with Nim's macros, but you can't expect that all third party code is going to play nice. That's the problem with the macro approach: it's great because it's ultra-flexible, but it also sucks because it's ultra-flexible. Everybody ends up doing their own little DSL that fits their use case or their personal taste, and it adds friction at the interfaces.

nikki93 6y ago
Is this based on having used Nim in practice in projects and observing the code of many Nim projects and collecting data / insights; or without having used Nim and on speculation / general thoughts about macros / DSLs (or somewhere along the spectrum)? Just so it's clear how to contextualize. Because having tried to explore these questions by studying Nim projects, going through a book and working on a game engine in it the past months; I've found that ufcs+overloading covers the static traits scenario, and it feels like the runtime traits object scenario is better self-rolled (I don't really want the compiler impl'ing vtables underneath me, save deciding to reuse a static dispatch feature for a dynamic one; if I want a struct of func ptrs I will make a struct of func ptrs.) at least for my usage. Various Nim code I come across is usually pretty readable, and I don't need to invent macros willy nilly. ufcs feels more elegant than needing to decide whether to namespace a function inside a struct or not (or which one), which is what most langs (including Rust) seem to do.
planetis 6y ago
There is no "friction" with macros, sure lot's of packages implement their own utility macros but most can be hidden under ordinary procs. Macros CAN be called like ORDINARY procs, check syntactic sugar module [1], though not all macros are designed this way. Unless we are talking about public DSLs. But I don't really understand what's the problem with them. [1] https://nim-lang.github.io/Nim/sugar.html https://nim-lang.github.io/Nim/sugar.html
- 6y ago

zinclozenge 6y ago

No algebraic datatypes + pattern matching, yes I'm aware of libraries that implement it via metaprogramming, but that's not good enough for me.

kevin_thibedeau 6y ago
Try using Rust without any macros.
arc619 6y ago
> No algebraic datatypes Not sure what you mean there, there's product types with tuples and objects, and sum types as object variants. > Pattern matching Eh, I mean it's just sugar over a case statement. let num = 5 str = case num of 1: "One!" of 2, 3, 5, 7, 11: "This is a prime" of 13..19: "A teen" else: "Unknown" # Compile error if all cases arent covered. As you say there's libraries that let you deconstruct and partially match more complex types if you need that. Being able to create things like pattern matching, async, and novel multithreading runtimes as a library in Nim shows how powerful (and useful) the metaprogramming is. Enums in Rust are more interesting, but again nothing you can't do with an object variant.