Re: [rust-dev] Please simplify the syntax for Great Justice

[spir]

On 11/20/2013 04:03 AM, Val Markovic wrote:

Fair point. I give you guys a lot of credit though, Rust is a wonderful
language in general. I also admire how willing core Rust devs are to admit
"ok that was a bad idea, let's try something else." I don't see that every
day; Rust is better for it.

Please continue being awesome.


Agree. Thank you all very much for this effort, and for making it "public good".

Denis
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Gaetan]

Indeed, that deserve our uttermost respect!
Le 20 nov. 2013 04:04, "Val Markovic"  a écrit :

> On Tue, Nov 19, 2013 at 5:21 PM, Patrick Walton wrote:
>
>>
>> I agree that we should change this, but give us some credit: it's only an
>> obvious design mistake now that we've gotten to this point.
>> [...]
>
> The current status is the product of the slow evolution of a design that
>> predated the region and slicing system, and what seems obvious now was not
>> obvious in retrospect.
>
>
> Fair point. I give you guys a lot of credit though, Rust is a wonderful
> language in general. I also admire how willing core Rust devs are to admit
> "ok that was a bad idea, let's try something else." I don't see that every
> day; Rust is better for it.
>
> Please continue being awesome.
>
>
>>
>>
>> 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
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Val Markovic]

On Tue, Nov 19, 2013 at 5:21 PM, Patrick Walton wrote:

>
> I agree that we should change this, but give us some credit: it's only an
> obvious design mistake now that we've gotten to this point.
> [...]

The current status is the product of the slow evolution of a design that
> predated the region and slicing system, and what seems obvious now was not
> obvious in retrospect.


Fair point. I give you guys a lot of credit though, Rust is a wonderful
language in general. I also admire how willing core Rust devs are to admit
"ok that was a bad idea, let's try something else." I don't see that every
day; Rust is better for it.

Please continue being awesome.


>
>
> 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] Please simplify the syntax for Great Justice

[Patrick Walton]

On 11/19/13 5:12 PM, Val Markovic wrote:

I felt cheated a bit TBH. It's such an obvious design mistake IMO;
everyone's going to get this wrong because it's counter-intuitive.


I agree that we should change this, but give us some credit: it's only 
an obvious design mistake now that we've gotten to this point. For those 
joining us now, we have gone through the following changes starting 3 
years ago:


1. `[T]` is always reference counted. Pushing onto a vector was 
optimized to push in-place iff the reference count was 1. There is `[mut 
T]` as well. There is no overloading and also no slicing, because there 
was no region system.
2. `[T]` is always owned and small vector optimized with 4 elements 
in place (number arrived at through measurements). There is no `[mut 
T]`. There is no slicing because there is no region system.
3. `[T]` is always owned and not small vector optimized. There is 
no slicing.
4. We have 4 vector types, `[T, ..N]`, `[T]/&` and `[T]/~` (today 
`[T, ..N]`, `&[T]`, `~[T]` respectively), as well as `[T]/@` which is 
reference counted. Vector literals infer to the right one. Owned and 
managed vectors can be sliced.

5. We have 4 vector types, `[T, ..N]`, `&[T]`, `~[T]`, and `@[T]`.
6. We have 3 vector types, `[T, ..N]`, `&[T]` and `~[T]`.

Now we're talking about:

7. We have 1 built-in vector type: `[T, ..N]`. Slices are 
`Slice` lang items. Owned and managed vectors can be built into the 
library.


The current status is the product of the slow evolution of a design that 
predated the region and slicing system, and what seems obvious now was 
not obvious in retrospect.


Patrick

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Val Markovic]

On Tue, Nov 19, 2013 at 4:43 AM, Daniel Micay  wrote:
>
> The expression ~([1, 2, 3]) has a different type than the expression
> ~[1, 2, 3]. The former is an owned box containing a fixed size array
> (~[int, ..3]) and the latter is a dynamic array (~[int]).
>
> The ~str and ~[T] types are *not* owned boxes in the current type
> system. There has been a proposal for dynamically sized types which
> would make them owned boxes, but I only like it as the path forwards
> for traits/closures and not vectors.
>
> I don't think dynamic arrays/strings belong as built-in types
> hard-wired into the language, especially with a confusing syntax like
> this. They should be treated as other containers are.
>
> In what I think is a sane system, dynamic arrays would be a library
> `Vec` type just like we have `HashMap` and will have other
> vector types like `Rope` or `SmallVec`.


Agreed with this 100%. From a mental model perspective, you can't have ~foo
mean "foo is boxed" everywhere in the language and then go "Oh but ~str and
~[T]? Yeah those are exceptions. You're mental model is wrong".

*Everyone* is going to build this incorrect mental model of "putting ~ in
front of a thing puts that thing in a box" and it's not the user's fault,
it's Rust's fault for having this silly distinction.

~ in front of a type should mean one thing and one thing only. Otherwise
we're just making life difficult for the users for no sensible reason. I
read through all the Rust docs several times over the last few months, I
have years of experience with C++ and thought I had a rock-solid
understanding of ~T (it's just a unique_ptr) and just a few days ago I
learned that ~str and ~[T] are special. And I only learned about this by
randomly browsing through rust-dev.

I felt cheated a bit TBH. It's such an obvious design mistake IMO;
everyone's going to get this wrong because it's counter-intuitive. It's
like mutable default arguments in Python 2.x (which was thankfully fixed in
3.0). [I'm not trying to bash a different language, I know that's against
the rules of the list. I'm just trying to draw a parallel with a different
language design mistake that tripped up everyone as well.]
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Liigo Zhuang]

在 2013年11月19日 下午8:44，"Daniel Micay" 写道：
>
> On Tue, Nov 19, 2013 at 7:35 AM, spir  wrote:
> >
> > If this is all true, that recursive structures are the main, "almost the
> > only use case" of ~ pointers, then the tutorial is in my view rather ok
on
> > this point. But then, why does it seem there are ~ pointers in every
corner
> > of Rust code? Including numerous cases in the tutorial itself.
> >
> > Also, how would we explain and term this meaning? "Indirection" is not
good
> > enough (for we introduce indirections for other reasons, if only to have
> > variable-size content). I'd say "self-similarity" is the right term
here,
> > and self-explaining (see wikipedia if you are not familiar with the
idea).
> > This is, in fact, the actual idea commonly termed "recursivity" in
> > programming (wrongly, in my view, but this is yet another terminological
> > issue). A rule about ~ pointers thus may be:
> >
> >Whenever one needs self-similarity, use a ~ pointer.
> >This lets the language store the element through the kind
> >of indirection that permits a self-similar structure.
> >
> > (I'm not happy of this formulation, neither, still obscure.)
> >
> > however, other comments on ~ pointers (eg comparisons with C++
unique_ptr,
> > notes that it means owned or "my") introduce ideas rather different
from the
> > one you suggest here, don't they? Say I manually create a kind of
string or
> > "fix-size" array:
> >
> > struct String {
> > n_bytes : uint,
> > bytes   : ~[u8],
> > }
> >
> > struct Array  {
> > n_items : uint,
> > items   : ~[Item],
> > }
>
> The expression ~([1, 2, 3]) has a different type than the expression
> ~[1, 2, 3]. The former is an owned box containing a fixed size array
> (~[int, ..3]) and the latter is a dynamic array (~[int]).
>
> The ~str and ~[T] types are *not* owned boxes in the current type
> system. There has been a proposal for dynamically sized types which
> would make them owned boxes, but I only like it as the path forwards
> for traits/closures and not vectors.
>

Are you telling us "~T is not ~T", just as "sun is not sun" and "moon is
not moon"?? If they do not have the same semantic, why use the same syntax?

> I don't think dynamic arrays/strings belong as built-in types
> hard-wired into the language, especially with a confusing syntax like
> this. They should be treated as other containers are.
>
> In what I think is a sane system, dynamic arrays would be a library
> `Vec` type just like we have `HashMap` and will have other
> vector types like `Rope` or `SmallVec`.
>
> > Is it wrong here to ~ point to bytes or items? that's what I'd do,
anyway...
> > If it is right, maybe the actual meaning of ~ is something like "proper
> > content". Whenever a structure actually contains content which is
actually
> > proper to it, or more generally has (pointed) data participating to its
> > description, then these contents or descriptive data should pointed
with ~:
> > because they belong / are proper to it.
> >
> > struct ComplexVisualForm {
> > shape : ~ Shape,
> > style : ~ Style,
> > }
>
> It doesn't make sense to use ~T over T without a reason to need a
> pointer-size value. It offers nothing in terms of semantics. It uses
> indirection to obtain pointer-size, and adds a destructor (a strict
> loss in terms of functionality). If you're not writing a recursive
> data structure or using dynamic dispatch via a trait object, you don't
> need it.
>
> > This matches my distinction between things and data (properly speaking).
> > Data, even when pointed (for technological rather than semantic
reasons),
> > still belong to whatever they are part of. Data are never referenced
> > (properly speaking), it makes no sense. Things instead exist by
themselves,
> > are always ref'ed, never copied (or moved), it makes no sense. If the
> > reasoning above about ~ pointers is more or less correct (i doubt it
is),
> > then we have in Rust the proper kind of pointer to point to data,
properly
> > speaking, meaning information about things. Now, to reference things
from
> > multiple points of view, we need something else, proper refs or links,
and
> > they cannot be ordinary pointers (especially not GC'ed): we need true
refs,
> > independant from the data (while pointers hold their addresses).
> >
> > Denis
> >
>
> ~T and T both have value semantics. Neither has by-reference
> semantics, as ~T is always the unique owner of the contained value.
> ___
> 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] Please simplify the syntax for Great Justice

[Liigo Zhuang]

在 2013年11月19日 下午8:41，"Gaetan" 写道：
>
> I think this is precisely one of the bigest issue, from a newbee point of
view. And I agree with spir on this point. It's not that important, but you
end up placing them everywhere "to make the compiler happy".
>
> ~str should be a ~T. If it is not, it should use another semantic.
>
+1

> However, I don't see where you explain this subtility in the tutorial,
didn't you added it recently?
>
> PS: I'm french, I know pretty well that all subtilities (other words for
"exception to the general rules") my natural language has their own reason,
BUT if I wanted to redesign french, I would get rid of all these rules,
exceptions, rules in the exceptions. And exceptions in the rules of
exceptions...
>
> -
> Gaetan
>
>
>
> 2013/11/19 Daniel Micay 
>>
>> On Tue, Nov 19, 2013 at 7:27 AM, Gaetan  wrote:
>> > "The most common use case for owned boxes is creating recursive data
>> > structures like a binary search tree."
>> >
>> > I don't think this is the most common use of owned boxes: string
management,
>> > ...
>> >
>> > I don't think it a good idea to place "binary search tree" in a
tutorial.
>> > You don't do this every day :)
>> >
>> > -
>> > Gaetan
>>
>> ~str isn't an ~T, in the existing type system
>
>
>
> ___
> 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] Please simplify the syntax for Great Justice

[Liigo Zhuang]

在 2013年11月19日 下午8:35，"spir" 写道：
>
> On 11/19/2013 12:51 PM, Daniel Micay wrote:
>>
>> So in your opinion, what's wrong with the `Boxes` section?
>>
>> http://static.rust-lang.org/doc/master/tutorial.html#boxes
>>
>> I happen to think it does a pretty good job of explaining why `~` is
>> required for recursive types, which is almost the only use case for it
>> from a purely semantic perspective (not worrying about performance).
>
>
> If this is all true, that recursive structures are the main, "almost the
only use case" of ~ pointers, then the tutorial is in my view rather ok on
this point. But then, why does it seem there are ~ pointers in every corner
of Rust code? Including numerous cases in the tutorial itself.
>
+1

> Also, how would we explain and term this meaning? "Indirection" is not
good enough (for we introduce indirections for other reasons, if only to
have variable-size content). I'd say "self-similarity" is the right term
here, and self-explaining (see wikipedia if you are not familiar with the
idea). This is, in fact, the actual idea commonly termed "recursivity" in
programming (wrongly, in my view, but this is yet another terminological
issue). A rule about ~ pointers thus may be:
>
>Whenever one needs self-similarity, use a ~ pointer.
>This lets the language store the element through the kind
>of indirection that permits a self-similar structure.
>
> (I'm not happy of this formulation, neither, still obscure.)
>
> however, other comments on ~ pointers (eg comparisons with C++
unique_ptr, notes that it means owned or "my") introduce ideas rather
different from the one you suggest here, don't they? Say I manually create
a kind of string or "fix-size" array:
>
> struct String {
> n_bytes : uint,
> bytes   : ~[u8],
> }
>
> struct Array  {
> n_items : uint,
> items   : ~[Item],
> }
>
> Is it wrong here to ~ point to bytes or items? that's what I'd do,
anyway... If it is right, maybe the actual meaning of ~ is something like
"proper content". Whenever a structure actually contains content which is
actually proper to it, or more generally has (pointed) data participating
to its description, then these contents or descriptive data should pointed
with ~: because they belong / are proper to it.
>
> struct ComplexVisualForm {
> shape : ~ Shape,
> style : ~ Style,
> }
>
> This matches my distinction between things and data (properly speaking).
Data, even when pointed (for technological rather than semantic reasons),
still belong to whatever they are part of. Data are never referenced
(properly speaking), it makes no sense. Things instead exist by themselves,
are always ref'ed, never copied (or moved), it makes no sense. If the
reasoning above about ~ pointers is more or less correct (i doubt it is),
then we have in Rust the proper kind of pointer to point to data, properly
speaking, meaning information about things. Now, to reference things from
multiple points of view, we need something else, proper refs or links, and
they cannot be ordinary pointers (especially not GC'ed): we need true refs,
independant from the data (while pointers hold their addresses).
>
> Denis
>
>
> ___
> 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] Please simplify the syntax for Great Justice

[Liigo Zhuang]

+1
在 2013年11月19日 下午8:27，"Gaetan" 写道：

> "The most common use case for owned boxes is creating recursive data
> structures like a binary search tree."
>
> I don't think this is the most common use of owned boxes: string
> management, ...
>
> I don't think it a good idea to place "binary search tree" in a tutorial.
> You don't do this every day :)
>
> -
> Gaetan
>
>
>
> 2013/11/19 Gaetan 
>
>> In the french presentation for rust 0.8 [1], the author gives the analogy
>> with C++ semantics
>> - ~ is a bit like unique_ptr
>> - @ is an enhanced shared_ptr
>> - borrowed pointer works like C++ reference
>>
>> and I think it was very helpful to better understand them. I don't know
>> if it is true or now, but this comparison helps a lot understanding the
>> concepts.You can present them like this, and after, add more precision, and
>> difference with the C++ counter parts.
>>
>> A tutorial to make would be "Rust for C++ programmer" :)
>>
>>
>> [1] http://linuxfr.org/news/presentation-de-rust-0-8
>>
>> -
>> Gaetan
>>
>>
>>
>> 2013/11/19 Daniel Micay 
>>
>>> On Tue, Nov 19, 2013 at 4:25 AM, Gaetan  wrote:
>>> > I don't think there is any particular issue with the tutorial, but we
>>> need
>>> > more "recipes" on how to handle typical situations.
>>>
>>> I'm specifically talking about the `Boxes` section in the tutorial and
>>> not the whole picture. I keep hearing that the coverage of `~` it's
>>> confusing - so can someone elaborate?
>>>
>>> Rewriting the coverage of boxes and references by walking through the
>>> implementation of some data structures is something I'm willing to do,
>>> but in my opinion that section is now quite good, other than being dry
>>> and not presenting interesting code samples for the use cases it
>>> describes.
>>>
>>
>>
>
> ___
> 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] Please simplify the syntax for Great Justice

[Kevin Ballard]

On Nov 19, 2013, at 3:08 AM, Daniel Micay  wrote:

> I wouldn't mind not having `~T` in the language at all, but am not
> really opposed to including it because there's no harm. Choosing to
> special-case arbitrary non-trivial data structures like vectors and
> reference counted boxes *is* harmful because alternatives should *not*
> be second-class.

Alternatives aren’t second-class, they just aren’t special. Vectors in 
particular are used so ubiquitously that having special syntax is extremely 
convenient.

Anecdotally, Objective-C has moved in the opposite direction to the great 
happiness of all Obj-C developers. NSArray* and NSDictionary* are the 
ubiquitous vector/hashtable implementations that everybody uses, but they 
didn’t have any special language support. Recently, special language support 
was added so I can say @[@“yes”, @“no”, @“maybe”] instead of [NSArray 
arrayWithObjects:@“yes”, @“no”, @“maybe”, nil] (and similar syntax for 
dictionaries, as well as boxed NSNumbers) and it’s made programming in Obj-C 
significantly nicer. There’s nothing stopping you from using other data 
structures, but the special syntax for these particular ubiquitous ones just 
makes everyone’s life easier.

So back to Rust. &[] and its variants are extremely commonly used. Removing the 
special syntax for this will do nothing but make it more annoying to use them. 
It doesn’t do anything to make alternative data structures any easier to use. 
The one suggestion I’d make is maybe provide hooks for the &[] syntax to be 
used for a different vector implementation on a per-crate basis, although this 
would mean that &[] would actually be something like std::vector and &[] is 
just syntactic sugar. Which is generally fine, although it’s awfully nice to 
have &[T] be the actual type name in type signatures, having to use 
std::vector in type signatures and then using [a, b, c] to construct the 
value in code just feels a bit less nice than what we have in Rust today (but 
certainly better than no syntactic sugar at all).

-Kevin___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Gaetan]

However, I want to highlight it is really appreciable that you, the rust
team, are so open to our question.

Just wanted to give you this feedback, I don't want to be held like the guy
who criticize the current work, I know very much that is could be very
annoying.

Just willing to help :)

-
Gaetan



2013/11/19 Gaetan 

> I think this is precisely one of the bigest issue, from a newbee point of
> view. And I agree with spir on this point. It's not that important, but you
> end up placing them everywhere "to make the compiler happy".
>
> ~str should be a ~T. If it is not, it should use another semantic.
>
> However, I don't see where you explain this subtility in the tutorial,
> didn't you added it recently?
>
> PS: I'm french, I know pretty well that all subtilities (other words for
> "exception to the general rules") my natural language has their own reason,
> BUT if I wanted to redesign french, I would get rid of all these rules,
> exceptions, rules in the exceptions. And exceptions in the rules of
> exceptions...
>
> -
> Gaetan
>
>
>
> 2013/11/19 Daniel Micay 
>
>> On Tue, Nov 19, 2013 at 7:27 AM, Gaetan  wrote:
>> > "The most common use case for owned boxes is creating recursive data
>> > structures like a binary search tree."
>> >
>> > I don't think this is the most common use of owned boxes: string
>> management,
>> > ...
>> >
>> > I don't think it a good idea to place "binary search tree" in a
>> tutorial.
>> > You don't do this every day :)
>> >
>> > -
>> > Gaetan
>>
>> ~str isn't an ~T, in the existing type system
>>
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Gaetan]

Sorry, but it's not clear.

the only occurences of "~str" are in "Declaring and implementing traits"
section...
Maybe by adding more "string specific" examples would help...

And a special section one "why ~str is not a ~T" would be so useful!

-
Gaetan



2013/11/19 Daniel Micay 

> On Tue, Nov 19, 2013 at 7:52 AM, Gaetan  wrote:
> > I think it is one of the first thing to explain, actually...
> >
> > Playing with strings, using the method in std or extra requires to
> > understand it. I wanted to use (and improve) extra::url and others (like
> > std::path,...) and... I was simply lost with all of these ~str... and
> > nothing in the manual or tutorial.
> >
> > -
> > Gaetan
>
> It is covered, I rewrote the section on it recently:
>
> http://static.rust-lang.org/doc/master/tutorial.html#vectors-and-strings
>
> It doesn't go out of the way to explain that they're not owned boxes,
> but I don't think it should. It's a confusing language wart and should
> be fixed as far as I am concerned.
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Daniel Micay]

On Tue, Nov 19, 2013 at 7:52 AM, Gaetan  wrote:
> I think it is one of the first thing to explain, actually...
>
> Playing with strings, using the method in std or extra requires to
> understand it. I wanted to use (and improve) extra::url and others (like
> std::path,...) and... I was simply lost with all of these ~str... and
> nothing in the manual or tutorial.
>
> -
> Gaetan

It is covered, I rewrote the section on it recently:

http://static.rust-lang.org/doc/master/tutorial.html#vectors-and-strings

It doesn't go out of the way to explain that they're not owned boxes,
but I don't think it should. It's a confusing language wart and should
be fixed as far as I am concerned.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Gaetan]

I think it is one of the first thing to explain, actually...

Playing with strings, using the method in std or extra requires to
understand it. I wanted to use (and improve) extra::url and others (like
std::path,...) and... I was simply lost with all of these ~str... and
nothing in the manual or tutorial.

-
Gaetan



2013/11/19 Daniel Micay 

> On Tue, Nov 19, 2013 at 7:40 AM, Gaetan  wrote:
> > I think this is precisely one of the bigest issue, from a newbee point of
> > view. And I agree with spir on this point. It's not that important, but
> you
> > end up placing them everywhere "to make the compiler happy".
> >
> > ~str should be a ~T. If it is not, it should use another semantic.
> >
> > However, I don't see where you explain this subtility in the tutorial,
> > didn't you added it recently?
> >
> > PS: I'm french, I know pretty well that all subtilities (other words for
> > "exception to the general rules") my natural language has their own
> reason,
> > BUT if I wanted to redesign french, I would get rid of all these rules,
> > exceptions, rules in the exceptions. And exceptions in the rules of
> > exceptions...
> >
> > -
> > Gaetan
>
> I don't want to have `~str` and `~[T]` in the language, so I'm not
> really motivated to spend time trying to paper over the confusion
> caused by them. I doubt most users of Rust realize that ~([1, 2, 3])
> and ~[1, 2, 3] have different types, and dynamically sized types are
> not going to fix this.
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Daniel Micay]

On Tue, Nov 19, 2013 at 7:40 AM, Gaetan  wrote:
> I think this is precisely one of the bigest issue, from a newbee point of
> view. And I agree with spir on this point. It's not that important, but you
> end up placing them everywhere "to make the compiler happy".
>
> ~str should be a ~T. If it is not, it should use another semantic.
>
> However, I don't see where you explain this subtility in the tutorial,
> didn't you added it recently?
>
> PS: I'm french, I know pretty well that all subtilities (other words for
> "exception to the general rules") my natural language has their own reason,
> BUT if I wanted to redesign french, I would get rid of all these rules,
> exceptions, rules in the exceptions. And exceptions in the rules of
> exceptions...
>
> -
> Gaetan

I don't want to have `~str` and `~[T]` in the language, so I'm not
really motivated to spend time trying to paper over the confusion
caused by them. I doubt most users of Rust realize that ~([1, 2, 3])
and ~[1, 2, 3] have different types, and dynamically sized types are
not going to fix this.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Daniel Micay]

On Tue, Nov 19, 2013 at 7:35 AM, spir  wrote:
>
> If this is all true, that recursive structures are the main, "almost the
> only use case" of ~ pointers, then the tutorial is in my view rather ok on
> this point. But then, why does it seem there are ~ pointers in every corner
> of Rust code? Including numerous cases in the tutorial itself.
>
> Also, how would we explain and term this meaning? "Indirection" is not good
> enough (for we introduce indirections for other reasons, if only to have
> variable-size content). I'd say "self-similarity" is the right term here,
> and self-explaining (see wikipedia if you are not familiar with the idea).
> This is, in fact, the actual idea commonly termed "recursivity" in
> programming (wrongly, in my view, but this is yet another terminological
> issue). A rule about ~ pointers thus may be:
>
>Whenever one needs self-similarity, use a ~ pointer.
>This lets the language store the element through the kind
>of indirection that permits a self-similar structure.
>
> (I'm not happy of this formulation, neither, still obscure.)
>
> however, other comments on ~ pointers (eg comparisons with C++ unique_ptr,
> notes that it means owned or "my") introduce ideas rather different from the
> one you suggest here, don't they? Say I manually create a kind of string or
> "fix-size" array:
>
> struct String {
> n_bytes : uint,
> bytes   : ~[u8],
> }
>
> struct Array  {
> n_items : uint,
> items   : ~[Item],
> }

The expression ~([1, 2, 3]) has a different type than the expression
~[1, 2, 3]. The former is an owned box containing a fixed size array
(~[int, ..3]) and the latter is a dynamic array (~[int]).

The ~str and ~[T] types are *not* owned boxes in the current type
system. There has been a proposal for dynamically sized types which
would make them owned boxes, but I only like it as the path forwards
for traits/closures and not vectors.

I don't think dynamic arrays/strings belong as built-in types
hard-wired into the language, especially with a confusing syntax like
this. They should be treated as other containers are.

In what I think is a sane system, dynamic arrays would be a library
`Vec` type just like we have `HashMap` and will have other
vector types like `Rope` or `SmallVec`.

> Is it wrong here to ~ point to bytes or items? that's what I'd do, anyway...
> If it is right, maybe the actual meaning of ~ is something like "proper
> content". Whenever a structure actually contains content which is actually
> proper to it, or more generally has (pointed) data participating to its
> description, then these contents or descriptive data should pointed with ~:
> because they belong / are proper to it.
>
> struct ComplexVisualForm {
> shape : ~ Shape,
> style : ~ Style,
> }

It doesn't make sense to use ~T over T without a reason to need a
pointer-size value. It offers nothing in terms of semantics. It uses
indirection to obtain pointer-size, and adds a destructor (a strict
loss in terms of functionality). If you're not writing a recursive
data structure or using dynamic dispatch via a trait object, you don't
need it.

> This matches my distinction between things and data (properly speaking).
> Data, even when pointed (for technological rather than semantic reasons),
> still belong to whatever they are part of. Data are never referenced
> (properly speaking), it makes no sense. Things instead exist by themselves,
> are always ref'ed, never copied (or moved), it makes no sense. If the
> reasoning above about ~ pointers is more or less correct (i doubt it is),
> then we have in Rust the proper kind of pointer to point to data, properly
> speaking, meaning information about things. Now, to reference things from
> multiple points of view, we need something else, proper refs or links, and
> they cannot be ordinary pointers (especially not GC'ed): we need true refs,
> independant from the data (while pointers hold their addresses).
>
> Denis
>

~T and T both have value semantics. Neither has by-reference
semantics, as ~T is always the unique owner of the contained value.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Gaetan]

I think this is precisely one of the bigest issue, from a newbee point of
view. And I agree with spir on this point. It's not that important, but you
end up placing them everywhere "to make the compiler happy".

~str should be a ~T. If it is not, it should use another semantic.

However, I don't see where you explain this subtility in the tutorial,
didn't you added it recently?

PS: I'm french, I know pretty well that all subtilities (other words for
"exception to the general rules") my natural language has their own reason,
BUT if I wanted to redesign french, I would get rid of all these rules,
exceptions, rules in the exceptions. And exceptions in the rules of
exceptions...

-
Gaetan



2013/11/19 Daniel Micay 

> On Tue, Nov 19, 2013 at 7:27 AM, Gaetan  wrote:
> > "The most common use case for owned boxes is creating recursive data
> > structures like a binary search tree."
> >
> > I don't think this is the most common use of owned boxes: string
> management,
> > ...
> >
> > I don't think it a good idea to place "binary search tree" in a tutorial.
> > You don't do this every day :)
> >
> > -
> > Gaetan
>
> ~str isn't an ~T, in the existing type system
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[spir]

On 11/19/2013 12:51 PM, Daniel Micay wrote:

So in your opinion, what's wrong with the `Boxes` section?

http://static.rust-lang.org/doc/master/tutorial.html#boxes

I happen to think it does a pretty good job of explaining why `~` is
required for recursive types, which is almost the only use case for it
from a purely semantic perspective (not worrying about performance).


If this is all true, that recursive structures are the main, "almost the only 
use case" of ~ pointers, then the tutorial is in my view rather ok on this 
point. But then, why does it seem there are ~ pointers in every corner of Rust 
code? Including numerous cases in the tutorial itself.


Also, how would we explain and term this meaning? "Indirection" is not good 
enough (for we introduce indirections for other reasons, if only to have 
variable-size content). I'd say "self-similarity" is the right term here, and 
self-explaining (see wikipedia if you are not familiar with the idea). This is, 
in fact, the actual idea commonly termed "recursivity" in programming (wrongly, 
in my view, but this is yet another terminological issue). A rule about ~ 
pointers thus may be:


   Whenever one needs self-similarity, use a ~ pointer.
   This lets the language store the element through the kind
   of indirection that permits a self-similar structure.

(I'm not happy of this formulation, neither, still obscure.)

however, other comments on ~ pointers (eg comparisons with C++ unique_ptr, notes 
that it means owned or "my") introduce ideas rather different from the one you 
suggest here, don't they? Say I manually create a kind of string or "fix-size" 
array:


struct String {
n_bytes : uint,
bytes   : ~[u8],
}

struct Array  {
n_items : uint,
items   : ~[Item],
}

Is it wrong here to ~ point to bytes or items? that's what I'd do, anyway... If 
it is right, maybe the actual meaning of ~ is something like "proper content". 
Whenever a structure actually contains content which is actually proper to it, 
or more generally has (pointed) data participating to its description, then 
these contents or descriptive data should pointed with ~: because they belong / 
are proper to it.


struct ComplexVisualForm {
shape : ~ Shape,
style : ~ Style,
}

This matches my distinction between things and data (properly speaking). Data, 
even when pointed (for technological rather than semantic reasons), still belong 
to whatever they are part of. Data are never referenced (properly speaking), it 
makes no sense. Things instead exist by themselves, are always ref'ed, never 
copied (or moved), it makes no sense. If the reasoning above about ~ pointers is 
more or less correct (i doubt it is), then we have in Rust the proper kind of 
pointer to point to data, properly speaking, meaning information about things. 
Now, to reference things from multiple points of view, we need something else, 
proper refs or links, and they cannot be ordinary pointers (especially not 
GC'ed): we need true refs, independant from the data (while pointers hold their 
addresses).


Denis

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Daniel Micay]

On Tue, Nov 19, 2013 at 7:27 AM, Gaetan  wrote:
> "The most common use case for owned boxes is creating recursive data
> structures like a binary search tree."
>
> I don't think this is the most common use of owned boxes: string management,
> ...
>
> I don't think it a good idea to place "binary search tree" in a tutorial.
> You don't do this every day :)
>
> -
> Gaetan

~str isn't an ~T, in the existing type system
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Gaetan]

"The most common use case for owned boxes is creating recursive data
structures like a binary search tree."

I don't think this is the most common use of owned boxes: string
management, ...

I don't think it a good idea to place "binary search tree" in a tutorial.
You don't do this every day :)

-
Gaetan



2013/11/19 Gaetan 

> In the french presentation for rust 0.8 [1], the author gives the analogy
> with C++ semantics
> - ~ is a bit like unique_ptr
> - @ is an enhanced shared_ptr
> - borrowed pointer works like C++ reference
>
> and I think it was very helpful to better understand them. I don't know if
> it is true or now, but this comparison helps a lot understanding the
> concepts.You can present them like this, and after, add more precision, and
> difference with the C++ counter parts.
>
> A tutorial to make would be "Rust for C++ programmer" :)
>
>
> [1] http://linuxfr.org/news/presentation-de-rust-0-8
>
> -
> Gaetan
>
>
>
> 2013/11/19 Daniel Micay 
>
>> On Tue, Nov 19, 2013 at 4:25 AM, Gaetan  wrote:
>> > I don't think there is any particular issue with the tutorial, but we
>> need
>> > more "recipes" on how to handle typical situations.
>>
>> I'm specifically talking about the `Boxes` section in the tutorial and
>> not the whole picture. I keep hearing that the coverage of `~` it's
>> confusing - so can someone elaborate?
>>
>> Rewriting the coverage of boxes and references by walking through the
>> implementation of some data structures is something I'm willing to do,
>> but in my opinion that section is now quite good, other than being dry
>> and not presenting interesting code samples for the use cases it
>> describes.
>>
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Daniel Glazman]

On 19/11/13 05:17, Patrick Walton wrote:

> I've observed a lot of beginning Rust programmers treat the language as
> "add sigils until it works". (I have specific examples but don't want to
> name people here; however, feel free to contact me privately if you're
> curious.) They end up with slow programs and frustrated with Rust,
> wondering why they had to fight the compiler if they seemingly didn't
> gain any performance from it.
> 
> I think a fair amount of it is that the sigils don't visually convey
> enough information to the programmer; they feel like something that you
> just have to add to make the compiler happy. A sigil in Rust's
> expression grammar as it stands represents an *action*, not a
> *qualifier* as it does in most other languages (e.g. `$foo` in PHP).
> Moreover, the `~` expression maps to one of the most expensive machine
> operations in the entire language semantics! It's thus important in my
> view to emphasize to newcomers that `~` *means* something; it is not
> just a qualifier you have to add to make the compiler happy. Indeed, if
> you are adding it just to make the compiler accept your code, there's
> something wrong--either the API you're using is inefficient or you're
> confused about the semantics!

I agree 1% with what was said above.


___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Gaetan]

+1 semantics is so important

>
> Le 19 nov. 2013 12:22, "spir"  a écrit :
>
>> On 11/19/2013 10:12 AM, Jordi Boggiano wrote:
>>>
>>> Often there is an alternative
>>> to pooping sigils all over the code, but if you don't understand the
>>> concepts behind it it's hard to reason about what those alternatives
>>> could be.
>>
>>
>> +++
>>
>> This is what I'm asking for about pointer variety and memory management
in Rust. What does this all mean? Semantics, please ;-) (I mean human
semantics, no machine operations)
>>
>> Denis
>> ___
>> 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] Please simplify the syntax for Great Justice

[Daniel Micay]

On Tue, Nov 19, 2013 at 6:45 AM, spir  wrote:>
>
> This helped me too, even if I'm not a C++ programmer (can only read).
> However, it is still not enough to understand the meaning of each of those
> pointer varieties, imo (at least, _i_ still don't get it). What semantic
> kinds of pointed data should go to each variety? why? I would help at once
> improving the tutorial if I did understand.
>
> @Daniel: I would answer your questions if I did understand the *logic* of
> Rust's pointers and memory management. The tutorial, in my view, should
> precisely help on this. Instead, it tells us about machine-side issues
> without meaning (which are important and we need to know, but don't help in
> understanding). What is the semantic counter-part of all this? Why does it
> exist?
>
> The logic here is hidden or difficult. As a comparison, we don't need tons
> of explanations to understand the differences between a sequential
> collection (array, list) and, say, a set. The logic is nearly obvious, we
> easily get why both kinds exist. And in fact, the machine-side,
> implementation counterpart, while important, comes after, once we understand
> the meaning; then we get to know the price one has to pay for quick, direct
> access of given items, as opposed to access by index.
>
> Denis

So in your opinion, what's wrong with the `Boxes` section?

http://static.rust-lang.org/doc/master/tutorial.html#boxes

I happen to think it does a pretty good job of explaining why `~` is
required for recursive types, which is almost the only use case for it
from a purely semantic perspective (not worrying about performance).
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[spir]

On 11/19/2013 10:51 AM, Gaetan wrote:

In the french presentation for rust 0.8 [1], the author gives the analogy
with C++ semantics
- ~ is a bit like unique_ptr
- @ is an enhanced shared_ptr
- borrowed pointer works like C++ reference

and I think it was very helpful to better understand them. I don't know if
it is true or now, but this comparison helps a lot understanding the
concepts.You can present them like this, and after, add more precision, and
difference with the C++ counter parts.

A tutorial to make would be "Rust for C++ programmer" :)


[1] http://linuxfr.org/news/presentation-de-rust-0-8


This helped me too, even if I'm not a C++ programmer (can only read). However, 
it is still not enough to understand the meaning of each of those pointer 
varieties, imo (at least, _i_ still don't get it). What semantic kinds of 
pointed data should go to each variety? why? I would help at once improving the 
tutorial if I did understand.


@Daniel: I would answer your questions if I did understand the *logic* of Rust's 
pointers and memory management. The tutorial, in my view, should precisely help 
on this. Instead, it tells us about machine-side issues without meaning (which 
are important and we need to know, but don't help in understanding). What is the 
semantic counter-part of all this? Why does it exist?


The logic here is hidden or difficult. As a comparison, we don't need tons of 
explanations to understand the differences between a sequential collection 
(array, list) and, say, a set. The logic is nearly obvious, we easily get why 
both kinds exist. And in fact, the machine-side, implementation counterpart, 
while important, comes after, once we understand the meaning; then we get to 
know the price one has to pay for quick, direct access of given items, as 
opposed to access by index.


Denis
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[spir]

On 11/19/2013 10:12 AM, Jordi Boggiano wrote:

Often there is an alternative
to pooping sigils all over the code, but if you don't understand the
concepts behind it it's hard to reason about what those alternatives
could be.


+++

This is what I'm asking for about pointer variety and memory management in Rust. 
What does this all mean? Semantics, please ;-) (I mean human semantics, no 
machine operations)


Denis
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[spir]

On 11/19/2013 05:17 AM, Patrick Walton wrote:

On 11/18/13 7:41 PM, Kevin Ballard wrote:

Is that really why, or are you just  guessing? I'm assuming the real
reason is that people are used to languages where heap allocation is
common and stack allocation rare or nonexistant, and don't understand
why boxing everything is a bad idea. In other words, it's a problem that
a proper tutorial should be able to help with. I don't think changing
syntax is going to make much of a difference.


I've observed a lot of beginning Rust programmers treat the language as "add
sigils until it works". (I have specific examples but don't want to name people
here; however, feel free to contact me privately if you're curious.) They end up
with slow programs and frustrated with Rust, wondering why they had to fight the
compiler if they seemingly didn't gain any performance from it.

I think a fair amount of it is that the sigils don't visually convey enough
information to the programmer; they feel like something that you just have to
add to make the compiler happy. A sigil in Rust's expression grammar as it
stands represents an *action*, not a *qualifier* as it does in most other
languages (e.g. `$foo` in PHP). Moreover, the `~` expression maps to one of the
most expensive machine operations in the entire language semantics! It's thus
important in my view to emphasize to newcomers that `~` *means* something; it is
not just a qualifier you have to add to make the compiler happy. Indeed, if you
are adding it just to make the compiler accept your code, there's something
wrong--either the API you're using is inefficient or you're confused about the
semantics!


I share this line of reasoning. However, why not take the opporunity to find a 
proper term (or abbreviation)? "New" says nothing about the "action" or its 
cost. Semantically, every expression yields a "new" value, doesn't it?
(My take as of now would be "mem", as a shortcut for "reserve some memory on the 
heap, where the following piece of data is to be stored; but I don't find it 
great myself. "Alloc" or "store" would be pretty good, but maybe too long.)
Some may think this is just bikeshed; I don't share this view: instead, 
terminology is extremely important, it is what conveys semantics, or should; 
ditto for "key signs". And key terms & signs remain until the end of eternity ;-).


Denis
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Daniel Micay]

On Tue, Nov 19, 2013 at 5:56 AM, Gaetan  wrote:
> Can I advise to have a certain constitency in the semantics?
>
> Not having ~foo, *foo, Rc<>, Gc<>.
>
> I would rather prefere having
>
>   ~foo *foo &foo @foo
>
> of
>
>   Something<>foo, other<>foo, Rc<> foo
>
> By the way, I like pretty much your pronoums thing, this help understanding
> :)
>
> -
> Gaetan

Containers and smart pointers are plain old generic data types, they
don't deserve special construction or type syntax at all in my
opinion. If there's something wrong with Rust's syntax for generics,
lets fix that.

I wouldn't mind not having `~T` in the language at all, but am not
really opposed to including it because there's no harm. Choosing to
special-case arbitrary non-trivial data structures like vectors and
reference counted boxes *is* harmful because alternatives should *not*
be second-class.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Gaetan]

Can I advise to have a certain constitency in the semantics?

Not having ~foo, *foo, Rc<>, Gc<>.

I would rather prefere having

  ~foo *foo &foo @foo

of

  Something<>foo, other<>foo, Rc<> foo

By the way, I like pretty much your pronoums thing, this help understanding
:)

-
Gaetan



2013/11/19 Gábor Lehel 

> In case this helps, I recently noticed that the sigils correspond to
> possessive pronouns:
>
> '~' => "my",
> '&' => "their",
> '@' => "our"
>
> Of course, `@` might be going away, but `Rc<>`, `Gc<>`, and so forth all
> (will) have the same intuitive content, only different representations
> (among other properties). Similarly `~Foo` and plain `Foo` both mean "my",
> while having differences in other areas, in which case yeah, telling you
> that `Foo` is stored in-place while `~Foo` is stored on the heap doesn't
> help you if you don't know what heap allocation is about. But maybe this is
> something.
>
>
> On Tue, Nov 19, 2013 at 10:12 AM, Jordi Boggiano wrote:
>
>> On Tue, Nov 19, 2013 at 5:17 AM, Patrick Walton 
>> wrote:
>> > I've observed a lot of beginning Rust programmers treat the language as
>> "add
>> > sigils until it works". (I have specific examples but don't want to name
>> > people here; however, feel free to contact me privately if you're
>> curious.)
>>
>> I feel like I have to out myself as one of the idiot newcomers that do
>> this, just for the sake of the discussion. I have no systems language
>> background and frankly never had to consider the difference between
>> the heap or the stack in the past 10-some years of writing code.
>>
>> I don't really think having new vs ~ would help me avoid this problem.
>> The issue I believe is that the language looks understandable enough
>> for the average joe used to higher level web languages (php, python,
>> ruby). That's a great thing of course, that I can just jump in and
>> mostly grasp what's going on, while past attempts at C++ tinkering
>> quickly ended in tears. It also means that you have lots of people
>> that come in and are capable of getting stuff to compile but won't
>> necessarily understand the small print. Often there is an alternative
>> to pooping sigils all over the code, but if you don't understand the
>> concepts behind it it's hard to reason about what those alternatives
>> could be.
>>
>> I think I'm getting better with this over time, and the rust libraries
>> also get more usable and consistent leading to less ~ insanity, but
>> one thing that would have helped early on is a good warning in the
>> docs about this, and a good explanation of what the hell is going on
>> (not one geared towards C++ devs using lingo that only low level devs
>> are familiar with).
>>
>> I realize it's no easy task, and that arguably I should probably just
>> read a book, but at the same time it's an amazing feat I think that
>> the language is so accessible while remaining at such a low level, so
>> if we manage to improve the onboarding process it would probably be
>> very beneficial. There are tons of web devs that are interested in
>> doing things faster/lower level - if only for fun. Maybe it's worth
>> having a chapter for them in the docs. I'd happily help review that
>> and point out unclear things :)
>>
>> Cheers
>>
>> --
>> Jordi Boggiano
>> @seldaek - http://nelm.io/jordi
>> ___
>> Rust-dev mailing list
>> Rust-dev@mozilla.org
>> https://mail.mozilla.org/listinfo/rust-dev
>>
>
>
>
> --
> Your ship was destroyed in a monadic eruption.
>
> ___
> 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] Please simplify the syntax for Great Justice

[Gábor Lehel]

In case this helps, I recently noticed that the sigils correspond to
possessive pronouns:

'~' => "my",
'&' => "their",
'@' => "our"

Of course, `@` might be going away, but `Rc<>`, `Gc<>`, and so forth all
(will) have the same intuitive content, only different representations
(among other properties). Similarly `~Foo` and plain `Foo` both mean "my",
while having differences in other areas, in which case yeah, telling you
that `Foo` is stored in-place while `~Foo` is stored on the heap doesn't
help you if you don't know what heap allocation is about. But maybe this is
something.


On Tue, Nov 19, 2013 at 10:12 AM, Jordi Boggiano  wrote:

> On Tue, Nov 19, 2013 at 5:17 AM, Patrick Walton 
> wrote:
> > I've observed a lot of beginning Rust programmers treat the language as
> "add
> > sigils until it works". (I have specific examples but don't want to name
> > people here; however, feel free to contact me privately if you're
> curious.)
>
> I feel like I have to out myself as one of the idiot newcomers that do
> this, just for the sake of the discussion. I have no systems language
> background and frankly never had to consider the difference between
> the heap or the stack in the past 10-some years of writing code.
>
> I don't really think having new vs ~ would help me avoid this problem.
> The issue I believe is that the language looks understandable enough
> for the average joe used to higher level web languages (php, python,
> ruby). That's a great thing of course, that I can just jump in and
> mostly grasp what's going on, while past attempts at C++ tinkering
> quickly ended in tears. It also means that you have lots of people
> that come in and are capable of getting stuff to compile but won't
> necessarily understand the small print. Often there is an alternative
> to pooping sigils all over the code, but if you don't understand the
> concepts behind it it's hard to reason about what those alternatives
> could be.
>
> I think I'm getting better with this over time, and the rust libraries
> also get more usable and consistent leading to less ~ insanity, but
> one thing that would have helped early on is a good warning in the
> docs about this, and a good explanation of what the hell is going on
> (not one geared towards C++ devs using lingo that only low level devs
> are familiar with).
>
> I realize it's no easy task, and that arguably I should probably just
> read a book, but at the same time it's an amazing feat I think that
> the language is so accessible while remaining at such a low level, so
> if we manage to improve the onboarding process it would probably be
> very beneficial. There are tons of web devs that are interested in
> doing things faster/lower level - if only for fun. Maybe it's worth
> having a chapter for them in the docs. I'd happily help review that
> and point out unclear things :)
>
> Cheers
>
> --
> Jordi Boggiano
> @seldaek - http://nelm.io/jordi
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>



-- 
Your ship was destroyed in a monadic eruption.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Daniel Micay]

On Tue, Nov 19, 2013 at 4:51 AM, Gaetan  wrote:
> In the french presentation for rust 0.8 [1], the author gives the analogy
> with C++ semantics
> - ~ is a bit like unique_ptr
> - @ is an enhanced shared_ptr
> - borrowed pointer works like C++ reference
>
> and I think it was very helpful to better understand them. I don't know if
> it is true or now, but this comparison helps a lot understanding the
> concepts.You can present them like this, and after, add more precision, and
> difference with the C++ counter parts.
>
> A tutorial to make would be "Rust for C++ programmer" :)
>
>
> [1] http://linuxfr.org/news/presentation-de-rust-0-8
>
> -
> Gaetan

I wrote a reference for C++ programmers on the wiki some time ago.
Rust is very easy to approach as if you have a solid grasp of C++11 so
I don't think it's an important area to work on.

A C++ programmer already has a thorough understanding of the
ownership/lifetime concepts in Rust and the trait system will be
familiar because C++ has type traits + enable_if and implicit type
"concepts" that aren't formalized in the language yet.

https://github.com/mozilla/rust/wiki/Rust-for-CXX-programmers
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Huon Wilson]

On 19/11/13 20:51, Gaetan wrote:
In the french presentation for rust 0.8 [1], the author gives the 
analogy with C++ semantics

- ~ is a bit like unique_ptr
- @ is an enhanced shared_ptr
- borrowed pointer works like C++ reference

and I think it was very helpful to better understand them. I don't 
know if it is true or now, but this comparison helps a lot 
understanding the concepts.You can present them like this, and after, 
add more precision, and difference with the C++ counter parts.


A tutorial to make would be "Rust for C++ programmer" :)


Something like that already exists: 
https://github.com/mozilla/rust/wiki/Rust-for-CXX-programmers



Huon
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Gaetan]

In the french presentation for rust 0.8 [1], the author gives the analogy
with C++ semantics
- ~ is a bit like unique_ptr
- @ is an enhanced shared_ptr
- borrowed pointer works like C++ reference

and I think it was very helpful to better understand them. I don't know if
it is true or now, but this comparison helps a lot understanding the
concepts.You can present them like this, and after, add more precision, and
difference with the C++ counter parts.

A tutorial to make would be "Rust for C++ programmer" :)


[1] http://linuxfr.org/news/presentation-de-rust-0-8

-
Gaetan



2013/11/19 Daniel Micay 

> On Tue, Nov 19, 2013 at 4:25 AM, Gaetan  wrote:
> > I don't think there is any particular issue with the tutorial, but we
> need
> > more "recipes" on how to handle typical situations.
>
> I'm specifically talking about the `Boxes` section in the tutorial and
> not the whole picture. I keep hearing that the coverage of `~` it's
> confusing - so can someone elaborate?
>
> Rewriting the coverage of boxes and references by walking through the
> implementation of some data structures is something I'm willing to do,
> but in my opinion that section is now quite good, other than being dry
> and not presenting interesting code samples for the use cases it
> describes.
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Daniel Micay]

On Tue, Nov 19, 2013 at 4:25 AM, Gaetan  wrote:
> I don't think there is any particular issue with the tutorial, but we need
> more "recipes" on how to handle typical situations.

I'm specifically talking about the `Boxes` section in the tutorial and
not the whole picture. I keep hearing that the coverage of `~` it's
confusing - so can someone elaborate?

Rewriting the coverage of boxes and references by walking through the
implementation of some data structures is something I'm willing to do,
but in my opinion that section is now quite good, other than being dry
and not presenting interesting code samples for the use cases it
describes.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Gaetan]

I don't think there is any particular issue with the tutorial, but we need
more "recipes" on how to handle typical situations.



-
Gaetan



2013/11/19 Daniel Micay 

> Is there any specific issue with the current tutorial section on
> boxes? It mentions every case where owned boxes are useful.
>
> http://static.rust-lang.org/doc/master/tutorial.html#boxes
>
> I keep hearing that it should be better, but have yet to see any hints
> on where it falls short. It's not going to change if no one can point
> out where it confuses them.
>
> I do want to rewrite it in a less boring style by having it be an
> introduction to these concepts by implementing a linked list, but I
> won't be changing the *content* (at least of Boxes).
> ___
> 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] Please simplify the syntax for Great Justice

[Daniel Micay]

Is there any specific issue with the current tutorial section on
boxes? It mentions every case where owned boxes are useful.

http://static.rust-lang.org/doc/master/tutorial.html#boxes

I keep hearing that it should be better, but have yet to see any hints
on where it falls short. It's not going to change if no one can point
out where it confuses them.

I do want to rewrite it in a less boring style by having it be an
introduction to these concepts by implementing a linked list, but I
won't be changing the *content* (at least of Boxes).
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Jordi Boggiano]

On Tue, Nov 19, 2013 at 5:17 AM, Patrick Walton  wrote:
> I've observed a lot of beginning Rust programmers treat the language as "add
> sigils until it works". (I have specific examples but don't want to name
> people here; however, feel free to contact me privately if you're curious.)

I feel like I have to out myself as one of the idiot newcomers that do
this, just for the sake of the discussion. I have no systems language
background and frankly never had to consider the difference between
the heap or the stack in the past 10-some years of writing code.

I don't really think having new vs ~ would help me avoid this problem.
The issue I believe is that the language looks understandable enough
for the average joe used to higher level web languages (php, python,
ruby). That's a great thing of course, that I can just jump in and
mostly grasp what's going on, while past attempts at C++ tinkering
quickly ended in tears. It also means that you have lots of people
that come in and are capable of getting stuff to compile but won't
necessarily understand the small print. Often there is an alternative
to pooping sigils all over the code, but if you don't understand the
concepts behind it it's hard to reason about what those alternatives
could be.

I think I'm getting better with this over time, and the rust libraries
also get more usable and consistent leading to less ~ insanity, but
one thing that would have helped early on is a good warning in the
docs about this, and a good explanation of what the hell is going on
(not one geared towards C++ devs using lingo that only low level devs
are familiar with).

I realize it's no easy task, and that arguably I should probably just
read a book, but at the same time it's an amazing feat I think that
the language is so accessible while remaining at such a low level, so
if we manage to improve the onboarding process it would probably be
very beneficial. There are tons of web devs that are interested in
doing things faster/lower level - if only for fun. Maybe it's worth
having a chapter for them in the docs. I'd happily help review that
and point out unclear things :)

Cheers

-- 
Jordi Boggiano
@seldaek - http://nelm.io/jordi
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Patrick Walton]

On 11/18/13 7:41 PM, Kevin Ballard wrote:

Is that really why, or are you just  guessing? I'm assuming the real
reason is that people are used to languages where heap allocation is
common and stack allocation rare or nonexistant, and don't understand
why boxing everything is a bad idea. In other words, it's a problem that
a proper tutorial should be able to help with. I don't think changing
syntax is going to make much of a difference.


I've observed a lot of beginning Rust programmers treat the language as 
"add sigils until it works". (I have specific examples but don't want to 
name people here; however, feel free to contact me privately if you're 
curious.) They end up with slow programs and frustrated with Rust, 
wondering why they had to fight the compiler if they seemingly didn't 
gain any performance from it.


I think a fair amount of it is that the sigils don't visually convey 
enough information to the programmer; they feel like something that you 
just have to add to make the compiler happy. A sigil in Rust's 
expression grammar as it stands represents an *action*, not a 
*qualifier* as it does in most other languages (e.g. `$foo` in PHP). 
Moreover, the `~` expression maps to one of the most expensive machine 
operations in the entire language semantics! It's thus important in my 
view to emphasize to newcomers that `~` *means* something; it is not 
just a qualifier you have to add to make the compiler happy. Indeed, if 
you are adding it just to make the compiler accept your code, there's 
something wrong--either the API you're using is inefficient or you're 
confused about the semantics!


Patrick

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Ben Kloosterman]

He said IMHO ..

An explicit "new" is a huge indicator of what is going on ... most people
are familiar enough with stack allocation early adopters are not 9-5
developers..

Ben


On Tue, Nov 19, 2013 at 11:41 AM, Kevin Ballard  wrote:

> Is that really why, or are you just  guessing? I'm assuming the real
> reason is that people are used to languages where heap allocation is common
> and stack allocation rare or nonexistant, and don't understand why boxing
> everything is a bad idea. In other words, it's a problem that a proper
> tutorial should be able to help with. I don't think changing syntax is
> going to make much of a difference.
>
> -Kevin
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Kevin Ballard]

Is that really why, or are you just  guessing? I'm assuming the real reason is 
that people are used to languages where heap allocation is common and stack 
allocation rare or nonexistant, and don't understand why boxing everything is a 
bad idea. In other words, it's a problem that a proper tutorial should be able 
to help with. I don't think changing syntax is going to make much of a 
difference.

-Kevin

On Nov 18, 2013, at 7:09 PM, Patrick Walton  wrote:

> 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  wrote:
> Yes.
> 
> Patrick
> 
> Ziad Hatahet  wrote:
> On Mon, Nov 18, 2013 at 5:34 PM, Patrick Walton  wrote:
> 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

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Gaetan]

More concretely, a good ide with completion, the right snippets and
contextual help is very helpful for learning new language.

I thing this could be a good idea to have an official set of "snippets",
typical every day codes, that can be used to create a common contextual
helps for editors (vim, sublim,...)

When i arrive in a new language, i m used to gather the common "experience"
and write some automatisation tool and documentation to have a unique point
of entry for all "what should i do in this situation". This covers:
- code styling
- source organisation
- file handling (open/close)
- error handling
- for python, import lines organisation
- argument passing...
Le 12 nov. 2013 11:35, "Diggory Hardy"  a écrit :

> My opinion is that clear semantics and good documentation is much more
> important than familiar syntax. Besides, it's not too closely C++ syntax;
> for
> example `let x : T = v` is much closer to Scala's `val x : T = v` than
> C++'s
> `T x = v`. (This is a good choice, as anyone who know's why C++ has a
> `typename` keyword will realise.)
>
> But why is this discussion continuing here? The developers have already
> stated
> that major type changes are not an option for Rust 1.0. I have been
> considering some (fairly major) syntax variations myself, but here is not
> the
> place; if you want to try out some other syntax then why not write a
> compiler
> extension which allows the option of different syntax through a different
> file
> extension (e.g. .rs2) or some such switch?
>
> I for one am not convinced that pure syntax changes can make that big a
> difference; far more interesting would be an interactive IDE which lets the
> programmer write plain English (or restricted English or German or
> Japanese or
> whatever you like) and attempts to infer what code is meant. Of course
> English
> is not precise enough to specify exact code (without a _lot_ of words), so
> the
> interesting part would be how to make the IDE smart enough and interact
> with
> the programmer well enough to produce good code easily. (The point of this
> in
> the first place is to allow the programmer to write things like "sort this
> list" or "give me an n*n identity matrix" without expecting the programmer
> to
> know in advance how the relevant APIs work.)
>
> On Tuesday 12 November 2013 10:59:16 Gábor Lehel wrote:
> > Does anyone have empirical data (or even anecdotes) about whether or not
> > C++ hackers find Rust's syntax appealing? :-)
> >
> > On Tue, Nov 12, 2013 at 10:53 AM, spir  wrote:
> > > On 11/11/2013 09:46 PM, Corey Richardson wrote:
> > >> I don't think Rust can succeed as a language if it massively differs,
> > >> visually, from the language it intends to offset (C++).
> > >
> > > I don't think Rust can succeed as a language if it massively resembles
> > >
> > > the language it intends to offset (C++).
> > >
> > > Denis
> > >
> > > ___
> > > 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] Please simplify the syntax for Great Justice

[Diggory Hardy]

My opinion is that clear semantics and good documentation is much more 
important than familiar syntax. Besides, it's not too closely C++ syntax; for 
example `let x : T = v` is much closer to Scala's `val x : T = v` than C++'s 
`T x = v`. (This is a good choice, as anyone who know's why C++ has a 
`typename` keyword will realise.)

But why is this discussion continuing here? The developers have already stated 
that major type changes are not an option for Rust 1.0. I have been 
considering some (fairly major) syntax variations myself, but here is not the 
place; if you want to try out some other syntax then why not write a compiler 
extension which allows the option of different syntax through a different file 
extension (e.g. .rs2) or some such switch?

I for one am not convinced that pure syntax changes can make that big a 
difference; far more interesting would be an interactive IDE which lets the 
programmer write plain English (or restricted English or German or Japanese or 
whatever you like) and attempts to infer what code is meant. Of course English 
is not precise enough to specify exact code (without a _lot_ of words), so the 
interesting part would be how to make the IDE smart enough and interact with 
the programmer well enough to produce good code easily. (The point of this in 
the first place is to allow the programmer to write things like "sort this 
list" or "give me an n*n identity matrix" without expecting the programmer to 
know in advance how the relevant APIs work.)

On Tuesday 12 November 2013 10:59:16 Gábor Lehel wrote:
> Does anyone have empirical data (or even anecdotes) about whether or not
> C++ hackers find Rust's syntax appealing? :-)
> 
> On Tue, Nov 12, 2013 at 10:53 AM, spir  wrote:
> > On 11/11/2013 09:46 PM, Corey Richardson wrote:
> >> I don't think Rust can succeed as a language if it massively differs,
> >> visually, from the language it intends to offset (C++).
> > 
> > I don't think Rust can succeed as a language if it massively resembles
> > 
> > the language it intends to offset (C++).
> > 
> > Denis
> > 
> > ___
> > Rust-dev mailing list
> > Rust-dev@mozilla.org
> > https://mail.mozilla.org/listinfo/rust-dev

signature.asc
Description: This is a digitally signed message part.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Gábor Lehel]

Does anyone have empirical data (or even anecdotes) about whether or not
C++ hackers find Rust's syntax appealing? :-)


On Tue, Nov 12, 2013 at 10:53 AM, spir  wrote:

> On 11/11/2013 09:46 PM, Corey Richardson wrote:
>
>> I don't think Rust can succeed as a language if it massively differs,
>> visually, from the language it intends to offset (C++).
>>
>
> I don't think Rust can succeed as a language if it massively resembles
>
> the language it intends to offset (C++).
>
> Denis
>
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>



-- 
Your ship was destroyed in a monadic eruption.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[spir]

On 11/11/2013 09:46 PM, Corey Richardson wrote:

I don't think Rust can succeed as a language if it massively differs,
visually, from the language it intends to offset (C++).


I don't think Rust can succeed as a language if it massively resembles
the language it intends to offset (C++).

Denis
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Gaetan]

The name itself is "standard", like "it is the default settings"...
 Le 12 nov. 2013 02:35, "Steven Fackler"  a écrit :

> > base64.rs:
> >let s = [52, 53, 54].to_base64(STANDARD);
> >
> > => why adding the "standard" argument? One will ALWAYS want the
> "STANDARD" method of creating the base64 representation of some bytes, why
> not adding this argument as default.
>
> That is not true. If you are going to be putting the Base64 encoded data
> into a URL you're going to have to use URL_SAFE instead of STANDARD. If
> you're trying to send an email, you'll need to use MIME instead of
> STANDARD. If you're talking to a service that requires one of the ~10 other
> variants of Base64, you'll need to use a custom config struct.
>
> Steven Fackler
>
>
> On Mon, Nov 11, 2013 at 5:23 PM, Brendan Zabarauskas 
> wrote:
>
>> On 12 Nov 2013, at 10:12 am, John Clements 
>> wrote:
>>
>> > If you had the energy to build an alternate front-end using a
>> parenthesized syntax, I'm sure there are others that would give it a try.
>> Me, for instance!
>>
>> It would be nice if we could:
>>
>> - A: desugar Rust into a small kernel language
>> - B: allow rustc to take in some sort of raw AST data (not sure if that’s
>> already possible)
>> - C: have a way of outputting the AST data in a certain syntax.
>>
>> That would allow folks like me to have a nice Haskelly syntax as well as
>> an s-expr style!
>>
>> Heh.
>>
>> ~Brendan
>>
>> ___
>> 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] Please simplify the syntax for Great Justice

[Steven Fackler]

> base64.rs:
>let s = [52, 53, 54].to_base64(STANDARD);
>
> => why adding the "standard" argument? One will ALWAYS want the
"STANDARD" method of creating the base64 representation of some bytes, why
not adding this argument as default.

That is not true. If you are going to be putting the Base64 encoded data
into a URL you're going to have to use URL_SAFE instead of STANDARD. If
you're trying to send an email, you'll need to use MIME instead of
STANDARD. If you're talking to a service that requires one of the ~10 other
variants of Base64, you'll need to use a custom config struct.

Steven Fackler


On Mon, Nov 11, 2013 at 5:23 PM, Brendan Zabarauskas wrote:

> On 12 Nov 2013, at 10:12 am, John Clements 
> wrote:
>
> > If you had the energy to build an alternate front-end using a
> parenthesized syntax, I'm sure there are others that would give it a try.
> Me, for instance!
>
> It would be nice if we could:
>
> - A: desugar Rust into a small kernel language
> - B: allow rustc to take in some sort of raw AST data (not sure if that’s
> already possible)
> - C: have a way of outputting the AST data in a certain syntax.
>
> That would allow folks like me to have a nice Haskelly syntax as well as
> an s-expr style!
>
> Heh.
>
> ~Brendan
>
> ___
> 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] Please simplify the syntax for Great Justice

[Brendan Zabarauskas]

On 12 Nov 2013, at 10:12 am, John Clements  wrote:

> If you had the energy to build an alternate front-end using a parenthesized 
> syntax, I'm sure there are others that would give it a try. Me, for instance!

It would be nice if we could:

- A: desugar Rust into a small kernel language
- B: allow rustc to take in some sort of raw AST data (not sure if that’s 
already possible)
- C: have a way of outputting the AST data in a certain syntax.

That would allow folks like me to have a nice Haskelly syntax as well as an 
s-expr style!

Heh.

~Brendan

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Patrick Walton]

On 11/12/13 9:00 AM, Greg wrote:

Thanks John, for the friendly email. :-)


The choice of the Rust team to adopt a C++-like syntax was very
deliberate, and I'm confident that the members of this team still
believe that was the right choice.


I wonder, right for what reason? Do they actually */like*/ it? I wrote a
lot of code in C++ back in the day. Can't touch the stuff anymore.
*shudders*


I prefer C-like (Algol-like, if you want to be pedantic :)) syntax to 
S-expressions.


Patrick

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Greg]

On Nov 11, 2013, at 7:05 PM, Tim Chevalier  wrote:
> Also, please avoid
> suggesting that people who do or don't like a particular syntax
> haven't expanded their mind; it's okay for different people to have
> different opinions about language design, and choosing any one
> approach doesn't mean we think less of people who prefer other ones.

I probably could have phrased that better to avoid misunderstandings. No 
offense was intended.

The comment is a reference to anyone who is unfamiliar with the syntax of 
non-C-type languages. It's not a reference to anyone familiar with various 
syntaxes (C-type and others) and prefers C++.

No superiority-complex, condescension, or anything of that sort was intended, 
please don't misunderstand.

Kind regards,
Greg

--
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] Please simplify the syntax for Great Justice

[Tim Chevalier]

Mod hat: This thread has become pretty off-topic. Let's wind it down
and move any specific questions or concrete proposals regarding Rust
to a new, separate thread.

Please familiarize yourself with the "Conduct" section of
https://github.com/mozilla/rust/wiki/Note-development-policy ,
particularly these parts:

"Respect that people have differences of opinion and that every design
or implementation choice carries a trade-off and numerous costs. There
is seldom a right answer.
Please keep unstructured critique to a minimum. If you have solid
ideas you want to experiment with, make a fork and see how it works."

In particular, discussing the merits or lack thereof of C or Java
syntax is out of scope for this mailing list. I understand that this
subject came up because it was cited as a reason for Rust's syntax,
but as several people have said, these decisions have been made and
won't be revisited (except, *perhaps*, in the presence of a concrete
proposal and preferably an implementation). Also, please avoid
suggesting that people who do or don't like a particular syntax
haven't expanded their mind; it's okay for different people to have
different opinions about language design, and choosing any one
approach doesn't mean we think less of people who prefer other ones.

Cheers,
Tim


On Mon, Nov 11, 2013 at 4:00 PM, Greg  wrote:
> Thanks John, for the friendly email. :-)
>
> The choice of the Rust team to adopt a C++-like syntax was very deliberate,
> and I'm confident that the members of this team still believe that was the
> right choice.
>
>
> I wonder, right for what reason? Do they actually *like* it? I wrote a lot
> of code in C++ back in the day. Can't touch the stuff anymore. *shudders*
>
> Or is it 'right' because it's familiar to C++ developers?
>
> I should have mentioned Java in my original post to the list.
>
> Java is relevant for a few reasons:
>
> 1. It has been around for a long time.
> 2. It's quite popular.
> 3. It's C-like, familiar, and attempts to implement some safety into the
> language
> 4. Its syntax is fairly simple (compared to C++).
>
> And most significantly of all:
>
> 5. It has gone through some significant syntactic changes, _years_ after
> being well established and well known.
>
> For example, Java 1.5 added Generics to the language (a simplified version
> of C++ templates).
>
> The recent Java has added anonymous functions (lambdas).
>
> Other well established languages have also made significant changes to their
> syntax well after their first birthday. Objective-C, for example, added
> properties and Automatic Reference Counting in with it turned 2.0.
>
> It also added syntax for various literals (arrays, maps, etc.):
> http://clang.llvm.org/docs/ObjectiveCLiterals.html
>
> So, given the history of these well established languages, I think there's
> still plenty of opportunity for change with Rust. More so, in fact, due to
> its alpha status. It's easier to remove syntax while a language is young,
> and Rust is still very young.
>
> With that said, though, Rust is a new and exciting language; if you can
> think of improvements, try coding them up and see what you get! In my
> experience, the Rust developers are always happy to hear from volunteers who
> are excited about the language and have concrete pull requests. If you had
> the energy to build an alternate front-end using a parenthesized syntax, I'm
> sure there are others that would give it a try. Me, for instance!
>
>
> I'd love to, but zero time at the moment. :-(
>
> Also, I'm not simply advocating a parenthesis-based syntax (though that
> would be *awesome*!). I think the present syntax is malleable and can be
> simplified and improved while retaining its C-ness for the sake of
> developers who haven't quite yet expanded their minds... :-p
>
> Cheers,
> Greg
>
> --
> Please do not email me anything that you are not comfortable also sharing
> with the NSA.
>
> On Nov 11, 2013, at 6:12 PM, John Clements 
> wrote:
>
>
> On Nov 11, 2013, at 1:07 PM, Greg wrote:
>
> I don't think Rust can succeed as a language if it massively differs,
> visually, from the language it intends to offset (C++).
>
>
> Yes, I agree, and that's why I wrote:
>
> "By this point, I'm aware that this is unlikely to happen."
>
>
> ...
>
> However, during those many years, did any of the brains that were involved
> in designing the syntax seriously consider Clojure's syntax, or Typed
> Clojure?
>
> I'm almost certain that the answer is "no" (partly because these
> languages/dialects did not exist at the time).
>
> What about Lua, which is more C-like?
>
> Or CoffeeScript?
>
>
> Greg, thanks for your comments!
>
> In fact, nearly all of the designers of Rust are deeply familiar with the
> syntactic conventions of these and other languages.  Speaking only for
> myself, I come from Racket, and I'm a strong proponent of fully
> parenthesized syntaxes.
>
> But!
>
> Rust is not that language.  As you suggest (and others confirm), that train
> left the 

Re: [rust-dev] Please simplify the syntax for Great Justice

[Daniel Micay]

On Mon, Nov 11, 2013 at 6:52 PM, Gaetan  wrote:

>
> For instance url.rs. To parse a string, you have to write this:
>
> let u = url::from_str(urlstring).unwrap();
>
> I would propose this solution:
>
> let u = parse_url(urlstring);
>
>
> => simpler, easier to read, easier to remember !
> Of course, the unwrap thing would still be here.
>

Rust generally uses sum types to report errors. The `from_str` method
doesn't work for all inputs, so it returns `None` in those cases. The
ability to handle errors does need to be there, and forcing a concious
decision on how to handle common, easily recoverable errors makes a lot of
sense to me.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Tim Chevalier]

On Mon, Nov 11, 2013 at 3:52 PM, Gaetan  wrote:
> Can we have Two rust?
>
> The first one would be easy to learn, easy to read, and do most of ones
> would expect: on demand garbage collector, traits, Owned pointers,...
>
> The second one would include all advanced feature we actually don t need
> everyday.
>
> Of course, we don t want to split the language, but rather présent the
> current things differently. The tutorials are a good starting point however,
> the rest of the documentations are quite complex. I would be very delighted
> to help on this matter. There could be some effort on simplification of the
> API (std/extra): provides just "the right functions" first, and allow all
> flexibility in a second step, maybe in an "advanced functions" parts in each
> API doc.

We always welcome documentation patches!

A more ambitious project would be to add "language levels" to Rust
(like Racket has). If you were interested in pursuing this, you would
want to discuss it with members of the core team. I doubt it would be
accepted as a patch in the short term (since it's not a 1.0 priority),
but in the long term, it's certainly possible.

Cheers,
Tim

>
> For instance url.rs. To parse a string, you have to write this:
>
> let u = url::from_str(urlstring).unwrap();
>
> I would propose this solution:
>
> let u = parse_url(urlstring);
>
>
> => simpler, easier to read, easier to remember !
> Of course, the unwrap thing would still be here.
>
> base64.rs:
>
> let s = [52, 53, 54].to_base64(STANDARD);
>
>
> => why adding the "standard" argument? One will ALWAYS want the "STANDARD"
> method of creating the base64 representation of some bytes, why not adding
> this argument as default.
>
> There are some minor change to the API that would help a lot the learning of
> this language, along with adding more code sample in the documentation.
>
> After year of writing C++ code with complex API (boost) I enjoy writing with
> python which seems to provide just the right methods I need.
>
> I'll willing to help, but I don't easily find a easy starting point :)
>
> Gaetan
>
> Le lundi 11 novembre 2013, Brian Anderson a écrit :
>
>> On 11/11/2013 01:07 PM, Greg wrote:
>>
>> I don't think Rust can succeed as a language if it massively differs,
>> visually, from the language it intends to offset (C++).
>>
>>
>> Yes, I agree, and that's why I wrote:
>>
>> "By this point, I'm aware that this is unlikely to happen."
>>
>> I think it's still possible to simplify Rust's existing syntax while
>> maintaining the features it offers.
>>
>> I am hoping that the developers of Rust will consider this issue important
>> enough to put more thought into it.
>>
>> I am aware that I am jumping into an issue at a point in time that's
>> considered "late in the game".
>>
>> From the outside, I can say (with confidence), that Rust is still a nearly
>> unheard-of language, and therefore it still has wiggle-room for improvement,
>> even if the Rust developers and community, because they have been immersed
>> in the language for quite some time, cannot see that this is in fact true.
>>
>> I also believe Tim when he said that years of effort went into designing
>> the syntax.
>>
>> However, during those many years, did any of the brains that were involved
>> in designing the syntax seriously consider Clojure's syntax, or Typed
>> Clojure?
>>
>> I'm almost certain that the answer is "no" (partly because these
>> languages/dialects did not exist at the time).
>>
>> What about Lua, which is more C-like?
>>
>> Or CoffeeScript?
>>
>> Looking at the "Influenced By" section on Wikipedia seems to indicate that
>> the answer to these questions is, again, "no".
>>
>>
>> The answer is 'yes'. The designers of Rust are well aware of these
>> languages and many others and have debated syntax issues repeatedly (as it
>> is the most beloved pasttime of language designers). The current syntax was
>> designed very intentionally the way it is.
>>
>>
>
> ___
> 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] Please simplify the syntax for Great Justice

[Greg]

Thanks John, for the friendly email. :-)

> The choice of the Rust team to adopt a C++-like syntax was very deliberate, 
> and I'm confident that the members of this team still believe that was the 
> right choice.

I wonder, right for what reason? Do they actually *like* it? I wrote a lot of 
code in C++ back in the day. Can't touch the stuff anymore. *shudders*

Or is it 'right' because it's familiar to C++ developers?

I should have mentioned Java in my original post to the list.

Java is relevant for a few reasons:

1. It has been around for a long time.
2. It's quite popular.
3. It's C-like, familiar, and attempts to implement some safety into the 
language
4. Its syntax is fairly simple (compared to C++).

And most significantly of all:

5. It has gone through some significant syntactic changes, _years_ after being 
well established and well known.

For example, Java 1.5 added Generics to the language (a simplified version of 
C++ templates).

The recent Java has added anonymous functions (lambdas).

Other well established languages have also made significant changes to their 
syntax well after their first birthday. Objective-C, for example, added 
properties and Automatic Reference Counting in with it turned 2.0.

It also added syntax for various literals (arrays, maps, etc.): 
http://clang.llvm.org/docs/ObjectiveCLiterals.html

So, given the history of these well established languages, I think there's 
still plenty of opportunity for change with Rust. More so, in fact, due to its 
alpha status. It's easier to remove syntax while a language is young, and Rust 
is still very young.

> With that said, though, Rust is a new and exciting language; if you can think 
> of improvements, try coding them up and see what you get! In my experience, 
> the Rust developers are always happy to hear from volunteers who are excited 
> about the language and have concrete pull requests. If you had the energy to 
> build an alternate front-end using a parenthesized syntax, I'm sure there are 
> others that would give it a try. Me, for instance!

I'd love to, but zero time at the moment. :-(

Also, I'm not simply advocating a parenthesis-based syntax (though that would 
be *awesome*!). I think the present syntax is malleable and can be simplified 
and improved while retaining its C-ness for the sake of developers who haven't 
quite yet expanded their minds... :-p

Cheers,
Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Nov 11, 2013, at 6:12 PM, John Clements  wrote:

> 
> On Nov 11, 2013, at 1:07 PM, Greg wrote:
> 
>>> I don't think Rust can succeed as a language if it massively differs,
>>> visually, from the language it intends to offset (C++).
>> 
>> Yes, I agree, and that's why I wrote:
>> 
>>  "By this point, I'm aware that this is unlikely to happen."
>> 
> 
> ...
> 
>> However, during those many years, did any of the brains that were involved 
>> in designing the syntax seriously consider Clojure's syntax, or Typed 
>> Clojure?
>> 
>> I'm almost certain that the answer is "no" (partly because these 
>> languages/dialects did not exist at the time).
>> 
>> What about Lua, which is more C-like?
>> 
>> Or CoffeeScript?
> 
> Greg, thanks for your comments!
> 
> In fact, nearly all of the designers of Rust are deeply familiar with the 
> syntactic conventions of these and other languages.  Speaking only for 
> myself, I come from Racket, and I'm a strong proponent of fully parenthesized 
> syntaxes.
> 
> But! 
> 
> Rust is not that language.  As you suggest (and others confirm), that train 
> left the station long, long ago. The choice of the Rust team to adopt a 
> C++-like syntax was very deliberate, and I'm confident that the members of 
> this team still believe that was the right choice.
> 
> With that said, though, Rust is a new and exciting language; if you can think 
> of improvements, try coding them up and see what you get! In my experience, 
> the Rust developers are always happy to hear from volunteers who are excited 
> about the language and have concrete pull requests. If you had the energy to 
> build an alternate front-end using a parenthesized syntax, I'm sure there are 
> others that would give it a try. Me, for instance!
> 
> All the best,
> 
> John Clements
> 



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] Please simplify the syntax for Great Justice

[Gaetan]

Can we have Two rust?

The first one would be easy to learn, easy to read, and do most of ones
would expect: on demand garbage collector, traits, Owned pointers,...

The second one would include all advanced feature we actually don t
need everyday.

Of course, we don t want to split the language, but rather présent the
current things differently. The tutorials are a good starting point
however, the rest of the documentations are quite complex. I would be very
delighted to help on this matter. There could be some effort on
simplification of the API (std/extra): provides just "the right functions"
first, and allow all flexibility in a second step, maybe in an "advanced
functions" parts in each API doc.

For instance url.rs. To parse a string, you have to write this:

let u = url::from_str(urlstring).unwrap();

I would propose this solution:

let u = parse_url(urlstring);


=> simpler, easier to read, easier to remember !
Of course, the unwrap thing would still be here.

base64.rs:

let s = [52, 53, 54].to_base64(STANDARD);


=> why adding the "standard" argument? One will ALWAYS want the "STANDARD"
method of creating the base64 representation of some bytes, why not adding
this argument as default.

There are some minor change to the API that would help a lot the learning
of this language, along with adding more code sample in the documentation.

After year of writing C++ code with complex API (boost) I enjoy writing
with python which seems to provide just the right methods I need.

I'll willing to help, but I don't easily find a easy starting point :)

Gaetan

Le lundi 11 novembre 2013, Brian Anderson a écrit :

>  On 11/11/2013 01:07 PM, Greg wrote:
>
>  I don't think Rust can succeed as a language if it massively differs,
> visually, from the language it intends to offset (C++).
>
>
>  Yes, I agree, and that's why I wrote:
>
>  * "By this point, I'm aware that this is unlikely to happen."*
>
>  I think it's still possible to simplify Rust's existing syntax while
> maintaining the features it offers.
>
>  I am hoping that the developers of Rust will consider this issue
> important enough to put more thought into it.
>
>  I am aware that I am jumping into an issue at a point in time that's
> considered "late in the game".
>
>  From the outside, I can say (with confidence), that Rust is still a
> nearly unheard-of language, and therefore it still has wiggle-room for
> improvement, even if the Rust developers and community, because they have
> been immersed in the language for quite some time, cannot see that this is
> in fact true.
>
>  I also believe Tim when he said that years of effort went into designing
> the syntax.
>
>  However, during those many years, did any of the brains that were
> involved in designing the syntax seriously consider Clojure's syntax, or
> Typed Clojure?
>
>  I'm almost certain that the answer is "no" (partly because these
> languages/dialects did not exist at the time).
>
>  What about Lua, which is more C-like?
>
>  Or CoffeeScript?
>
>  Looking at the "Influenced By" section on Wikipedia seems to indicate
> that the answer to these questions is, again, "no".
>
>
> The answer is 'yes'. The designers of Rust are well aware of these
> languages and many others and have debated syntax issues repeatedly (as it
> is the most beloved pasttime of language designers). The current syntax was
> designed very intentionally the way it is.
>
>
>
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[John Clements]

On Nov 11, 2013, at 1:07 PM, Greg wrote:

>> I don't think Rust can succeed as a language if it massively differs,
>> visually, from the language it intends to offset (C++).
> 
> Yes, I agree, and that's why I wrote:
> 
>   "By this point, I'm aware that this is unlikely to happen."
> 

...

> However, during those many years, did any of the brains that were involved in 
> designing the syntax seriously consider Clojure's syntax, or Typed Clojure?
> 
> I'm almost certain that the answer is "no" (partly because these 
> languages/dialects did not exist at the time).
> 
> What about Lua, which is more C-like?
> 
> Or CoffeeScript?

Greg, thanks for your comments!

In fact, nearly all of the designers of Rust are deeply familiar with the 
syntactic conventions of these and other languages.  Speaking only for myself, 
I come from Racket, and I'm a strong proponent of fully parenthesized syntaxes.

But! 

Rust is not that language.  As you suggest (and others confirm), that train 
left the station long, long ago. The choice of the Rust team to adopt a 
C++-like syntax was very deliberate, and I'm confident that the members of this 
team still believe that was the right choice.

With that said, though, Rust is a new and exciting language; if you can think 
of improvements, try coding them up and see what you get! In my experience, the 
Rust developers are always happy to hear from volunteers who are excited about 
the language and have concrete pull requests. If you had the energy to build an 
alternate front-end using a parenthesized syntax, I'm sure there are others 
that would give it a try. Me, for instance!

All the best,

John Clements

___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Brian Anderson]

On 11/11/2013 01:07 PM, Greg wrote:

I don't think Rust can succeed as a language if it massively differs,
visually, from the language it intends to offset (C++).


Yes, I agree, and that's why I wrote:

/"By this point, I'm aware that this is unlikely to happen."/

I think it's still possible to simplify Rust's existing syntax while 
maintaining the features it offers.


I am hoping that the developers of Rust will consider this issue 
important enough to put more thought into it.


I am aware that I am jumping into an issue at a point in time that's 
considered "late in the game".


From the outside, I can say (with confidence), that Rust is still a 
nearly unheard-of language, and therefore it still has wiggle-room for 
improvement, even if the Rust developers and community, because they 
have been immersed in the language for quite some time, cannot see 
that this is in fact true.


I also believe Tim when he said that years of effort went into 
designing the syntax.


However, during those many years, did any of the brains that were 
involved in designing the syntax seriously consider Clojure's syntax, 
or Typed Clojure?


I'm almost certain that the answer is "no" (partly because these 
languages/dialects did not exist at the time).


What about Lua, which is more C-like?

Or CoffeeScript?

Looking at the "Influenced By" section on Wikipedia seems to indicate 
that the answer to these questions is, again, "no".


The answer is 'yes'. The designers of Rust are well aware of these 
languages and many others and have debated syntax issues repeatedly (as 
it is the most beloved pasttime of language designers). The current 
syntax was designed very intentionally the way it is.



___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Thad Guidry]

>From the outside looking in...

I do not see anything preventing Greg from producing many macros or an
entire syntax sub-system to emulate and empower him with any sugary
languages that he might prefer or desire.  It is just going to be quite a
bit of work for him, but he could do it himself, if we wanted to turn
Rust's syntax into something closer to Type Clojure or create a DSL.

 Is that not true ?



On Mon, Nov 11, 2013 at 3:28 PM, Corey Richardson  wrote:

> On Mon, Nov 11, 2013 at 4:07 PM, Greg  wrote:
> > I don't think Rust can succeed as a language if it massively differs,
> > visually, from the language it intends to offset (C++).
> >
> > Yes, I agree, and that's why I wrote:
> >
> > "By this point, I'm aware that this is unlikely to happen."
> >
> > I think it's still possible to simplify Rust's existing syntax while
> > maintaining the features it offers.
> >
>
> My point is that the familiar syntax *is* a feature. What
> simplifications do you propose? I think everyone is mostly happy with
> the syntax at this point, so your proposed changes and justification
> are going to be very pursuasive, and followed by a PR, for there to be
> a chance of them being accepted.
> ___
> Rust-dev mailing list
> Rust-dev@mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
>



-- 
-Thad
+ThadGuidry 
Thad on LinkedIn 
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Corey Richardson]

On Mon, Nov 11, 2013 at 4:07 PM, Greg  wrote:
> I don't think Rust can succeed as a language if it massively differs,
> visually, from the language it intends to offset (C++).
>
> Yes, I agree, and that's why I wrote:
>
> "By this point, I'm aware that this is unlikely to happen."
>
> I think it's still possible to simplify Rust's existing syntax while
> maintaining the features it offers.
>

My point is that the familiar syntax *is* a feature. What
simplifications do you propose? I think everyone is mostly happy with
the syntax at this point, so your proposed changes and justification
are going to be very pursuasive, and followed by a PR, for there to be
a chance of them being accepted.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Andrew Webb]

Hi,

I am just a lurker as well, so take all of this with a good dose of salt...


> At the same time, I am disappointed and quite concerned about Rust's
> unimaginative syntax.
>

It seems to preserve decades of poor decision-making from C++.
>
>
Personally, I find it very pleasant. There are a few things I would have
done differently (mostly to do using full names for e.g., function), but
that is all window dressing.



>
> To the contrary, a simpler syntax will likely lead to increased
> flexibility and possibilities. Lisp has demonstrated unequivocally.
>
> "Typed Clojure" may provide the authors with needed inspiration:
>
>
Clojure is my main language, so don't take this as an attack on it (or
lisps in general), but the "flexibility" that those languages show is at
least in part due to the dynamic type system. Even typed clojure (and typed
racket)  are dynamically typed, but with posthoc type checking. Although
there are many benefits to dynamic typing, neither efficiency, nor provable
safety are usually counted amongst them.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Greg]

> I don't think Rust can succeed as a language if it massively differs,
> visually, from the language it intends to offset (C++).


Yes, I agree, and that's why I wrote:

"By this point, I'm aware that this is unlikely to happen."

I think it's still possible to simplify Rust's existing syntax while 
maintaining the features it offers.

I am hoping that the developers of Rust will consider this issue important 
enough to put more thought into it.

I am aware that I am jumping into an issue at a point in time that's considered 
"late in the game".

From the outside, I can say (with confidence), that Rust is still a nearly 
unheard-of language, and therefore it still has wiggle-room for improvement, 
even if the Rust developers and community, because they have been immersed in 
the language for quite some time, cannot see that this is in fact true.

I also believe Tim when he said that years of effort went into designing the 
syntax.

However, during those many years, did any of the brains that were involved in 
designing the syntax seriously consider Clojure's syntax, or Typed Clojure?

I'm almost certain that the answer is "no" (partly because these 
languages/dialects did not exist at the time).

What about Lua, which is more C-like?

Or CoffeeScript?

Looking at the "Influenced By" section on Wikipedia seems to indicate that the 
answer to these questions is, again, "no".

The list contains some bad role models (in terms of syntactic elegance and 
simplicity): C++, Haskell, OCaml, and Ruby.

Thankfully Common Lisp is mentioned. Although, of the Lisps I'm familiar with, 
Common Lisp has the ugliest syntax (still better than C++ though).

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.

And I think that's quite unfortunate for Rust.

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.

- 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++).



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] Please simplify the syntax for Great Justice

[Corey Richardson]

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

Re: [rust-dev] Please simplify the syntax for Great Justice

[Greg]

> At this state in Rust's development, we are unlikely to make any major
> changes to Rust's syntax. 

*cries*

> I encourage you to check out Rust's syntax extension / macro system:
> http://static.rust-lang.org/doc/master/tutorial-macros.html

*clicks link*

O_O

*cries more*

:'-(

I'm not sure what stage I'm at right now: 
https://en.wikipedia.org/wiki/K%C3%BCbler-Ross_model#Stages

Either 3 (Bargaining), or 4 (Depression).

- Greg

--
Please do not email me anything that you are not comfortable also sharing with 
the NSA.

On Nov 11, 2013, at 3:33 PM, Tim Chevalier  wrote:

> Hi, Greg --
> 
> At this state in Rust's development, we are unlikely to make any major
> changes to Rust's syntax. Literally years of effort have gone into
> desgining the syntax, and at this point in the language's development,
> our focus is on making any non-backwards-compatible changes in
> preparation for releasing 1.0.
> 
> I encourage you to check out Rust's syntax extension / macro system:
> 
> http://static.rust-lang.org/doc/master/tutorial-macros.html
> 
> and explore how that can be used to extend the base syntax.
> 
> Cheers,
> Tim
> 
> 
> On Mon, Nov 11, 2013 at 12:27 PM, Greg  wrote:
>> Dear Mozilla, rust devs, and memory-safe enthusiasts everywhere,
>> 
>> I'm very happy with the safety improvements that Rust brings.
>> 
>> This is true innovation.
>> 
>> At the same time, I am disappointed and quite concerned about Rust's 
>> unimaginative syntax.
>> 
>> It seems to preserve decades of poor decision-making from C++.
>> 
>> The FAQ states: "The syntax is still evolving"
>> 
>> I hope this is still true today. Syntax plays a significant role in safety:
>> 
>> 1. Simple syntax makes software easier to write.
>> 2. Simple syntax makes software easier to understand.
>> 3. Simple syntax makes inserting a backdoor into an open source project more 
>> difficult.
>> 4. Simple syntax leads to fewer mistakes.
>> 
>> Were I to have written Rust, I would have modeled its syntax after 
>> Clojure/Lisp/Scheme instead of C++ [1]. By this point, I'm aware that this 
>> is unlikely to happen.
>> 
>> However, I would like to ask the Rust architects to seriously consider this 
>> issue, and ask themselves what syntax they can remove from the language 
>> while maintaining type-safety.
>> 
>> Removing syntax should not raise any fears that the language will lose any 
>> features or flexibility.
>> 
>> To the contrary, a simpler syntax will likely lead to increased flexibility 
>> and possibilities. Lisp has demonstrated unequivocally.
>> 
>> "Typed Clojure" may provide the authors with needed inspiration:
>> 
>> https://github.com/clojure/core.typed/wiki
>> https://s3.amazonaws.com/github/downloads/frenchy64/papers/ambrose-honours.pdf
>> 
>> Kind regards,
>> Greg
>> 
>> [1] 
>> https://www.taoeffect.com/blog/2010/01/how-newlisp-took-my-breath-and-syntax-away/
>> 
>> --
>> 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
>> 
> 
> 
> 
> -- 
> 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



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] Please simplify the syntax for Great Justice

[Gregory Maxwell]

On Mon, Nov 11, 2013 at 12:27 PM, Greg  wrote:
> Dear Mozilla, rust devs, and memory-safe enthusiasts everywhere,
>
> I'm very happy with the safety improvements that Rust brings.
>
> This is true innovation.
>
> At the same time, I am disappointed and quite concerned about Rust's 
> unimaginative syntax.
[...]

I'm not a rust developer— so consider my comments accordingly worthless.

But what you're asking for here is very non-specific. Basically you
expect that I should study a number of other languages in general and
then infer which specific syntactic changes you might prefer. I think
thats asking a little too much.

My general impression is that the time for broad bike-shedding of the
whole syntactic strategy has passed, ... but regardless of how broad
or narrow the changes you hope to see happen, specific and actionable
examples of places where the current syntax creates avoidable traps
for programmers (esp. where they can't be fixed with a suitable use of
macros) would likely be much more helpful than a general call for
syntax minimalism.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Please simplify the syntax for Great Justice

[Tim Chevalier]

Hi, Greg --

At this state in Rust's development, we are unlikely to make any major
changes to Rust's syntax. Literally years of effort have gone into
desgining the syntax, and at this point in the language's development,
our focus is on making any non-backwards-compatible changes in
preparation for releasing 1.0.

I encourage you to check out Rust's syntax extension / macro system:

http://static.rust-lang.org/doc/master/tutorial-macros.html

and explore how that can be used to extend the base syntax.

Cheers,
Tim


On Mon, Nov 11, 2013 at 12:27 PM, Greg  wrote:
> Dear Mozilla, rust devs, and memory-safe enthusiasts everywhere,
>
> I'm very happy with the safety improvements that Rust brings.
>
> This is true innovation.
>
> At the same time, I am disappointed and quite concerned about Rust's 
> unimaginative syntax.
>
> It seems to preserve decades of poor decision-making from C++.
>
> The FAQ states: "The syntax is still evolving"
>
> I hope this is still true today. Syntax plays a significant role in safety:
>
> 1. Simple syntax makes software easier to write.
> 2. Simple syntax makes software easier to understand.
> 3. Simple syntax makes inserting a backdoor into an open source project more 
> difficult.
> 4. Simple syntax leads to fewer mistakes.
>
> Were I to have written Rust, I would have modeled its syntax after 
> Clojure/Lisp/Scheme instead of C++ [1]. By this point, I'm aware that this is 
> unlikely to happen.
>
> However, I would like to ask the Rust architects to seriously consider this 
> issue, and ask themselves what syntax they can remove from the language while 
> maintaining type-safety.
>
> Removing syntax should not raise any fears that the language will lose any 
> features or flexibility.
>
> To the contrary, a simpler syntax will likely lead to increased flexibility 
> and possibilities. Lisp has demonstrated unequivocally.
>
> "Typed Clojure" may provide the authors with needed inspiration:
>
> https://github.com/clojure/core.typed/wiki
> https://s3.amazonaws.com/github/downloads/frenchy64/papers/ambrose-honours.pdf
>
> Kind regards,
> Greg
>
> [1] 
> https://www.taoeffect.com/blog/2010/01/how-newlisp-took-my-breath-and-syntax-away/
>
> --
> 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
>



-- 
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