5 ms·

Your criticism comes down to wanting a different abbreviation for "function" and wanting camel case instead of snake case. I would suggest that it's not that we

Your criticism comes down to wanting a different abbreviation for "function" and wanting camel case instead of snake case. I would suggest that it's not that we didn't spend time on the "visual aspect" of a language: rather it's that we made choices that were not your preference. We had to pick something and disappoint somebody; I apologize that that person was you. > Compare something in Rust (from OP's repo): As with so many of these comparisons, you're effectively comparing a language with GC to a language with safe manual memory management, and misinterpreting this as evidence of bad syntactic choices. (Same with Nim: Nim has GC.) Look at the function signature when you remove the lifetime annotations: fn type_list(dex: &DexFile, off: u32, parse_class_desc: bool) -> Vec<bstr> When you do that, there's very little difference between that and Go. > Of course, Go doesn't have lifetime annotations, but I understand who thought using ' was a great idea. Me. It was chosen because it's very visually lightweight.

stcredzero 10y ago
you're effectively comparing a language with GC to a language with safe manual memory management, and misinterpreting this as evidence of bad syntactic choices. So a better comparison would be to Swift. I don't think Rust compares favorably with Swift either.
- pcwalton 10y ago
  Swift doesn't have lifetimes either, as it's garbage collected via reference counting.
  - stcredzero 10y ago
    Swift isn't garbage collected. ARC is not GC. It's actually a form of manual memory management, with lots of help from the compiler. The way you structure your program does give particular objects a particular lifetime. https://news.ycombinator.com/item?id=7813598 https://news.ycombinator.com/item?id=7813598
    - pcwalton 10y ago
      Reference counting is a form of garbage collection [1] [2], as I've explained numerous times before. It has been considered a form of GC since the original papers in the 1960s and I see no reason to revisit that definition now. To track the lifetimes of objects, Swift programs perform operations (reference count manipulation) at runtime. That's because the Swift compiler does not know the static lifetimes of objects, unlike Rust. It can optimize away some reference count traffic, but this doesn't change the basic system: semantically, all objects are reference counted. [1]: https://en.m.wikipedia.org/wiki/Reference_counting https://en.m.wikipedia.org/wiki/Reference_counting [2]: http://www.memorymanagement.org/glossary/a.html#term-automatic-memory-management http://www.memorymanagement.org/glossary/a.html#term-automat...
atombender 10y ago
> Your criticism comes down to ... No, those were only the two most obvious, easiest-to-solve examples that came to mind. With all due respect to you and your Rust colleagues (who have done a lot of impressive work), "we made choices that were not your preference" sounds a little condescending. These are my personal opinions, just as your counterarguments are opinions. We should all able to make technical arguments without resorting to that kind of rhetoric. Of course you made choices. Everyone here is entitled to disagree with them and explain why. There's a false dichotomy between "hard-to-read syntax" and "no syntax at all" being implied here. It's reasonable to imagine that Rust could have had less terse, but still readable, syntax, even for things like lifetimes.
- pcwalton 10y ago
  > We should all able to make technical arguments without resorting to that kind of rhetoric. The subtext here is that these decisions aren't technical. They're pretty arbitrary: "func" vs. "fn" or camel case vs. snake case. There's no science here: there are lots of very successful languages with camel case and lots of very successful languages with snake case. I certainly appreciate that you have specific reasons for your preferences, but I take issue with the idea that we didn't spend time on the visual aspect of the language. > It's reasonable to imagine that Rust could have had less terse, but still readable, syntax, even for things like lifetimes. Do you have a proposal? There were long threads with different proposals back when this stuff was being designed, but none of them were particularly palatable. The verbosity with anything that wasn't as lightweight as possible turned out to be too much.

stcredzero 10y ago

you're effectively comparing a language with GC to a language with safe manual memory management, and misinterpreting this as evidence of bad syntactic choices. So a better comparison would be to Swift. I don't think Rust compares favorably with Swift either.

pcwalton 10y ago
Swift doesn't have lifetimes either, as it's garbage collected via reference counting.
- stcredzero 10y ago
  Swift isn't garbage collected. ARC is not GC. It's actually a form of manual memory management, with lots of help from the compiler. The way you structure your program does give particular objects a particular lifetime. https://news.ycombinator.com/item?id=7813598 https://news.ycombinator.com/item?id=7813598
  - pcwalton 10y ago
    Reference counting is a form of garbage collection [1] [2], as I've explained numerous times before. It has been considered a form of GC since the original papers in the 1960s and I see no reason to revisit that definition now. To track the lifetimes of objects, Swift programs perform operations (reference count manipulation) at runtime. That's because the Swift compiler does not know the static lifetimes of objects, unlike Rust. It can optimize away some reference count traffic, but this doesn't change the basic system: semantically, all objects are reference counted. [1]: https://en.m.wikipedia.org/wiki/Reference_counting https://en.m.wikipedia.org/wiki/Reference_counting [2]: http://www.memorymanagement.org/glossary/a.html#term-automatic-memory-management http://www.memorymanagement.org/glossary/a.html#term-automat...

atombender 10y ago

> Your criticism comes down to ... No, those were only the two most obvious, easiest-to-solve examples that came to mind. With all due respect to you and your Rust colleagues (who have done a lot of impressive work), "we made choices that were not your preference" sounds a little condescending. These are my personal opinions, just as your counterarguments are opinions. We should all able to make technical arguments without resorting to that kind of rhetoric. Of course you made choices. Everyone here is entitled to disagree with them and explain why. There's a false dichotomy between "hard-to-read syntax" and "no syntax at all" being implied here. It's reasonable to imagine that Rust could have had less terse, but still readable, syntax, even for things like lifetimes.

pcwalton 10y ago
> We should all able to make technical arguments without resorting to that kind of rhetoric. The subtext here is that these decisions aren't technical. They're pretty arbitrary: "func" vs. "fn" or camel case vs. snake case. There's no science here: there are lots of very successful languages with camel case and lots of very successful languages with snake case. I certainly appreciate that you have specific reasons for your preferences, but I take issue with the idea that we didn't spend time on the visual aspect of the language. > It's reasonable to imagine that Rust could have had less terse, but still readable, syntax, even for things like lifetimes. Do you have a proposal? There were long threads with different proposals back when this stuff was being designed, but none of them were particularly palatable. The verbosity with anything that wasn't as lightweight as possible turned out to be too much.