On Tuesday, 18 December 2012 at 07:36:26 UTC, Marcel wrote:
Rust designers seems to love really short keywords, this is in
my opinion a bit silly. On the other hand in D you have
keywords like immutable that are rather long to type. So I
prefer a mid way between those two.
They aren't silly,
Marcel:
Rust designers seems to love really short keywords, this is in
my opinion a bit silly. On the other hand in D you have
keywords like immutable that are rather long to type. So I
prefer a mid way between those two.
They aren't silly, they're consistent. We have int, char, auto,
they
On 12/18/2012 4:35 AM, bearophile wrote:
in general the
naming choice of D is better than Rust.
A red letter day for D! Bearophile says that D does something better than some
other language!
:-)
Rust designers seems to love really short keywords, this is in
my opinion a bit silly. On the other hand in D you have
keywords like immutable that are rather long to type. So I
prefer a mid way between those two.
They aren't silly, they're consistent. We have int, char, auto,
they have fn,
On Sunday, 8 July 2012 at 13:49:50 UTC, bearophile wrote:
So I've taken another look at the Rust tutorial:
http://dl.rust-lang.org/doc/tutorial.html
Does it handle angle brackets well?
Am Tue, 17 Jul 2012 21:39:33 +0200
schrieb SomeDude lovelyd...@mailmetrash.com:
On Friday, 13 July 2012 at 14:58:57 UTC, bearophile wrote:
A blog post about one of the Rust pointers, the borrowed ones:
http://smallcultfollowing.com/babysteps/blog/2012/07/10/borrowed-pointer-tutorial/
Walter Bright:
auto code() { return cast(ushort)42; }
works fine. There isn't really a lack here, just some more
typing. I just don't see the case coming up hardly at all.
I have just found an example (reduced code):
import std.typecons;
void main() {
alias Tuple!(ubyte[]) Tu;
On Friday, 13 July 2012 at 14:58:57 UTC, bearophile wrote:
A blog post about one of the Rust pointers, the borrowed ones:
http://smallcultfollowing.com/babysteps/blog/2012/07/10/borrowed-pointer-tutorial/
Bye,
bearophile
Rust is a much more interesting language than Go. At least they
are
On 07/17/2012 07:25 PM, bearophile wrote:
Walter Bright:
auto code() { return cast(ushort)42; }
works fine. There isn't really a lack here, just some more typing. I
just don't see the case coming up hardly at all.
I have just found an example (reduced code):
import std.typecons;
void
Am Fri, 13 Jul 2012 08:31:31 +0900
schrieb Geoffrey Biggs geoffrey.bi...@aist.go.jp:
Personally, I think that if I need to care about the data size/maximum
range of a value, I should be using a fixed-size data type rather than
specifying it in the value. The language typically supports me in
Am Thu, 12 Jul 2012 11:30:58 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 7/12/2012 2:42 AM, Marco Leise wrote:
I understand that some of the examples have better alternatives. What I
don't
understand is why you term this as increased language complexity. This is
not
A blog post about one of the Rust pointers, the borrowed ones:
http://smallcultfollowing.com/babysteps/blog/2012/07/10/borrowed-pointer-tutorial/
Bye,
bearophile
On 7/13/2012 3:21 AM, Marco Leise wrote:
The cases of 'auto' return or assignment can be worked around by not using
auto and may be artificial. Yet it feels like auto is partially broken,
because I cannot directly write down 8- and 16-bit integer literals like so:
auto code(...) { if (...)
David Piepgrass wrote in message
news:jdyhfsxgucfglqgaj...@forum.dlang.org...
Rust has type classes from Haskell (with some simplifications for higher
kinds), uniqueness typing, and typestates.
As nice as kinds, typestates, typeclasses and several pointer types may be,
I was in the Rust
Am Wed, 11 Jul 2012 22:58:07 +0200
schrieb bearophile bearophileh...@lycos.com:
= a = 5s;
I read that as 5 seconds :-(
Me too, but then again 5l could be read as 5 liters. I guess that is why the
move is towards uppercase suffixes. 5S and 5L are not likely misread.
I don't think your
Am Thu, 12 Jul 2012 11:42:13 +0200
schrieb Marco Leise marco.le...@gmx.de:
Am Wed, 11 Jul 2012 22:58:07 +0200
schrieb bearophile bearophileh...@lycos.com:
= a = 5s;
I read that as 5 seconds :-(
Me too, but then again 5l could be read as 5 liters. I guess that is why
the move is
On 07/11/2012 03:50 PM, Walter Bright wrote:
On 7/11/2012 11:54 AM, David Piepgrass wrote:
That reminds me, I was so happy the first two times I got an undefined
symbol
error in D. The compiler said: Did you mean 'correct variable
name'? LOL,
don't tell me how it works... it's magic, right? I
Am Thu, 12 Jul 2012 08:22:59 -0400
schrieb Jeff Nowakowski j...@dilacero.org:
On 07/11/2012 03:50 PM, Walter Bright wrote:
On 7/11/2012 11:54 AM, David Piepgrass wrote:
That reminds me, I was so happy the first two times I got an undefined
symbol
error in D. The compiler said: Did you
Am Thu, 12 Jul 2012 12:08:07 +0200
schrieb Marco Leise marco.le...@gmx.de:
Am Thu, 12 Jul 2012 11:42:13 +0200
schrieb Marco Leise marco.le...@gmx.de:
Am Wed, 11 Jul 2012 22:58:07 +0200
schrieb bearophile bearophileh...@lycos.com:
= a = 5s;
I read that as 5 seconds :-(
On 7/12/2012 2:42 AM, Marco Leise wrote:
I understand that some of the examples have better alternatives. What I don't
understand is why you term this as increased language complexity. This is not
one of the why not add kind of requests. From my point of view the
complexity is already there
On 12 July 2012 18:42, Marco Leise marco.le...@gmx.de wrote:
Am Wed, 11 Jul 2012 22:58:07 +0200
schrieb bearophile bearophileh...@lycos.com:
= a = 5s;
I read that as 5 seconds :-(
Me too, but then again 5l could be read as 5 liters. I guess that is why
the move is towards uppercase
Short keywords are only important with barebones editors like
a default vi.
Nobody would use this for real development.
I started I long discussion on Reddit, because I complained
that the goal of 5 letter keywords is primitive, and brings
back memories of the time the compilers were memory
On Wednesday, 11 July 2012 at 16:45:17 UTC, David Piepgrass wrote:
Anyway I think short vs long is much ado about nothing. No one
complains that we have to type int instead of integer,
after all. Most languages have only a few keywords, which
people quickly learn. As long as all the standard
On Sunday, 8 July 2012 at 19:28:11 UTC, Walter Bright wrote:
On 7/8/2012 6:49 AM, bearophile wrote:
I think in Go the function stack is segmented and growable as
in Go. This saves
RAM if you need a small stack, and avoids stack overflows
where lot of stack is
needed.
The trouble with
On 07/11/2012 06:45 PM, David Piepgrass wrote:
...
These benefits (except 3) all exist for function as well as fn, but
while many languages use fun, requiring function for all functions
is almost unheard of (at least I haven't heard of it), why? It's too
damn long! We write functions constantly,
On Wednesday, 11 July 2012 at 17:09:27 UTC, Timon Gehr wrote:
On 07/11/2012 06:45 PM, David Piepgrass wrote:
...
These benefits (except 3) all exist for function as well as
fn, but
while many languages use fun, requiring function for all
functions
is almost unheard of (at least I haven't
On 11-07-2012 19:09, Timon Gehr wrote:
On 07/11/2012 06:45 PM, David Piepgrass wrote:
...
These benefits (except 3) all exist for function as well as fn, but
while many languages use fun, requiring function for all functions
is almost unheard of (at least I haven't heard of it), why? It's too
On Sunday, 8 July 2012 at 21:04:05 UTC, jerro wrote:
As someone that values readable code, I don't understand this
desire to turn every programming language into APL.
I would expect the abbreviations that rust uses to be perfectly
readable once you know the langauge.
I like a lot ML
Rust has type classes from Haskell (with some simplifications
for higher kinds), uniqueness typing, and typestates.
As nice as kinds, typestates, typeclasses and several pointer
types may be, I was in the Rust mailing list and felt unable to
participate because they kept using terminology
On Wednesday, 11 July 2012 at 17:09:27 UTC, Timon Gehr wrote:
On 07/11/2012 06:45 PM, David Piepgrass wrote:
...
These benefits (except 3) all exist for function as well as
fn, but
while many languages use fun, requiring function for all
functions
is almost unheard of (at least I haven't
Marco Leise:
Yes, this is the single most important Rust feature to me when
typing. I've just had too many cases of mass-casts to ubyte or
short where a suffix to the literal would only have cost one or
two letters. 255ub = byte, 32000s = short
I am writing a lot of D2 code, but in my code
On 07/11/2012 08:00 PM, David Piepgrass wrote:
...
Oh, I can't tell you what a pet peeve PITA the C precedence is. Ugh! I
know it's against D philosophy to change the precedence w.r.t. C, but
how about a compromise: give a warning or error for x2 0, with
error message: add parenthesis around x2
On 7/11/2012 9:57 AM, David Piepgrass wrote:
On Sunday, 8 July 2012 at 19:28:11 UTC, Walter Bright wrote:
On 7/8/2012 6:49 AM, bearophile wrote:
I think in Go the function stack is segmented and growable as in Go. This saves
RAM if you need a small stack, and avoids stack overflows where lot
The trouble with segmented stacks are:
1. they have a significant runtime penalty
Why?
Extra instructions generated for each function.
Every function? Why?
2. interfacing to C code becomes problematic
Isn't it possible to auto-commit new pages when C code needs
it?
...
There's no way to
On 7/11/2012 11:00 AM, David Piepgrass wrote:
the logical bitwise operators have higher precedence. In C, x 2 0 comes
out as x (2 0), in Rust, it means (x 2) 0, which is more likely to be
what you expect (unless you are a C veteran).
Oh, I can't tell you what a pet peeve PITA the C
On 7/11/2012 9:45 AM, David Piepgrass wrote:
I still type reutrn and retrun all the damn time!
I keep finding myself typing redrum !
On Wednesday, 11 July 2012 at 18:31:23 UTC, David Piepgrass wrote:
The trouble with segmented stacks are:
1. they have a significant runtime penalty
Why?
Extra instructions generated for each function.
Every function? Why?
Looks like I misunderstood what Segmented stacks are. From an
LLVM
Oh, I can't tell you what a pet peeve PITA the C precedence
is. Ugh! I know it's
against D philosophy to change the precedence w.r.t. C, but
how about a
compromise: give a warning or error for x2 0, with error
message: add
parenthesis around x2 to clarify your intention.
bool test(int x)
Am Wed, 11 Jul 2012 19:09:26 +0200
schrieb Timon Gehr timon.g...@gmx.ch:
On 07/11/2012 06:45 PM, David Piepgrass wrote:
...
These benefits (except 3) all exist for function as well as fn, but
while many languages use fun, requiring function for all functions
is almost unheard of (at
bool test(int x) { return x 2 0; }
gives:
foo.d(1): Error: 2 0 must be parenthesized when next to
operator
That reminds me, I was so happy the first two times I got an
undefined symbol error in D. The compiler said: Did you mean
'correct variable name'? LOL, don't tell me how it
On 7/11/2012 11:54 AM, David Piepgrass wrote:
That reminds me, I was so happy the first two times I got an undefined symbol
error in D. The compiler said: Did you mean 'correct variable name'? LOL,
don't tell me how it works... it's magic, right? I love a good error message.
I added a spelling
Am Wed, 11 Jul 2012 20:24:34 +0200
schrieb bearophile bearophileh...@lycos.com:
Marco Leise:
Yes, this is the single most important Rust feature to me when
typing. I've just had too many cases of mass-casts to ubyte or
short where a suffix to the literal would only have cost one or
On Wednesday, 11 July 2012 at 18:53:31 UTC, Marco Leise wrote:
Am Wed, 11 Jul 2012 19:09:26 +0200
schrieb Timon Gehr timon.g...@gmx.ch:
On 07/11/2012 06:45 PM, David Piepgrass wrote:
...
These benefits (except 3) all exist for function as well
as fn, but
while many languages use fun,
Marco Leise:
Phobos:
(boxer.d):
assert (box(1) == box(cast(byte)1));
= assert (box(1) == box(1b));
(algorithm.d):
assert(b == [ cast(ubyte) 0, cast(ubyte)2, cast(ubyte)1,
cast(ubyte)6, cast(ubyte)5], text(b));
= assert(b == [ 0ub, 2ub, 1ub, 6ub, 5ub], text(b));
Here b is an
On 07/11/12 20:32, Walter Bright wrote:
On 7/11/2012 9:45 AM, David Piepgrass wrote:
I still type reutrn and retrun all the damn time!
I keep finding myself typing redrum !
Good one :D
Marco Leise:
Then again it also has 'begin' and 'end' instead of { and }.
Masochists...
Between APL/Ursala and Ada extremes there is a wide happy middle,
D, Pascal and probably Rust too are all usable.
The 'begin' and 'end' of Pascal are not bad, they are short
lowercase words written
On 11/07/2012 21:50, Walter Bright wrote:
On 7/11/2012 11:54 AM, David Piepgrass wrote:
That reminds me, I was so happy the first two times I got an undefined
symbol
error in D. The compiler said: Did you mean 'correct variable
name'? LOL,
don't tell me how it works... it's magic, right? I love
On 07/11/2012 02:00 PM, David Piepgrass wrote:
I am particularly a fan of structural typing. I don't know if Rust uses
it but Opa and other functional languages often do. You see, there's a
problem that pops up in .NET all the time, and probably the same problem
exists in D.
Any time two
Caligo iteronve...@gmail.com wrote:
On Mon, Jul 9, 2012 at 4:24 PM, Stefan Scholl ste...@no-spoon.de wrote:
bearophile bearophileh...@lycos.com wrote:
I think Go is meant to be used mostly on 64 bit servers.
There aren't many people using Go on 32 bit systems. That's why there is
(was?) a
Am Sun, 08 Jul 2012 21:51:57 +0200
schrieb Daniel wyr...@gmx.net:
On Sunday, 8 July 2012 at 13:49:50 UTC, bearophile wrote:
This seems a bit overkill to me:
It's also possible to avoid any type ambiguity by writing
integer literals with a suffix. The suffixes i and u are for
the
On 7/10/12 2:30 AM, Stefan Scholl wrote:
Caligoiteronve...@gmail.com wrote:
On Mon, Jul 9, 2012 at 4:24 PM, Stefan Schollste...@no-spoon.de wrote:
bearophilebearophileh...@lycos.com wrote:
I think Go is meant to be used mostly on 64 bit servers.
There aren't many people using Go on 32
On 10 July 2012 13:35, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 7/10/12 2:30 AM, Stefan Scholl wrote:
Caligoiteronve...@gmail.com wrote:
On Mon, Jul 9, 2012 at 4:24 PM, Stefan Schollste...@no-spoon.de wrote:
bearophilebearophileh...@lycos.com wrote:
I think Go is
Andrei Alexandrescu Wrote:
On 7/10/12 2:30 AM, Stefan Scholl wrote:
Caligoiteronve...@gmail.com wrote:
On Mon, Jul 9, 2012 at 4:24 PM, Stefan Schollste...@no-spoon.de wrote:
bearophilebearophileh...@lycos.com wrote:
I think Go is meant to be used mostly on 64 bit servers.
There
On 7/10/12 10:59 AM, Patrick Stewar wrote:
Andrei Alexandrescu Wrote:
On 7/10/12 2:30 AM, Stefan Scholl wrote:
Caligoiteronve...@gmail.com wrote:
On Mon, Jul 9, 2012 at 4:24 PM, Stefan
Schollste...@no-spoon.de wrote:
bearophilebearophileh...@lycos.com wrote:
I think Go is meant to be
jerro a...@a.com wrote:
I would expect the abbreviations that rust uses to be perfectly
readable once you know the langauge.
There is a lot of noise (lot of special characters) in Rust code. Together
with short keywords like fn for function definition.
It's hard to see a structure in it. You
bearophile bearophileh...@lycos.com wrote:
I think Go is meant to be used mostly on 64 bit servers.
There aren't many people using Go on 32 bit systems. That's why there is
(was?) a big memory leak on these systems which wasn't caught early on.
On Mon, Jul 9, 2012 at 4:24 PM, Stefan Scholl ste...@no-spoon.de wrote:
bearophile bearophileh...@lycos.com wrote:
I think Go is meant to be used mostly on 64 bit servers.
There aren't many people using Go on 32 bit systems. That's why there is
(was?) a big memory leak on these systems which
On Reddit they are currently discussing again about the Rust
language, and about the browser prototype written in Rust, named
Servo (https://github.com/mozilla/servo ):
http://www.reddit.com/r/programming/comments/w6h7x/the_state_of_servo_a_mozilla_experiment_in/
So I've taken another look at
Thank for keeping us informed about Rust. i don't like the syntax, but
it is definitively an interesting language and something we should look
at as D people.
On 08/07/2012 15:49, bearophile wrote:
On Reddit they are currently discussing again about the Rust language,
and about the browser
bearophile bearophileh...@lycos.com wrote:
On default in Rust types are immutable. If you want the mutable type you
need to annotate it with mut in some way.
Rust designers seems to love really short keywords, this is in my opinion
a bit silly. On the other hand in D you have keywords like
On Sunday, 8 July 2012 at 18:13:49 UTC, Stefan Scholl wrote:
bearophile bearophileh...@lycos.com wrote:
On default in Rust types are immutable. If you want the
mutable type you
need to annotate it with mut in some way.
Rust designers seems to love really short keywords, this is in
my
On 7/8/2012 6:49 AM, bearophile wrote:
I think in Go the function stack is segmented and growable as in Go. This saves
RAM if you need a small stack, and avoids stack overflows where lot of stack is
needed.
The trouble with segmented stacks are:
1. they have a significant runtime penalty
2.
On Sunday, 8 July 2012 at 13:49:50 UTC, bearophile wrote:
This seems a bit overkill to me:
It's also possible to avoid any type ambiguity by writing
integer literals with a suffix. The suffixes i and u are for
the types int and uint, respectively: the literal -3i has type
int, while 127u has
As someone that values readable code, I don't understand this
desire to turn every programming language into APL.
I would expect the abbreviations that rust uses to be perfectly
readable once you know the langauge.
Walter Bright:
Thank you for your answers Walter, as you guess I am ignorant
about segmented stacks.
The trouble with segmented stacks are:
1. they have a significant runtime penalty
Also, they do not save RAM, they save address space. RAM is not
committed until a stack memory page is
On 7/8/2012 2:32 PM, bearophile wrote:
Segmented stacks are useful for 32 bit address space. However, they are not
useful for 64 bit address spaces.
I think Go is meant to be used mostly on 64 bit servers.
Both the designers of Go and Rust are experienced people, and they plan to use
their
66 matches
Mail list logo
