Re: [rust-dev] Rust forum
On Tue, Dec 3, 2013 at 12:45 AM, David Piepgrass wrote: > 1. In non-digest mode, My inbox gets flooded. > 3. In email I don't get a threaded view. If I go to mailing list archives > to see a threaded view, I can't reply. > 4. I have to manually watch for replies to my messages or to threads I'm > following. If someone mentions my name (not that they would), I won't be > notified. > You should consider getting a better email client. GMail handles mailing lists pretty poorly, and even it does better than that. > In contrast, Discourse has a variety of email notification options. I > don't know if those options are enough to please everybody, but you can > probably configure it to notify you about all posts, which makes it > essentially equivalent to a mailing list. It supports reply by email, so > those that prefer a mailing list can still pretend it's a mailing list. > Currently I'm getting an shrunk digest of Discourse Meta--by email I only > get a subset of all messages, auto-selected by Discourse, whatever it > thinks is interesting. That's good for me: I really don't want to see every > message. > Do you think it allows you to reply via email like github does? You've made a number of good points, I must say. > Plus, a mailing list offers less privacy as it mandates publishing your > email address. That's not a big deal for me personally, but do you really > want to require that from every Rust user? > > (btw, if I'm wrong about any of the above points, I promise there are lots > of other netizens out there who have the same misconception(s), so many of > them will avoid mailing lists. The fact that y'all are talking to me on a > mailing list suggests that the disadvantages of a mailing list are not a > big deal *to you*, but as for those who aren't participating, you can't > conclude *they* prefer mailing lists.) > > And like mailing lists, Discourse also supports private messages. > > I don't understand why Paul mentioned GPG. You want to encrypt messages to > a public mailing list? You can sign messages, but surely almost no one > actually checks the signature, and I'd be surprised if Discourse didn't > offer some built-in evidence of identity (surely it's not like email in > letting you spoof the sender name easily?). > > I heard discourse supports attachments, just that you may have to go to > the forum to attach or download them (rather than by email). > > > ___ > 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] Placement new and the loss of `new` to keywords
I agree with the `box` name, it's far less jarring than `new (1+1)`. On Sun, Dec 1, 2013 at 9:06 AM, Tim Kuehn wrote: > On Sun, Dec 1, 2013 at 8:04 AM, spir wrote: > >> On 12/01/2013 02:51 AM, Florian Zeitz wrote: >> >>> If I may chime in here. >>> I agree with Kevin that the different semantics of `new` are more likely >>> to create confusion, than alleviate it. >>> >>> Personally I would suggest calling this operator `box`, since it "boxes" >>> its argument into a newly allocated memory box. >>> >>> After all, these are different semantics from C++'s `new` (and also Go's >>> `make` AFAICT), therefore, presuming that a sigil is not a sufficient >>> indicator of a non-stack allocation, using an unprecedented keyword >>> seems the way to go to me. >>> >> >> +++ to all 3 points >> >> Denis >> > > > I, too, am in favor of the `box` proposal. Short, intuitive, not > already commonly used. What's not to like? > > Cheers, > Tim > > > > > > > ___ >> 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 > > ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] do
On Sat, Nov 30, 2013 at 9:34 AM, Oren Ben-Kiki wrote: > That would help a bit, but it would still require the programmer to > manually setup and teardown the tuples, pass them to the closure, and so > on. We'll also need to change each and every function that takes an action > parameter to take the extra tuple in every container or container-like > type. And then there's the possibility of modifying variables... It sounds > like a lot of effort working around something the compiler can do > automatically and actually already does automatically; all it needs is the > ability to communicate the programmer intent via the type system so it can > support and enforce it. > I agree, having annotations so that the type system can enforce safety is a better idea than hacking around it with alternate versions of every function for taking closures only used once. ___ 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 wrote: > 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 > wrote: > > On Mon, Nov 11, 2013 at 4:07 PM, Greg 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 wrote: > >> > >> On Mon, Nov 11, 2013 at 3:41 PM, Greg 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
Re: [rust-dev] Fwd: Please simplify the syntax for Great Justice
On Tue, Nov 12, 2013 at 12:37 PM, Greg wrote: > On Nov 12, 2013, at 12:15 PM, Tiffany Bennett > 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. ~[Option>] > > 2. fn linear_map_with_capacity(capacity: uint) -> > LinearMap > > 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 RC/GC), & 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
[rust-dev] Fwd: Please simplify the syntax for Great Justice
On Mon, Nov 11, 2013 at 4:07 PM, Greg 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 wrote: > > On Mon, Nov 11, 2013 at 3:41 PM, Greg 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
Re: [rust-dev] Abandoning segmented stacks in Rust
If you really need such a small memory footprint for your tasks, I am of the opinion that it would be less error prone (whoops, accidentally used 64 bytes of stack than I should have, now I'm using twice as much memory!) to use an async event loop, like libevent, rather than a task model. It just doesn't seem like it's as worthwhile - if you really need to have that faux synchronous IO, you could use FRP. I'm sure a lot of people would disagree with me, given the general direction rust has been going with tasks (IO, task-local errors, etc.) ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
