6 ms·

Nim (http://nim-lang.org http://nim-lang.org) is far superior to Go and Rust in many ways.

by sprash 11y ago

MichaelGG 11y ago
Nim is interesting but isn't remotely like Rust. It doesn't have memory safety as a core goal. And there's no strong sense of design and elegance. It very much comes off as "here's a bunch of ideas thrown together with the restriction that they all must somehow compile to C". I'm not saying it's bad or its users are wrong, but the mindset is utterly different. Rust and Go don't belong in any comparsion really. The only reason they are compared is because Google co-opted the term "systems" to mean something different than everyone else. Go fits in much more compared to managed languages, like Java or OCaml or something. (Just because Go statically links its runtime into output binaries doesn't change things. You can do this with C# via Mono's AOT features, for instance.)
- burntsushi 11y ago
  > The only reason they are compared is because Google co-opted the term "systems" to mean something different than everyone else. Really? You know, for a fact, that that is the only reason the two languages are compared? There couldn't be any other possible reason? How many years has it been since the official literature made such an egregious and offensive mistake as to misuse the term "systems"? The only reason it's even an issue is because people insist on bringing it up as the root cause for [insert social phenomenon here]. Because clearly, anyone who compares these languages must be so enamored by the original description of Go as a "systems" language that there couldn't possibly be any other explanation. (But maybe this fits in just right with your view of the Go community as "anti-intellectual.") Maybe people compare the languages because many people find them comparable. There's no mystery there.
  - matthewmacleod 11y ago
    There's no mystery there. Contrary to the previous poster, I suspect people simply compare the languages because they appeared around the same time and are both backed by big players. There's nothing really comparable between them (although the that's just my opinion) and I'm baffled as to why they are co pared so often.
    - burntsushi 11y ago
      Any two languages can be compared. The notion that the act of comparing two languages can be traced to one particular root cause (such as the use of the word "systems" N years ago) is ludicrous to me. What matters is the analysis that is involved in that comparison. For example, I'd find the answer to this question very interesting: "Compare and contrast concurrency in Rust and Go." I contend that the answer to this question is epic. It will take you back through the history of PL and lots of really interesting design decisions. At the forefront: should concurrency be a first class part of the language? Or should it be part of a library? And that's just one interesting question. There are plenty more.
  - MichaelGG 11y ago
    Right from the article: > When I initially wrote down my reactions to Go, I didn’t know about another new systems language: Rust. But maybe I'm misreading (honestly). Still they end up getting compared an awfully lot, more than they're compared to closer languages. At any rate, yeah, I find it very weird that the languages are compared. There seems to be very little overlap in when you'd want to use them. If you aren't bound by C-linkage or zero-runtime/overhead requirements, then there are higher level, more flexible languages to use than Rust. If you do have those requirements, Go simply isn't an option. (This is a bit simplistic but is generally correct.) Edit: I see you're taking an overly literal interpretation of "only". You're right. Anyone can compare anything for any reason. I think the intent of my comment is clear enough.
    - burntsushi 11y ago
      Your reasoning is not just a bit simplistic, it's overly reductive. Just because I'm not bound by C-linkage or zero-runtime/overheard requirements doesn't mean Rust isn't a good choice. Similarly, even if I do need to link to a C library, that doesn't mean Go is a bad choice. > There seems to be very little overlap in when you'd want to use them. If all you're going to do is consider each respective language's wheelhouses, then I might agree that there is little overlap (at least, currently). But in my experience, there are often plenty of other reasons in play that influence language choice. I once chose a language (not Rust/Go) purely because of how popular/accessible it was. There was no technical merit there, but because of that choice, the project has gotten very popular and used by a lot of people. At work, a few months ago, we had an internal debate over whether to use Rust or Go for a new project. There's plenty of overlap. Not every problem has a workable solution governed by uncompromisable requirements that uniquely identify a language, so one invariably winds up adopting other criteria for choosing a language. These criteria may not be uniquely technical; they may be social or even emotional. I contend that nothing I've said here is controversial. My goal is to encourage others to broaden their horizons; we don't need to put our blinders on and snub our noses at people that do things differently. (Which is absolutely how I perceived your comments in this thread.)
      - MichaelGG 11y ago
- sprash 11y ago
  > It doesn't have memory safety as a core goal. There is always a trade off in memory safety vs. performance. > there's no strong sense of design and elegance. I definitely see more elegance in Nims syntax as compared to Rust or even Go. But maybe this is because in real life python is by far the most productive language for me and Nim represents something like sane Cython alternative.
  - burntsushi 11y ago
    > There is always a trade off in memory safety vs. performance. Well... no. The central premise Rust is to not make that specific trade off. Rust gets memory safety without a hit in performance. (It does of course make a trade off: memory safety comes at the cost of more compile time checks and a more sophisticated type system.)
    - acconsta 11y ago
      >Rust gets memory safety without a hit in performance Interesting. How does rust statically verify that array accesses are in bounds?
      - bjz_ 11y ago
        Rust defaults to run-time bounds-checked array accesses, but iterators mean that the bounds only need to be checked once.
        acconsta 11y ago
        >iterators mean that the bounds only need to be checked once. How is that possible with random access or mutable containers?
        masklinn 11y ago
        A Rust object can be owned (T), mutably referenced (&mut T) or immutably referenced (&T). To a given owned object you can create either a single mutable reference or any number of immutable references (concurrently, sequentially is fine). When you create an iterator from a container, the iterator contains an immutable reference to the container. As long as the iterator is alive, it's not possible to take a mutable reference to the container, and thus not possible to modify it. Because a reference can't outlive its source, this also ensures the iterator can't outlive the collection.
- Araq 11y ago
  > And there's no strong sense of design and elegance. It very much comes off as "here's a bunch of ideas thrown together with the restriction that they all must somehow compile to C". But C is Turing-complete, so there is no restriction here. It's also not a "bunch of ideas thrown together" anymore than Haskell or Scala or Rust is. Nim focuses on 3 things: * Metaprogramming via a hygienic AST-based macro system. * An effect system to make the type system simpler to use. (The compiler infers an awful lot of useful information for you, the docgen shows the results for everybody to look at.) * GC'ed thread local heaps where each GC can comply with soft-realtime requirements. Hard realtime is being worked on. Any modern statically typed language also needs to have generics, closures, inheritance, exceptions or workarounds of the same complexity, so yeah Nim also has these making Nim instantly a big language. That doesn't mean it's a "bunch of ideas thrown together". > It doesn't have memory safety as a core goal. It does and it is reasonably safe (yeah yeah yeah we don't check for 'nil' properly yet, give me a break) with quite some improvements in the pipeline.
  - MichaelGG 11y ago
    My apologies then. I didn't mean to come off rude; elegance is subjective I suppose. I was under the impression that the only safe pointers (references) must be GC'd. So if you want/must to avoid that (say for perf), you're stuck using regular unsafe pointers. Is that inaccurate? The manual even says that just calling printf is actually unsafe as the cstring could be GC'd (but it probably won't). Maybe Nim should have an unsafe directive to make sure any unsafe user code is clearly marked? I also coulda sworn there was some part of the manual or site that was discussing a feature with a limitation due to the difficulty of expressing it in C. Maybe I imagined it. Sorry.
    - Araq 11y ago
      > The manual even says that just calling printf is actually unsafe as the cstring could be GC'd (but it probably won't). The manual tries very hard to mention corner cases since it's evolving into a proper spec. Calling printf is safe, it's C functions that take ownership of the char* pointer that are inherently unsafe. > Maybe Nim should have an unsafe directive to make sure any unsafe user code is clearly marked? That's a common misunderstanding, Nim doesn't need this. Instead of an ``unsafe`` keyword, Nim has ``addr`` and ``cast`` as keywords, these are the unsafe building blocks of the language. There are other corner cases that introduce unsafety, but they are all known and can be solved in time. > I also coulda sworn there was some part of the manual or site that was discussing a feature with a limitation due to the difficulty of expressing it in C. Well these things certainly are everywhere, but the issue here is not the difficulty of expressing it in C, but a desire to have very good C interop. Rust actually has all the same design constraints even though Rust builds on top of LLVM because the constraints come from the "systems programming" problem domain: Control over memory layouts, the stressed difference between heap and stack, etc. LLVM's IR is very close to C, so what is difficult to map to C is difficult to map to LLVM too.

Nim (http://nim-lang.org http://nim-lang.org) is far superior to Go and Rust in many ways.

by sprash 11y ago

Nim (http://nim-lang.org http://nim-lang.org) is far superior to Go and Rust in many ways.

Nim is interesting but isn't remotely like Rust. It doesn't have memory safety as a core goal. And there's no strong sense of design and elegance. It very much comes off as "here's a bunch of ideas thrown together with the restriction that they all must somehow compile to C". I'm not saying it's bad or its users are wrong, but the mindset is utterly different. Rust and Go don't belong in any comparsion really. The only reason they are compared is because Google co-opted the term "systems" to mean something different than everyone else. Go fits in much more compared to managed languages, like Java or OCaml or something. (Just because Go statically links its runtime into output binaries doesn't change things. You can do this with C# via Mono's AOT features, for instance.)

burntsushi 11y ago
> The only reason they are compared is because Google co-opted the term "systems" to mean something different than everyone else. Really? You know, for a fact, that that is the only reason the two languages are compared? There couldn't be any other possible reason? How many years has it been since the official literature made such an egregious and offensive mistake as to misuse the term "systems"? The only reason it's even an issue is because people insist on bringing it up as the root cause for [insert social phenomenon here]. Because clearly, anyone who compares these languages must be so enamored by the original description of Go as a "systems" language that there couldn't possibly be any other explanation. (But maybe this fits in just right with your view of the Go community as "anti-intellectual.") Maybe people compare the languages because many people find them comparable. There's no mystery there.
- matthewmacleod 11y ago
  There's no mystery there. Contrary to the previous poster, I suspect people simply compare the languages because they appeared around the same time and are both backed by big players. There's nothing really comparable between them (although the that's just my opinion) and I'm baffled as to why they are co pared so often.
  - burntsushi 11y ago
    Any two languages can be compared. The notion that the act of comparing two languages can be traced to one particular root cause (such as the use of the word "systems" N years ago) is ludicrous to me. What matters is the analysis that is involved in that comparison. For example, I'd find the answer to this question very interesting: "Compare and contrast concurrency in Rust and Go." I contend that the answer to this question is epic. It will take you back through the history of PL and lots of really interesting design decisions. At the forefront: should concurrency be a first class part of the language? Or should it be part of a library? And that's just one interesting question. There are plenty more.
- MichaelGG 11y ago
  Right from the article: > When I initially wrote down my reactions to Go, I didn’t know about another new systems language: Rust. But maybe I'm misreading (honestly). Still they end up getting compared an awfully lot, more than they're compared to closer languages. At any rate, yeah, I find it very weird that the languages are compared. There seems to be very little overlap in when you'd want to use them. If you aren't bound by C-linkage or zero-runtime/overhead requirements, then there are higher level, more flexible languages to use than Rust. If you do have those requirements, Go simply isn't an option. (This is a bit simplistic but is generally correct.) Edit: I see you're taking an overly literal interpretation of "only". You're right. Anyone can compare anything for any reason. I think the intent of my comment is clear enough.
  - burntsushi 11y ago
    Your reasoning is not just a bit simplistic, it's overly reductive. Just because I'm not bound by C-linkage or zero-runtime/overheard requirements doesn't mean Rust isn't a good choice. Similarly, even if I do need to link to a C library, that doesn't mean Go is a bad choice. > There seems to be very little overlap in when you'd want to use them. If all you're going to do is consider each respective language's wheelhouses, then I might agree that there is little overlap (at least, currently). But in my experience, there are often plenty of other reasons in play that influence language choice. I once chose a language (not Rust/Go) purely because of how popular/accessible it was. There was no technical merit there, but because of that choice, the project has gotten very popular and used by a lot of people. At work, a few months ago, we had an internal debate over whether to use Rust or Go for a new project. There's plenty of overlap. Not every problem has a workable solution governed by uncompromisable requirements that uniquely identify a language, so one invariably winds up adopting other criteria for choosing a language. These criteria may not be uniquely technical; they may be social or even emotional. I contend that nothing I've said here is controversial. My goal is to encourage others to broaden their horizons; we don't need to put our blinders on and snub our noses at people that do things differently. (Which is absolutely how I perceived your comments in this thread.)
    - MichaelGG 11y ago
sprash 11y ago
> It doesn't have memory safety as a core goal. There is always a trade off in memory safety vs. performance. > there's no strong sense of design and elegance. I definitely see more elegance in Nims syntax as compared to Rust or even Go. But maybe this is because in real life python is by far the most productive language for me and Nim represents something like sane Cython alternative.
- burntsushi 11y ago
  > There is always a trade off in memory safety vs. performance. Well... no. The central premise Rust is to not make that specific trade off. Rust gets memory safety without a hit in performance. (It does of course make a trade off: memory safety comes at the cost of more compile time checks and a more sophisticated type system.)
  - acconsta 11y ago
    >Rust gets memory safety without a hit in performance Interesting. How does rust statically verify that array accesses are in bounds?
    - bjz_ 11y ago
      Rust defaults to run-time bounds-checked array accesses, but iterators mean that the bounds only need to be checked once.
      - acconsta 11y ago
        >iterators mean that the bounds only need to be checked once. How is that possible with random access or mutable containers?
        masklinn 11y ago
        A Rust object can be owned (T), mutably referenced (&mut T) or immutably referenced (&T). To a given owned object you can create either a single mutable reference or any number of immutable references (concurrently, sequentially is fine). When you create an iterator from a container, the iterator contains an immutable reference to the container. As long as the iterator is alive, it's not possible to take a mutable reference to the container, and thus not possible to modify it. Because a reference can't outlive its source, this also ensures the iterator can't outlive the collection.
Araq 11y ago
> And there's no strong sense of design and elegance. It very much comes off as "here's a bunch of ideas thrown together with the restriction that they all must somehow compile to C". But C is Turing-complete, so there is no restriction here. It's also not a "bunch of ideas thrown together" anymore than Haskell or Scala or Rust is. Nim focuses on 3 things: * Metaprogramming via a hygienic AST-based macro system. * An effect system to make the type system simpler to use. (The compiler infers an awful lot of useful information for you, the docgen shows the results for everybody to look at.) * GC'ed thread local heaps where each GC can comply with soft-realtime requirements. Hard realtime is being worked on. Any modern statically typed language also needs to have generics, closures, inheritance, exceptions or workarounds of the same complexity, so yeah Nim also has these making Nim instantly a big language. That doesn't mean it's a "bunch of ideas thrown together". > It doesn't have memory safety as a core goal. It does and it is reasonably safe (yeah yeah yeah we don't check for 'nil' properly yet, give me a break) with quite some improvements in the pipeline.
- MichaelGG 11y ago
  My apologies then. I didn't mean to come off rude; elegance is subjective I suppose. I was under the impression that the only safe pointers (references) must be GC'd. So if you want/must to avoid that (say for perf), you're stuck using regular unsafe pointers. Is that inaccurate? The manual even says that just calling printf is actually unsafe as the cstring could be GC'd (but it probably won't). Maybe Nim should have an unsafe directive to make sure any unsafe user code is clearly marked? I also coulda sworn there was some part of the manual or site that was discussing a feature with a limitation due to the difficulty of expressing it in C. Maybe I imagined it. Sorry.
  - Araq 11y ago
    > The manual even says that just calling printf is actually unsafe as the cstring could be GC'd (but it probably won't). The manual tries very hard to mention corner cases since it's evolving into a proper spec. Calling printf is safe, it's C functions that take ownership of the char* pointer that are inherently unsafe. > Maybe Nim should have an unsafe directive to make sure any unsafe user code is clearly marked? That's a common misunderstanding, Nim doesn't need this. Instead of an ``unsafe`` keyword, Nim has ``addr`` and ``cast`` as keywords, these are the unsafe building blocks of the language. There are other corner cases that introduce unsafety, but they are all known and can be solved in time. > I also coulda sworn there was some part of the manual or site that was discussing a feature with a limitation due to the difficulty of expressing it in C. Well these things certainly are everywhere, but the issue here is not the difficulty of expressing it in C, but a desire to have very good C interop. Rust actually has all the same design constraints even though Rust builds on top of LLVM because the constraints come from the "systems programming" problem domain: Control over memory layouts, the stressed difference between heap and stack, etc. LLVM's IR is very close to C, so what is difficult to map to C is difficult to map to LLVM too.