I am not a fan of having wrap-around and non-wrap-around types, because
whether you use wrap-around arithmetic or not is, in the end, an
implementation detail, and having to switch types left and right whenever
going from one mode to the other is going to be a lot of boilerplate.
Instead, why not
On Sat, Jun 21, 2014 at 3:31 AM, Jerry Morrison jhm...@gmail.com wrote:
On Fri, Jun 20, 2014 at 5:36 PM, Gábor Lehel glaebho...@gmail.com wrote:
On Sat, Jun 21, 2014 at 1:37 AM, Jerry Morrison jhm...@gmail.com wrote:
On Fri, Jun 20, 2014 at 2:07 PM, Gábor Lehel glaebho...@gmail.com
On Sat, Jun 21, 2014 at 11:21 PM, Vadim Chugunov vadi...@gmail.com wrote:
My 2c:
The world is finally becoming security-conscious, so I think it is a only
matter of time before architectures that implement zero-cost integer
overflow checking appear. I think we should be ready for it when
On Sun, Jun 22, 2014 at 2:02 AM, Daniel Micay danielmi...@gmail.com wrote:
On 21/06/14 07:55 PM, Benjamin Striegel wrote:
No one will use Rust if it's slow. If it uses checked arithmetic, it
will be slow. There's nothing subjective about that.
This is the only argument that matters.
Even though Rust is a performance conscious language (since it aims at
displacing C and C++), the 80/20 rule still applies and most of Rust code
should not require absolute speed
This is a mistaken assumption. Systems programming exists on the extreme
end of the programming spectrum where edge
Because of memory safety? Because you want low-level control without
absolute speed? Because of a small memory footprint? Because of having a
good async story without giving up a lot of speed?
There are plenty of other features to Rust then absolute speed. Just
because that's *your* usecase for
There are plenty of other features to Rust then absolute speed.
You're right. Here are the three primary features of Rust, in decreasing
order of importance:
1. Memory safety
2. C++ performance
3. Safe concurrency
Notably, correctness in the face of integer overflow is merely a
On 18/06/14 10:11, Hans Jørgen Hoel wrote:
Rust Ci wasn't working for a period due to problems with building the
nightly PPA for the platform used by Travis (required GCC version was
bumped with no way to specify alternative to configure script).
This has been fixed for a while, but it turns
On 22.06.2014 17:32, Benjamin Striegel wrote:
Even though Rust is a performance conscious language (since it aims at
displacing C and C++), the 80/20 rule still applies and most of Rust
code should not require absolute speed
This is a mistaken assumption. Systems programming exists on the
I don't think I was ever Railing against the incorrectness of overflow
semantics? I was just pointing out that your (imo pretty hostile?) message
about If you don't require absolute speed, why are you using Rust?
doesn't really ring true. Most C++ programmers don't even require absolute
speed.
I agree that we need to clarify our error-handling story. Specifically I
would like Daniel to elaborate on this quote of his from the previous
thread, with potential solutions at the language level:
Rust's task failure isn't very isolated or robust. A failure in a
destructor called during
On 06/22/2014 11:32 AM, Benjamin Striegel wrote:
This is a mistaken assumption. Systems programming exists on the extreme
end of the programming spectrum where edge cases are the norm, not the
exception, and where 80/20 does not apply.
Even in systems programming not every line is going to be
On 22 June 2014 17:06, Florian Zeitz flo...@babelmonkeys.de wrote:
To me the point of this discussion boils down to this:
I think we can all agree that having checked arithmetic is worthwhile.
Rust already has it as e.g. `.checked_add()'.
I think it might even be non-controversial that it is
I apologize for being hostile. As Florian has noted, we're just arguing
about the default behavior here. It is my opinion that checked behavior by
default will make Rust unsuitable for filling C++'s niche, and send the
message that we are not serious about performance.
On Sun, Jun 22, 2014 at
Are there advantages or disadvantages with using nightlies from the PPA
rather than those from rust-lang.org?
PPA nightlies are woefully out of date but they are easier to reinstall -
they automatically notify you when you're out of date, which I don't think
rust-lang nightlies do. Also having
Yes, but many users won't even attempt to write their own pointer types,
and will reap benefits from having nice support for the essential pointers,
that they can think of as built-in. Those that attempt to write their own
will not be in a worse position than they are now.
On 21 June 2014 17:05,
On 21 June 2014 22:03, Igor Bukanov i...@mir2.org wrote:
On 20 June 2014 21:07, Paulo Sérgio Almeida pssalme...@gmail.com wrote:
I have seen many other examples, where the code could mislead the reader
into
thinking there are several, e.g., Mutexes:
let mutex = Arc::new(Mutex::new(1));
On 6/21/14 9:00 AM, Benjamin Striegel wrote:
I don't think that is untenable, performance wise, after all it is
what everyone is currently doing in C++.
We have already made several decisions that will disadvantage us with
regard to C++.
...Like what?
This thread has a lot of very
Why can't you use Rc or Weak? That seems self-evidently false to me:
there are many languages that *only* have reference counting, and they
can represent graphs just fine.
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
On 6/21/14 4:05 PM, Cameron Zwarich wrote:
Another big problem with implicit copy constructors is that they make it
very difficult to write correct unsafe code. When each use of a variable
can call arbitrary code, each use of a variable can trigger unwinding.
You then basically require people to
On 6/21/14 4:10 PM, Daniel Micay wrote:
http://ref.x86asm.net/coder64.html
I don't see enough gaps here for the necessary instructions.
I think all that Intel would have to do is to resurrect INTO (0xce) and
optimize the case in which INTO immediately follows an overflowable
arithmetic
On 22/06/14 09:31 AM, Gábor Lehel wrote:
The prospect of future architectures with cheaper (free) overflow
checking isn't my primary motivation, though if we also end up better
prepared for them as a side effect, that's icing on the cake.
It's never going to be free or even cheap. Replacing
Apologies if this has been suggested, but would it be possible to have a
compiler switch that can add runtime checks and abort on
overflow/underflow/carry for debugging purposes, but the default behavior
is no check? IMO this would be the best of both worlds, because I would
assume that one would
For some applications, Rust’s bounds checks and the inability of rustc to
eliminate them in nontrivial cases will already be too much of a performance
sacrifice. What do we say to those people? Is it just that memory safety is
important because of its security implications, and other forms of
On Jun 16, 2014, at 3:19 PM, Patrick Walton pcwal...@mozilla.com wrote:
On 6/16/14 3:17 PM, Cameron Zwarich wrote:
I stated the right case, but the wrong reason. It’s not for
vectorization, it’s because it’s not easy to reuse the storage of a
matrix while multiplying into it.
Wouldn't most
On 22/06/14 11:39 AM, Evan G wrote:
Because of memory safety?
Most modern languages are memory safe. They're also significantly easier
to use than Rust, because the compiler / runtime is responsible for
managing object lifetimes.
Because you want low-level control without absolute speed?
I'm
On 22/06/14 11:32 AM, Benjamin Striegel wrote:
Even though Rust is a performance conscious language (since it aims at
displacing C and C++), the 80/20 rule still applies and most of Rust
code should not require absolute speed
This is a mistaken assumption. Systems programming exists on the
On 22/06/14 05:09 PM, Rick Richardson wrote:
Apologies if this has been suggested, but would it be possible to have a
compiler switch that can add runtime checks and abort on
overflow/underflow/carry for debugging purposes, but the default
behavior is no check? IMO this would be the best of
On 2014-06-22, at 23:31 , Daniel Micay danielmi...@gmail.com wrote:
On 22/06/14 05:09 PM, Rick Richardson wrote:
Apologies if this has been suggested, but would it be possible to have a
compiler switch that can add runtime checks and abort on
overflow/underflow/carry for debugging purposes,
On 22/06/14 05:12 PM, Cameron Zwarich wrote:
For some applications, Rust’s bounds checks and the inability of rustc
to eliminate them in nontrivial cases will already be too much of a
performance sacrifice. What do we say to those people? Is it just that
memory safety is important because of
On 22/06/14 05:48 PM, Masklinn wrote:
On 2014-06-22, at 23:31 , Daniel Micay danielmi...@gmail.com wrote:
On 22/06/14 05:09 PM, Rick Richardson wrote:
Apologies if this has been suggested, but would it be possible to have a
compiler switch that can add runtime checks and abort on
On 22/06/14 06:37 AM, Matthieu Monrocq wrote:
I am not a fan of having wrap-around and non-wrap-around types, because
whether you use wrap-around arithmetic or not is, in the end, an
implementation detail, and having to switch types left and right
whenever going from one mode to the other is
I think a reasonable middle ground is to have checked operators that look a
little funny. Kind of like swift, but in reverse:
malloc((number_of_elements +~ 12) *~ size_of::int())
Where adding a ~ to the end of an operator makes it check for overflow.
This would certainly look nicer than stuff
The PPA nightlies should be up to date now if you're using an Ubuntu
version that's still supported by Canonical (i.e. supported by
Launchpad).
--
Hans Jørgen
On 22 June 2014 19:24, Daniel Fath daniel.fa...@gmail.com wrote:
Are there advantages or disadvantages with using nightlies from the
On 6/22/14 2:12 PM, Cameron Zwarich wrote:
For some applications, Rust’s bounds checks and the inability of rustc
to eliminate them in nontrivial cases will already be too much of a
performance sacrifice. What do we say to those people? Is it just that
memory safety is important because of its
On Sun, Jun 22, 2014 at 05:26:47PM -0400, Daniel Micay wrote:
Rust's design is based on the assumption that performance cannot be
achieved simply by having highly optimized inner loops. It takes a whole
program approach to performance by exposing references as first-class
values and
On Sun, Jun 22, 2014 at 11:05 PM, Daniel Micay danielmi...@gmail.com
wrote:
On 22/06/14 09:31 AM, Gábor Lehel wrote:
The prospect of future architectures with cheaper (free) overflow
checking isn't my primary motivation, though if we also end up better
prepared for them as a side effect,
Makes sense, but I am curious, how do you see adding this post-1.0? Would
you:
- add overflow-checked int types and tell everybody to use them instead of
the default ones from that point on
- declare that in Rust2 integers are overflow-checked, and have everybody
port their Rust1 code. (Well,
Apologies for adding heat to the discussion. The industry needs to make
progress on security/safety-critical systems, and Rust does a great deal
for that by bringing memory safety to a C/C++ alternative.
This post about hardware traps for integer overflow
http://blog.regehr.org/archives/1154 is
On Sun, Jun 22, 2014 at 2:31 PM, Daniel Micay danielmi...@gmail.com wrote:
On 22/06/14 05:09 PM, Rick Richardson wrote:
Apologies if this has been suggested, but would it be possible to have a
compiler switch that can add runtime checks and abort on
overflow/underflow/carry for debugging
On 6/22/14 5:34 PM, Vadim Chugunov wrote:
Modern C++ compilers often have a bunch of runtime checks (stack
overflow protectors, iterator invalidation detectors, and so on) that
may be enabled or disabled, and nobody bats an eye at that.
I'm not so sure. C++ is notoriously bad at dynamic
On 22/06/14 07:43 PM, Vadim Chugunov wrote:
Makes sense, but I am curious, how do you see adding this post-1.0?
Would you:
- add overflow-checked int types and tell everybody to use them instead
of the default ones from that point on
- declare that in Rust2 integers are overflow-checked,
On 22/06/14 07:26 PM, Gábor Lehel wrote:
Coincidentally, I didn't propose it. I proposed one implementation with
owned allocation (which we already have) in the `prelude` and one with
tracing GC allocation in the `gc` module.
Then I don't understand why we would have one for task-local
On 22/06/14 08:25 PM, Jerry Morrison wrote:
The post also links to Wikipedia on Intel MPX
http://en.wikipedia.org/wiki/Intel_MPX: Intel is adding x86 extensions
to aid memory safety! I think it's for array bounds checking, but the
article is unclear.
It's for faster (but not free) array
On 6/22/14 8:46 PM, Daniel Micay wrote:
It's for faster (but not free) array bounds checking. I don't think Rust
will be able to use it because it unwinds on out-of-bounds rather than
aborting, and it will be difficult to turn the OS support (perhaps
SIGFPE / SIGSEGV on *nix) into well defined
On 6/22/14 8:52 PM, Patrick Walton wrote:
On 6/22/14 8:46 PM, Daniel Micay wrote:
It's for faster (but not free) array bounds checking. I don't think Rust
will be able to use it because it unwinds on out-of-bounds rather than
aborting, and it will be difficult to turn the OS support (perhaps
On 22/06/14 07:24 PM, Andrew Poelstra wrote:
On Sun, Jun 22, 2014 at 05:26:47PM -0400, Daniel Micay wrote:
Rust's design is based on the assumption that performance cannot be
achieved simply by having highly optimized inner loops. It takes a whole
program approach to performance by exposing
On 22/06/14 11:52 PM, Patrick Walton wrote:
On 6/22/14 8:46 PM, Daniel Micay wrote:
It's for faster (but not free) array bounds checking. I don't think Rust
will be able to use it because it unwinds on out-of-bounds rather than
aborting, and it will be difficult to turn the OS support (perhaps
On 22/06/14 06:43 PM, Clark Gaebel wrote:
I think a reasonable middle ground is to have checked operators that
look a little funny. Kind of like swift, but in reverse:
malloc((number_of_elements +~ 12) *~ size_of::int())
Where adding a ~ to the end of an operator makes it check for
On Jun 22, 2014, at 8:52 PM, Patrick Walton pcwal...@mozilla.com wrote:
On 6/22/14 8:46 PM, Daniel Micay wrote:
It's for faster (but not free) array bounds checking. I don't think Rust
will be able to use it because it unwinds on out-of-bounds rather than
aborting, and it will be difficult to
On Sun, Jun 22, 2014 at 5:05 PM, Daniel Micay danielmi...@gmail.com wrote:
Anyway, no one has offered an explanation of how they're
planning on integrating this into LLVM and how they propose turning a
trapping operation into unwinding across various platforms.
Isn't that what asynchronous
On 23/06/14 12:17 AM, comex wrote:
On Sun, Jun 22, 2014 at 5:05 PM, Daniel Micay danielmi...@gmail.com wrote:
Anyway, no one has offered an explanation of how they're
planning on integrating this into LLVM and how they propose turning a
trapping operation into unwinding across various
On Mon, Jun 23, 2014 at 12:10 AM, Daniel Micay danielmi...@gmail.com wrote:
Rust only gains efficiency from the type system, not any form of thread
safety that's not available to a garbage collected language. It's able
to send `BoxT` data structures without performing a deep copy.
Which is the
On Mon, Jun 23, 2014 at 12:35 AM, Daniel Micay danielmi...@gmail.com wrote:
An operation that can unwind isn't pure. It impedes code motion such as
hoisting operations out of a loop, which is very important for easing
the performance issues caused by indexing bounds checks. LLVM doesn't
model
On Jun 22, 2014, at 9:35 PM, Daniel Micay danielmi...@gmail.com wrote:
An operation that can unwind isn't pure. It impedes code motion such as
hoisting operations out of a loop, which is very important for easing
the performance issues caused by indexing bounds checks. LLVM doesn't
model the
On 23/06/14 12:49 AM, Cameron Zwarich wrote:
On Jun 22, 2014, at 9:35 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
An operation that can unwind isn't pure. It impedes code motion such as
hoisting operations out of a loop, which is very important for easing
the
On 23/06/14 12:46 AM, comex wrote:
On Mon, Jun 23, 2014 at 12:35 AM, Daniel Micay danielmi...@gmail.com wrote:
An operation that can unwind isn't pure. It impedes code motion such as
hoisting operations out of a loop, which is very important for easing
the performance issues caused by indexing
On Mon, Jun 23, 2014 at 1:05 AM, Daniel Micay danielmi...@gmail.com wrote:
The call we make to perform unwinding isn't a pure function though, it's
aware of the context causing it to unwind. As long as we're supporting
stuff like backtraces outside of a debugger, that's going to be the case.
On Jun 22, 2014, at 10:00 PM, Daniel Micay danielmi...@gmail.com wrote:
On 23/06/14 12:49 AM, Cameron Zwarich wrote:
On Jun 22, 2014, at 9:35 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
An operation that can unwind isn't pure. It impedes code motion such as
On 23/06/14 01:15 AM, comex wrote:
On Mon, Jun 23, 2014 at 1:05 AM, Daniel Micay danielmi...@gmail.com wrote:
The call we make to perform unwinding isn't a pure function though, it's
aware of the context causing it to unwind. As long as we're supporting
stuff like backtraces outside of a
On 23/06/14 01:16 AM, Cameron Zwarich wrote:
On Jun 22, 2014, at 10:00 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
On 23/06/14 12:49 AM, Cameron Zwarich wrote:
On Jun 22, 2014, at 9:35 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com
61 matches
Mail list logo
