6 ms·

So, I've noticed that over the past six months that every time something about Nim gets posted to HN, you make an effort to discredit the language. Care to off

So, I've noticed that over the past six months that every time something about Nim gets posted to HN, you make an effort to discredit the language. Care to offer an explanation why?

pcwalton 11y ago
I think Nim is an impressive language that does a lot of things really well. I don't think the memory management is one of them. I believe that memory management and compilation to C are the only two major things I've ever talked about in regards to Nim, because I'm abstractly interested in those topics. If an article about thread-local deferred reference counting in Ruby hit the top of HN and the comments were talking about how that's good for games, I'd probably comment there too.
- copx 11y ago
  And how do you do "memory management well"? Like Rust? You pay a high price in complexity and inflexibility for that juicy GC-less yet safe memory management. Ref counting is not superior or inferior to explicit, restrictive ownership semantics. Those are simply different trade-offs. Nim might be strictly inferior for writing a heavily multi-threaded web browser because of its memory management approach but that does not mean the approach is generally inferior. Seems to me that Nim aims to be a "casual", rapid development / friendly (Python-like) language. Ownership semantics like in Rust do not fit there.
  - pcwalton 11y ago
    I'm personally a fan of regular old Java/C#-like concurrent garbage collection for most "scripting" languages (perhaps surprisingly, given my work on Rust). It's a lot of work to get there, but I think there's no substitute for doing the work—apps really end up needing the flexibility of shared memory. Shortcuts that seem simple like DRC end up tending to run into walls in practice, which is something that the other languages discovered—history keeps pointing to the HotSpot-style garbage collector as the one that systems that need to offer a simple, general-purpose garbage-collected programming model migrate to. For different use cases Rust-style ownership semantics (when the performance of GC and runtime interoperability become an issue), or Azul-style pauseless GC (when you're willing to trade throughput for latency), or shared-nothing architectures (when you need them for legacy reasons like JavaScript, or want a simple programming model like Erlang) can work great.
    - tatterdemalion 11y ago
      "apps really end up needing the flexibility of shared memory" Why? Just performance or is there a design reason also?
  - jibalt 11y ago
    "You pay a high price in complexity and inflexibility for that juicy GC-less yet safe memory management." It's a price that a lot of people are willing to pay, because of how badly they want what they're paying for. Nim and Rust have different goals, different tradeoffs, and overlapping target audiences. Having both is good. Making them fight is bad.
MichaelGG 11y ago
I'm guessing because Nim gets portrayed as safe, or offers some safe features, but overall is not memory safe. Rust has worked very hard and gotten through the problem of having memory safety, with zero runtime cost and reasonably good language features. Since it's 2015, it seems fair to point out when a new language offers something neat, but in a way that isn't safe.
- Pharohbot 11y ago
  Nim is as safe as any other language. Perhaps it's not as safe as Rust but that brings specific trade offs most people dont wan't to deal with. I don't understand why people think that Nim is "terribly unsafe" when in reality it's like any other language
  - heinrich5991 11y ago
    It has a feel of a scripting language, but as far as I can tell, it rather has the safety of C/C++, which I personally wouldn't call "safe like any other language".
    - Pharohbot 11y ago
      Why not? I'm interested to know because in my opinion I don't see it any less safe than languages that don't have automatic memory management and/or languages like Rust.
      - MichaelGG 11y ago
        Because it is flatly untrue? Memory safety is rather a binary thing. C# without /unsafe is safe. Same for Java and Rust. Not true for Nim or C/C++. Rust is unique in doing this without any GC or other runtime overhead, AFAIK, which makes it a bit special.
        Pharohbot 11y ago
        Do you have any specific examples of these unsafetiness in Nim?
kibwen 11y ago
You yourself know that this claim is entirely unsubstantiated, as evidenced by the fact that you felt the need to create a throwaway account. pcwalton is an active commentator throughout HN in general, and garbage collection and parallelism are two of his areas of expertise. If his opinion is somehow uninformed, then tell him so and explain how. If he's not uninformed, then the only thing your comment is doing is trying to shut down legitimate criticism. All languages have faults. Engage with your critics, own your faults, and either correct them or justify them based on your principles. EDIT: To give an example, pcwalton also initially criticized Go for not being memory-safe for values of GOMAXPROCS greater than 1. However, the Go team later implemented the dynamic race detector, which, if you've followed pcwalton's comments at all, you know that he is actually quite impressed with.
- fjehcjriendje 11y ago
  I always post using throwaways since I don't like karma influencing the content of my posts and it also makes it significantly more difficult for third parties to profile me.
  - kibwen 11y ago
    This is some glass-houses logic right here, given that you're attempting to leverage trivially-falsifiable assertions in order to profile pcwalton as a Nim hater with a personal vendetta. In the meantime you have yet to actually address his criticisms, which, to reiterate, indicates that you're trying to shut down critics via deflection. (I suppose, in the future, pcwalton should just generate a throwaway before commenting on Nim.)
jibalt 11y ago
I've noticed that a) that's an ad hominem attack and b) it isn't accurate.

So, I've noticed that over the past six months that every time something about Nim gets posted to HN, you make an effort to discredit the language. Care to offer an explanation why?

pcwalton 11y ago

I think Nim is an impressive language that does a lot of things really well. I don't think the memory management is one of them. I believe that memory management and compilation to C are the only two major things I've ever talked about in regards to Nim, because I'm abstractly interested in those topics. If an article about thread-local deferred reference counting in Ruby hit the top of HN and the comments were talking about how that's good for games, I'd probably comment there too.

copx 11y ago
And how do you do "memory management well"? Like Rust? You pay a high price in complexity and inflexibility for that juicy GC-less yet safe memory management. Ref counting is not superior or inferior to explicit, restrictive ownership semantics. Those are simply different trade-offs. Nim might be strictly inferior for writing a heavily multi-threaded web browser because of its memory management approach but that does not mean the approach is generally inferior. Seems to me that Nim aims to be a "casual", rapid development / friendly (Python-like) language. Ownership semantics like in Rust do not fit there.
- pcwalton 11y ago
  I'm personally a fan of regular old Java/C#-like concurrent garbage collection for most "scripting" languages (perhaps surprisingly, given my work on Rust). It's a lot of work to get there, but I think there's no substitute for doing the work—apps really end up needing the flexibility of shared memory. Shortcuts that seem simple like DRC end up tending to run into walls in practice, which is something that the other languages discovered—history keeps pointing to the HotSpot-style garbage collector as the one that systems that need to offer a simple, general-purpose garbage-collected programming model migrate to. For different use cases Rust-style ownership semantics (when the performance of GC and runtime interoperability become an issue), or Azul-style pauseless GC (when you're willing to trade throughput for latency), or shared-nothing architectures (when you need them for legacy reasons like JavaScript, or want a simple programming model like Erlang) can work great.
  - tatterdemalion 11y ago
    "apps really end up needing the flexibility of shared memory" Why? Just performance or is there a design reason also?
- jibalt 11y ago
  "You pay a high price in complexity and inflexibility for that juicy GC-less yet safe memory management." It's a price that a lot of people are willing to pay, because of how badly they want what they're paying for. Nim and Rust have different goals, different tradeoffs, and overlapping target audiences. Having both is good. Making them fight is bad.

MichaelGG 11y ago

I'm guessing because Nim gets portrayed as safe, or offers some safe features, but overall is not memory safe. Rust has worked very hard and gotten through the problem of having memory safety, with zero runtime cost and reasonably good language features. Since it's 2015, it seems fair to point out when a new language offers something neat, but in a way that isn't safe.

Pharohbot 11y ago
Nim is as safe as any other language. Perhaps it's not as safe as Rust but that brings specific trade offs most people dont wan't to deal with. I don't understand why people think that Nim is "terribly unsafe" when in reality it's like any other language
- heinrich5991 11y ago
  It has a feel of a scripting language, but as far as I can tell, it rather has the safety of C/C++, which I personally wouldn't call "safe like any other language".
  - Pharohbot 11y ago
    Why not? I'm interested to know because in my opinion I don't see it any less safe than languages that don't have automatic memory management and/or languages like Rust.
    - MichaelGG 11y ago
      Because it is flatly untrue? Memory safety is rather a binary thing. C# without /unsafe is safe. Same for Java and Rust. Not true for Nim or C/C++. Rust is unique in doing this without any GC or other runtime overhead, AFAIK, which makes it a bit special.
      - Pharohbot 11y ago
        Do you have any specific examples of these unsafetiness in Nim?

kibwen 11y ago

You yourself know that this claim is entirely unsubstantiated, as evidenced by the fact that you felt the need to create a throwaway account. pcwalton is an active commentator throughout HN in general, and garbage collection and parallelism are two of his areas of expertise. If his opinion is somehow uninformed, then tell him so and explain how. If he's not uninformed, then the only thing your comment is doing is trying to shut down legitimate criticism. All languages have faults. Engage with your critics, own your faults, and either correct them or justify them based on your principles. EDIT: To give an example, pcwalton also initially criticized Go for not being memory-safe for values of GOMAXPROCS greater than 1. However, the Go team later implemented the dynamic race detector, which, if you've followed pcwalton's comments at all, you know that he is actually quite impressed with.

fjehcjriendje 11y ago
I always post using throwaways since I don't like karma influencing the content of my posts and it also makes it significantly more difficult for third parties to profile me.
- kibwen 11y ago
  This is some glass-houses logic right here, given that you're attempting to leverage trivially-falsifiable assertions in order to profile pcwalton as a Nim hater with a personal vendetta. In the meantime you have yet to actually address his criticisms, which, to reiterate, indicates that you're trying to shut down critics via deflection. (I suppose, in the future, pcwalton should just generate a throwaway before commenting on Nim.)

jibalt 11y ago

I've noticed that a) that's an ad hominem attack and b) it isn't accurate.