Re: [rust-dev] Fwd: Please simplify the syntax for Great Justice
On 19/11/13 02:36, Nathan Myers wrote: Rust is a general purpose language designed to make programming more fun for the serious programmer. - nobody, yet. Honestly, I don't really care about fun. What my company needs is more in line with: « Rust is a powerful, clean, easy-to-learn and easy-to-read general purpose language designed for “programming in the large” that could replace c++ » /Daniel ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Fwd: Please simplify the syntax for Great Justice
On 11/13/13 2:37 AM, Greg wrote: 1. ~[OptionBucketK,V] 2. fn linear_map_with_capacityK:Eq + Hash,V(capacity: uint) - LinearMapK,V 3. fn contains_key(self, k: K) My approach would be to try and get rid of templates through better type inference in the compiler. We need the ability to define custom generic containers, which are essential for high-performance code. The Go/JS-like approach of building a few blessed containers into the language doesn't work when you need fine-grained control over data representations, which we need to build a competitive browser engine among other considerations. I'd introduce the common brace literal syntax for maps that can be found in JS and elsewhere, and perhaps additional literal syntax (ala ObjC + Clojure). We use the brace literal syntax for objects already, so we need something different. I do think that having a map literal syntax would be nice, but that can probably be done via the macro system for now. I'd also look at the symbols '~', '@', and '', and see what could be done to remove or simplify those. The current thinking is to remove `@` and possibly change `~`. `` will likely not change because of familiarity from C++. I'd look to see whether ARC could be used instead of garbage collection, and whether that would have an impact on syntax or not. We do support reference counting. The fact that we offer GC is a choice that gives control to the programmer. A broader point, though, is that syntax seems to me to be a very unimportant concern when making decisions that impact performance and control. Users of high-performance software, who vastly outnumber the developers and who never see the source code, aren't going to accept tradeoffs made to source-level aesthetics that simultaneously have the effect of making their software slow. There's also the question of whether symbols (ala Lisp/Scheme/Clojure) could be useful in simplifying the language and making it more versatile. Can you elaborate? Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Fwd: Please simplify the syntax for Great Justice
...and possibly change `~`. To what? -- Ziad On Tue, Nov 12, 2013 at 1:31 PM, Patrick Walton pcwal...@mozilla.comwrote: On 11/13/13 2:37 AM, Greg wrote: 1. ~[OptionBucketK,V] 2. fn linear_map_with_capacityK:Eq + Hash,V(capacity: uint) - LinearMapK,V 3. fn contains_key(self, k: K) My approach would be to try and get rid of templates through better type inference in the compiler. We need the ability to define custom generic containers, which are essential for high-performance code. The Go/JS-like approach of building a few blessed containers into the language doesn't work when you need fine-grained control over data representations, which we need to build a competitive browser engine among other considerations. I'd introduce the common brace literal syntax for maps that can be found in JS and elsewhere, and perhaps additional literal syntax (ala ObjC + Clojure). We use the brace literal syntax for objects already, so we need something different. I do think that having a map literal syntax would be nice, but that can probably be done via the macro system for now. I'd also look at the symbols '~', '@', and '', and see what could be done to remove or simplify those. The current thinking is to remove `@` and possibly change `~`. `` will likely not change because of familiarity from C++. I'd look to see whether ARC could be used instead of garbage collection, and whether that would have an impact on syntax or not. We do support reference counting. The fact that we offer GC is a choice that gives control to the programmer. A broader point, though, is that syntax seems to me to be a very unimportant concern when making decisions that impact performance and control. Users of high-performance software, who vastly outnumber the developers and who never see the source code, aren't going to accept tradeoffs made to source-level aesthetics that simultaneously have the effect of making their software slow. There's also the question of whether symbols (ala Lisp/Scheme/Clojure) could be useful in simplifying the language and making it more versatile. Can you elaborate? Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Fwd: Please simplify the syntax for Great Justice
On 11/18/13 4:23 PM, Ziad Hatahet wrote: ...and possibly change `~`. To what? `*` Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Fwd: Please simplify the syntax for Great Justice
To what? `*` ...But only if you change the deref operator to something else. Bikeshedding thread! :P On Mon, Nov 18, 2013 at 7:27 PM, Patrick Walton pcwal...@mozilla.comwrote: On 11/18/13 4:23 PM, Ziad Hatahet wrote: ...and possibly change `~`. To what? `*` Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Fwd: Please simplify the syntax for Great Justice
On 11/18/13 5:33 PM, Benjamin Striegel wrote: To what? `*` ...But only if you change the deref operator to something else. Bikeshedding thread! :P No, allocation would be with `new`. Patrick ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Fwd: Please simplify the syntax for Great Justice
On 11/18/2013 04:27 PM, Patrick Walton wrote: On 11/18/13 4:23 PM, Ziad Hatahet wrote: ...and possibly change `~`. To what? `*` Also, s/fn/fun/g We must not underestimate the importance of being perceived as a fun language. C++ is a general purpose programming language designed to make programming more enjoyable for the serious programmer. - Bjarne Stroustrup Rust is a general purpose language designed to make programming more fun for the serious programmer. - nobody, yet. Seriously, Nathan Myers ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Fwd: Please simplify the syntax for Great Justice
On Mon, Nov 18, 2013 at 5:34 PM, Patrick Walton pcwal...@mozilla.comwrote: No, allocation would be with `new`. Would that have to proceed each allocation? For instance, would let v = ~[~one, ~two, ~three]; turn into let v = new Vector(new one, new two, new three); ? -- Ziad ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Fwd: Please simplify the syntax for Great Justice
Yes. Patrick Ziad Hatahet hata...@gmail.com wrote: On Mon, Nov 18, 2013 at 5:34 PM, Patrick Walton pcwal...@mozilla.comwrote: No, allocation would be with `new`. Would that have to proceed each allocation? For instance, would let v = ~[~one, ~two, ~three]; turn into let v = new Vector(new one, new two, new three); ? -- Ziad -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Fwd: Please simplify the syntax for Great Justice
Keep in mind that, IMHO, the brevity of ~ is a large reason why people overallocate and make Rust programs slower than they need to be (e.g. your example). Patrick Patrick Walton pwal...@mozilla.com wrote: Yes. Patrick Ziad Hatahet hata...@gmail.com wrote: On Mon, Nov 18, 2013 at 5:34 PM, Patrick Walton pcwal...@mozilla.comwrote: No, allocation would be with `new`. Would that have to proceed each allocation? For instance, would let v = ~[~one, ~two, ~three]; turn into let v = new Vector(new one, new two, new three); ? -- Ziad -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Fwd: Please simplify the syntax for Great Justice
On Nov 12, 2013, at 12:15 PM, Tiffany Bennett tiff...@stormbit.net wrote: [.. a bunch of flamebait ..] Sorry, not gonna bite. I think there was one reply-worthy comment buried in there, perhaps a tacit request for remove-worthy syntax examples? I can point out syntax that I don't like, but I think it'd be more productive to simultaneously offer alternatives, and I haven't studied Rust in enough depth to where I'd be comfortable doing that. Here are some areas that caught my eye in the Doc-language-FAQ on Github. If I were to start using Rust, I'd research these in more depth to try and simplify the syntax: 1. ~[OptionBucketK,V] 2. fn linear_map_with_capacityK:Eq + Hash,V(capacity: uint) - LinearMapK,V 3. fn contains_key(self, k: K) My approach would be to try and get rid of templates through better type inference in the compiler. I'd introduce the common brace literal syntax for maps that can be found in JS and elsewhere, and perhaps additional literal syntax (ala ObjC + Clojure). I'd also look at the symbols '~', '@', and '', and see what could be done to remove or simplify those. I'd look to see whether ARC could be used instead of garbage collection, and whether that would have an impact on syntax or not. There's also the question of whether symbols (ala Lisp/Scheme/Clojure) could be useful in simplifying the language and making it more versatile. Finally, if all else fails, I'd go for broke and S-expr the whole thing. :-p - Greg P.S. Accusing me of lying, and then misrepresenting what I said, is not going to take this conversation down a productive path. You'll probably just end up getting ignored (or worse). -- Please do not email me anything that you are not comfortable also sharing with the NSA. signature.asc Description: Message signed with OpenPGP using GPGMail ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Fwd: Please simplify the syntax for Great Justice
On Tue, Nov 12, 2013 at 12:37 PM, Greg g...@kinostudios.com wrote: On Nov 12, 2013, at 12:15 PM, Tiffany Bennett tiff...@stormbit.net wrote: [.. a bunch of flamebait ..] Sorry, not gonna bite. I think there was one reply-worthy comment buried in there, perhaps a tacit request for remove-worthy syntax examples? I can point out syntax that I don't like, but I think it'd be more productive to simultaneously offer alternatives, and I haven't studied Rust in enough depth to where I'd be comfortable doing that. Here are some areas that caught my eye in the Doc-language-FAQ on Github. If I were to start using Rust, I'd research these in more depth to try and simplify the syntax: 1. ~[OptionBucketK,V] 2. fn linear_map_with_capacityK:Eq + Hash,V(capacity: uint) - LinearMapK,V 3. fn contains_key(self, k: K) My approach would be to try and get rid of templates through better type inference in the compiler. I'd introduce the common brace literal syntax for maps that can be found in JS and elsewhere, and perhaps additional literal syntax (ala ObjC + Clojure). Type inference for function signatures leads to programmer errors where it infers the wrong type. You seem to have the idea that much of this syntax is unnecessary, when it really is - all of it is important to specifying exactly what you mean. In a system's language like Rust, there are a lot of things that you could mean. You should try providing real examples of how you could simplify the examples you provided. I'd also look at the symbols '~', '@', and '', and see what could be done to remove or simplify those. Anything you do to simplify Rust's memory management will be of detriment to the language, because it is an important part of Rust's ability to function as a system's language. Each of those symbols has an important meaning in regards to memory management - ~ being RAII-like, @ being garbage collected (and now behind a feature gate while everyone figures out whether to keep the symbol or just use RCT/GCT), is a way to take temporary references to something. I'd look to see whether ARC could be used instead of garbage collection, and whether that would have an impact on syntax or not. ARC /is/ garbage collection. It's an atomic reference counter that can be sent between tasks. There's also the question of whether symbols (ala Lisp/Scheme/Clojure) could be useful in simplifying the language and making it more versatile. Finally, if all else fails, I'd go for broke and S-expr the whole thing. :-p I've tried implementing an S-expr based language myself, and the benefits are really not as great as they first seem. One thing you eventually realize is that although lisp has an incredible macro system, needing macros in the first place is often a sign of a type system that isn't powerful enough to express many concepts. Do you often see macros used in languages like Haskell or Idris? - Greg P.S. Accusing me of lying, and then misrepresenting what I said, is not going to take this conversation down a productive path. You'll probably just end up getting ignored (or worse). -- Please do not email me anything that you are not comfortable also sharing with the NSA. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Fwd: Please simplify the syntax for Great Justice
Sorry, I did go a bit overboard On Tue, Nov 12, 2013 at 12:48 PM, Tim Chevalier catamorph...@gmail.comwrote: Hey Tiffany -- Just wanted to let you know that I thought this was a totally appropriate email on your part :-) Normally I would warn about the code of conduct, but tbh, in this case I think Greg deserved it. Just my opinion, of course, and not the official opinion of the team :-) That said, when you want to shut people down in the future (a role that is very much needed given the number of cranks that Rust attracts, especially now that neither I nor Graydon will be mods after this week), try to do it in a way that you can argue is kind and courteous (as per the conduct section of https://github.com/mozilla/rust/wiki/Note-development-policy ), so that the other list mods will have no reason to criticize it :-) Cheers, Tim On Tue, Nov 12, 2013 at 9:15 AM, Tiffany Bennett tiff...@stormbit.net wrote: On Mon, Nov 11, 2013 at 4:07 PM, Greg g...@kinostudios.com wrote: I think it's still possible to simplify Rust's existing syntax while maintaining the features it offers. You haven't actually explained which syntax you want to remove. I'm almost certain that the answer is no (partly because these languages/dialects did not exist at the time). The language is very similar in semantics to OCaml, to say that Rust is only inspired by C++ would be a lie. What about Lua, which is more C-like? You've obviously never used Lua, it's nothing like C. Or CoffeeScript? Coffeescript is the exact opposite of what you ask - it's a superset of javascript that adds some syntax sugar. The fact it compiles to very readable javascript is a testament to this. The list contains some bad role models (in terms of syntactic elegance and simplicity): C++, Haskell, OCaml, and Ruby. I seriously doubt your taste in syntax if you think Haskell and OCaml are undesirable. Thankfully Common Lisp is mentioned. Although, of the Lisps I'm familiar with, Common Lisp has the ugliest syntax (still better than C++ though). You are clearly misusing the word syntax... Common lisp's syntax consists of only S-exprs and the quote sugar, as other lisps do. This is all to say that, from what I can tell, simplicity and elegance of syntax was not a design requirement (or goal) that the Rust developers had in mind. The goal of Rust was to produce a type-safe, memory-safe, programmer-safe programming language, in the niche of system's languages. And I think that's quite unfortunate for Rust. It's quite unfortunate that the language doesn't abide by your nebulous, sparsely defined ideas of what a good language looks like? I'm sorry I was not able to provide this feedback years ago when it might have been more helpful. I only recently became aware of Rust. I doubt it would have been taken seriously then. - Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. On Nov 11, 2013, at 3:46 PM, Corey Richardson co...@octayn.net wrote: On Mon, Nov 11, 2013 at 3:41 PM, Greg g...@kinostudios.com wrote: At this state in Rust's development, we are unlikely to make any major changes to Rust's syntax. *cries* I don't think Rust can succeed as a language if it massively differs, visually, from the language it intends to offset (C++). ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev -- Tim Chevalier * http://catamorphism.org/ * Often in error, never in doubt If you are silent about your pain, they'll kill you and say you enjoyed it. -- Zora Neale Hurston ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
