Hello rustangles!
Just a friendly reminder that we have a great meetup lined up tomorrow in
San Francisco. Instructions on attending or watching remotely are found
here:
http://www.meetup.com/Rust-Bay-Area/events/17672/
See you tomorrow!
-Erick
On Sat, May 24, 2014 at 8:03 PM, Tom Park
On 24/06/14 01:55 AM, Jerry Morrison wrote:
On Mon, Jun 23, 2014 at 10:32 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
On 24/06/14 01:17 AM, Jerry Morrison wrote:
Does `checked { }` mean all functions within that scope use
On Tue, Jun 24 2014, Yehuda Katz wrote:
I'm happy to announce that Cargo is now ready to try out!
That's great news! Thanks for all your work and for making Rust more
accessible to newcomers like myself.
--
Petar Radosevic | @wunki
___
Rust-dev
The FAQ says:
Our solution: Cargo allows a package to specify a script to run
before invoking |rustc|. We plan to add support for platform-specific
configuration, so you can use |make| on Linux and |cmake| on BSD, for
example.
Just to make it perfectly clear, this will force a Cygwin
On 24.06.2014 06:36, Gil Cottle wrote:
If not, adding a flag would be useful for text file-writing/reading when
running on Windows, but it could also be a source of issues for people
trying to write binary/text data depending on the defaults. Any thoughts on
this?
For what its worth, I think
On 24/06/14 20:41, György Andrasek wrote:
The FAQ says:
Our solution: Cargo allows a package to specify a script to run
before invoking |rustc|. We plan to add support for platform-specific
configuration, so you can use |make| on Linux and |cmake| on BSD, for
example.
Just to make it
On Tue, Jun 24, 2014 at 7:52 AM, Corey Richardson co...@octayn.net wrote:
There is an Ubuntu PPA available at
https://launchpad.net/~cmrx64/+archive/cargo, for use on travis or
otherwise.
cargo : Depends: libc6 ( 2.16) but 2.19-0ubuntu6 is installed.
Only for Ubuntu 14.04?
--
Sebastien
On 06/24/2014 01:05 PM, Huon Wilson wrote:
Just to be clear: what's the trade-off here? That is, what is the
alternative: not supporting running external scripts at all?
The alternative is to use a proper scripting language for configuration,
so people don't need *external* scripts: waf
On Jun 23, 2014, at 7:16 PM, John Regehr reg...@cs.utah.edu wrote:
I do think Rust should exposed either `checked { }` or operators for
checked arithmetic along with an opt-in lint to deny the unchecked
operators. You can opt-out of a lint for a function/impl/module after
opting into it at
On Mon, Jun 23, 2014 at 10:00 PM, Daniel Micay danielmi...@gmail.com wrote:
I don't understand why this would be better than either `checked {}` or
checked operators along with an opt-in lint to catch unchecked
operators. It's far better than simply saying stuff is unspecified and
not actually
It wasn't clear from the documentation I read, but are multi-package
repositories supported? The manifest format, in particular, doesn't seem to
mention it (unless the manifest format is also incomplete).
-SL
___
Rust-dev mailing list
El 24/06/14 12:05, Huon Wilson escribió:
On 24/06/14 20:41, György Andrasek wrote:
The FAQ says:
Our solution: Cargo allows a package to specify a script to run
before invoking |rustc|. We plan to add support for platform-specific
configuration, so you can use |make| on Linux and |cmake| on
Using Go (or Python or whatever) for this implies either the build system needs
to include compiled
binaries (not good) or the system doing the build needs to have a Go (or xyz)
interpreter installed. So
cross-platform build configurations will require an external dependency (or
writing
This is very well presented for an alpha. Nicely done. So excited to see
projects start using it.
On 06/23/2014 10:50 PM, Yehuda Katz wrote:
Folks,
I'm happy to announce that Cargo is now ready to try out!
The Cargo repository is now at https://github.com/rust-lang/cargo and
you can learn
On 24/06/14 10:57 AM, Lars Bergstrom wrote:
On Jun 23, 2014, at 7:16 PM, John Regehr reg...@cs.utah.edu wrote:
I do think Rust should exposed either `checked { }` or operators for
checked arithmetic along with an opt-in lint to deny the unchecked
operators. You can opt-out of a lint for a
On 24/06/14 11:12 AM, Gregory Maxwell wrote:
On Mon, Jun 23, 2014 at 10:00 PM, Daniel Micay danielmi...@gmail.com wrote:
I don't understand why this would be better than either `checked {}` or
checked operators along with an opt-in lint to catch unchecked
operators. It's far better than simply
This is pretty awesome. I notice that http://crates.io doesn’t link to the
GitHub repo though. Seems like that might be a useful thing to add.
-Kevin
On Jun 23, 2014, at 10:50 PM, Yehuda Katz wyc...@gmail.com wrote:
Folks,
I'm happy to announce that Cargo is now ready to try out!
The
On Tue, Jun 24, 2014 at 11:39 AM, Daniel Micay danielmi...@gmail.com wrote:
A language full of implementation defined behaviour and language
dialects via compiler switches has no place in 2014.
This seems to be getting a by high spirited here.
Am I supposted to respond in kind? A language
On 24/06/14 02:51 PM, Gregory Maxwell wrote:
On Tue, Jun 24, 2014 at 11:39 AM, Daniel Micay danielmi...@gmail.com wrote:
A language full of implementation defined behaviour and language
dialects via compiler switches has no place in 2014.
This seems to be getting a by high spirited here.
On 24/06/14 02:34 PM, Daniel Micay wrote:
You haven't explained how this is going to cause security issues in
Rust, when the language is guaranteed to be memory safe outside of
`unsafe` blocks. The `unsafe` blocks are low-level, performance critical
code where unnecessary overflow checks are
I've been (very slowly) working on a pure rust build system (
https://github.com/erickt/rbuild) that we might be able to someday use to
do complex builds without needing other external language or build system.
On Tue, Jun 24, 2014 at 11:22 AM, Daniel Micay danielmi...@gmail.com
wrote:
On
On 24/06/14 03:06 PM, Erick Tryzelaar wrote:
I've been (very slowly) working on a pure rust build system
(https://github.com/erickt/rbuild) that we might be able to someday use
to do complex builds without needing other external language or build
system.
Well, +1 for that because it's very
I completely agree with Daniel in all points on this thread. (he
aggressively states over and over his stance and the teams concerning the
goals of Rust. The team has not deviated from their objective of the Rust
model. Kudos.)
I do not need compiler switches nor do I want them.
I want the
On 24/06/14 03:33 PM, Thad Guidry wrote:
I completely agree with Daniel in all points on this thread. (he
aggressively states over and over his stance and the teams concerning
the goals of Rust. The team has not deviated from their objective of the
Rust model. Kudos.)
Well, I don't speak for
On Tue, Jun 24, 2014 at 11:58 AM, Daniel Micay danielmi...@gmail.com
wrote:
That's why I support adding attributes but turning wrapping on overflow
on and off for a scope. You can indicate whether wrapping is considered
correct in that scope, meaning you either expect it to wrap or you have
I mostly agree, though for #1, I think that new int types would be more
appropriate. A set of special operators seems like an overkill for a
relatively infrequently used functionality. Annotations are too broad
(what if I need to do both wrapping and non-wrapping calculations in the
same
On 24/06/14 08:39 PM, Vadim Chugunov wrote:
I mostly agree, though for #1, I think that new int types would be more
appropriate. A set of special operators seems like an overkill for a
relatively infrequently used functionality. Annotations are too broad
(what if I need to do both wrapping
Yeah. And would programmers also have to convert each literal, like in the
Java-ish hashCode() example:
result = (wint) 31 * result + (wint) areaCode;
because adding a non-wraparound integer and a wraparound integer is
ambiguous?
Hey, it's just 5 more arithmetic operators. (A building architect
On 24/06/14 08:39 PM, Vadim Chugunov wrote:
I mostly agree, though for #1, I think that new int types would be more
appropriate. A set of special operators seems like an overkill for a
relatively infrequently used functionality. Annotations are too broad
(what if I need to do both wrapping
On Tue, Jun 24, 2014 at 5:48 PM, Jerry Morrison jhm...@gmail.com wrote:
Yeah. And would programmers also have to convert each literal, like in the
Java-ish hashCode() example:
result = (wint) 31 * result + (wint) areaCode;
because adding a non-wraparound integer and a wraparound integer is
On Wed, Jun 25, 2014 at 6:58 AM, Daniel Micay danielmi...@gmail.com wrote:
Rust has been consistently opposed to adding compiler switches changing
the meaning of the code. The metadata belongs *in the code* itself, and
you are free to flip wrapping on/off for whatever reason in the code
On 23/06/14 14:46, 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
I would think that something simple like
let mut sum = 0;
for x in some_int_array.iter() {
sum += x;
}
would be very hard to vectorise with unwinding integer operations.
It sounds like there are two problems. First, you need to give up on
precise exceptions. So the code
Ada's approach to integer overflows is substantially similar to AIR
Isn't Ada's response to overflow implementation-defined?
On Mon, Jun 23, 2014 at 11:37 AM, John Regehr reg...@cs.utah.edu wrote:
I would think that something simple like
let mut sum = 0;
for x in
hey rust community , i want initiate this project ..
where can i get started ?
* Laxmi Narayan Patel*
* MCA NIT Durgapur (2011-2014)*
* Mob:-8345847473*
On Tue, Jun 10, 2014 at 2:09 AM, Eli Green e...@zigr.org wrote:
Having looked at this library
On 22/06/14 12:16 PM, SiegeLord wrote:
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
Ada's approach to integer overflows is substantially similar to AIR
Isn't Ada's response to overflow implementation-defined?
Sort of.
First, the standard seems to require a Constraint_Error when signed
integer overflow happens. For example, on page 47 of the ADA 2012 standard:
For a
Hi
I finished basic Rust support for the Meson build system. It now supports
shared and static libraries with full install support and all that. Here's
the entire build definition for a library and two executables that use it.
project('libproject', 'rust')
corelib = shared_library('core',
On 23/06/14 04:10 PM, Tony Arcieri wrote:
On Monday, June 23, 2014, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
Rust is not a language designed for an imaginary sufficiently smart
compiler. It targets real architectures and the real LLVM backend.
I
On 23/06/14 04:01 PM, John Regehr wrote:
I doubt it, since Swift has a high level IR above LLVM IR and the
implementation isn't open-source. The language-specific optimizations
like removing overflow / bounds checks based on type system rules will
almost certainly be done on the high-level SIL
On 23/06/14 04:00 PM, Gregory Maxwell wrote:
On Mon, Jun 23, 2014 at 12:50 PM, Daniel Micay danielmi...@gmail.com wrote:
The discussion here is about checking for both signed / unsigned integer
overflow, as in passing both `-fsanitize=signed-integer-overflow` and
On Mon, Jun 23, 2014 at 3:50 PM, Daniel Micay danielmi...@gmail.com wrote:
I doubt it, since Swift has a high level IR above LLVM IR and the
implementation isn't open-source. The language-specific optimizations
like removing overflow / bounds checks based on type system rules will
almost
On 23/06/14 03:59 PM, Cameron Zwarich wrote:
On Jun 22, 2014, at 4:12 PM, Patrick Walton pcwal...@mozilla.com wrote:
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
On 6/23/14 1:55 PM, Daniel Micay wrote:
It's not much a systems language if it's slower than an inner loop in a
JavaScript program without going out of your way to avoid the overhead.
I agree with your general concerns, but I should nitpick that it won't
be slower than JavaScript, since JS
On Mon, Jun 23, 2014 at 4:49 PM, Daniel Micay danielmi...@gmail.com wrote:
I don't understand what the problem would be with my proposal to have
either `checked { }` or checked operators + a lint for unchecked usage.
I don't see 'checked { }' anywhere in the discussion before this
message...
On 6/23/14 2:04 PM, comex wrote:
On Mon, Jun 23, 2014 at 4:49 PM, Daniel Micay danielmi...@gmail.com wrote:
I don't understand what the problem would be with my proposal to have
either `checked { }` or checked operators + a lint for unchecked usage.
I don't see 'checked { }' anywhere in the
On Mon, Jun 23, 2014 at 1:32 PM, Daniel Micay danielmi...@gmail.com wrote:
It would be an enormous mistake to ship a language with region typing /
move semantics and worse before than Java.
You keep saying that, but if the argument is to use Swift's approach, i.e.:
Non-overflow operators: +
On Mon, Jun 23, 2014 at 1:49 PM, Daniel Micay danielmi...@gmail.com wrote:
I already mentioned the issue of undefined overflow, and how using
inbounds pointer arithmetic is both higher-level (iterators) and just as
fast. It doesn't cover every case, but it covers enough of them that the
use
O Mon, Jun 23, 2014 at 2:08 PM, Tony Arcieri basc...@gmail.com wrote:
Want to perform well at TIOBE or other (micro)benchmarks? Use the overflow
operators!
I meant http://shootout.alioth.debian.org here, but yeah, I hope you get
the idea ;)
--
Tony Arcieri
On 23/06/14 04:58 PM, Patrick Walton wrote:
On 6/23/14 1:55 PM, Daniel Micay wrote:
It's not much a systems language if it's slower than an inner loop in a
JavaScript program without going out of your way to avoid the overhead.
I agree with your general concerns, but I should nitpick that it
On 23/06/14 05:11 PM, Gregory Maxwell wrote:
Calling things 'slower than java' is a little bit hyperbole with the
actual numbers posted here. But I agree any non-trivial slowdown by
default would adversely impact adoption, I don't consider that
desirable.
It's really not hyperbole. Java's
I feel like Rust might be missing out on the free lunch I expect Swift to
provide
I think that it may be unfounded to expect Swift to spur drastic
improvements to any aspect of LLVM. Apple is already the biggest benefactor
of LLVM, which powers the C compiler their OS is built with, the
On 23/06/14 05:08 PM, Tony Arcieri wrote:
On Mon, Jun 23, 2014 at 1:32 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
It would be an enormous mistake to ship a language with region typing /
move semantics and worse before than Java.
You keep saying
On 23/06/14 05:38 PM, Benjamin Striegel wrote:
I feel like Rust might be missing out on the free lunch I expect Swift
to provide
I think that it may be unfounded to expect Swift to spur drastic
improvements to any aspect of LLVM. Apple is already the biggest
benefactor of LLVM, which powers
On Mon, Jun 23, 2014 at 2:44 PM, Daniel Micay danielmi...@gmail.com wrote:
Rust is a performance-centric systems language, Swift is not.
You say that, but I don't see how it applies to my argument. 2 of the 3
options I proposed are purely additive changes to Rust that would not
affect at all
On 23/06/14 05:57 PM, Tony Arcieri wrote:
On Mon, Jun 23, 2014 at 2:44 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
Rust is a performance-centric systems language, Swift is not.
You say that, but I don't see how it applies to my argument. 2 of the 3
On Mon, Jun 23, 2014 at 3:07 PM, Daniel Micay danielmi...@gmail.com wrote:
The language shouldn't be designed around the hypothetical good will of
a corporation. Anyway, I don't know why Swift would have the high-level
SIL IR layer if that's not where they plan on doing these optimizations.
On Mon, Jun 23, 2014 at 3:08 PM, Tony Arcieri basc...@gmail.com wrote:
To flip the question around: what's wrong with Swift's approach?
Or perhaps to ask a less pointed question, what's wrong with Swift's
approach besides making the slow operators the default?
--
Tony Arcieri
On Mon, Jun 23, 2014 at 5:38 PM, Benjamin Striegel
ben.strie...@gmail.com wrote:
I'd like to also note that Apple has no external incentive to improve Swift.
Objective-C was a dead language before Apple's fiat rocketed it into the
position of world's third-most-popular programming language.
On 23/06/14 06:08 PM, Tony Arcieri wrote:
On Mon, Jun 23, 2014 at 3:07 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
The language shouldn't be designed around the hypothetical good will of
a corporation. Anyway, I don't know why Swift would have the
On 23/06/14 06:34 PM, comex wrote:
On Mon, Jun 23, 2014 at 5:38 PM, Benjamin Striegel
ben.strie...@gmail.com wrote:
I'd like to also note that Apple has no external incentive to improve Swift.
Objective-C was a dead language before Apple's fiat rocketed it into the
position of world's
On 23/06/14 08:16 PM, John Regehr wrote:
I do think Rust should exposed either `checked { }` or operators for
checked arithmetic along with an opt-in lint to deny the unchecked
operators. You can opt-out of a lint for a function/impl/module after
opting into it at a higher scope.
I'm just
the fact is that everyone is an optimist when it comes to integer
overflow bugs. People just do not think they're going to get bitten.
I agree, and I don't think anyone else here is going to try to argue that
this doesn't cause real bugs. As so often seems to be the case, language
design
In short:
- everybody wants checked integer arithmetic because it helps to
write better code (thanks to compile time and runtime errors)
- nobody wants to pay the price in performances, but maybe in the
future, hardware++ will make it easier... or so on...
What about:
- Defining safe integer
On 23/06/14 11:58 PM, François-Xavier Bourlet wrote:
In short:
- everybody wants checked integer arithmetic because it helps to
write better code (thanks to compile time and runtime errors)
- nobody wants to pay the price in performances, but maybe in the
future, hardware++ will make it
On Mon, Jun 23, 2014 at 1:49 PM, Daniel Micay danielmi...@gmail.com wrote:
On 23/06/14 04:00 PM, Gregory Maxwell wrote:
On Mon, Jun 23, 2014 at 12:50 PM, Daniel Micay danielmi...@gmail.com
wrote:
The discussion here is about checking for both signed / unsigned integer
overflow, as in
On Tue, Jun 24, 2014 at 1:17 AM, Jerry Morrison jhm...@gmail.com wrote:
Does `checked { }` mean all functions within that scope use checked-integer
arithmetic? This sounds great to me.
Bikeshed: If this happens there should also be a module-level
attribute alternative to avoid unnecessary
On 24/06/14 01:22 AM, comex wrote:
On Tue, Jun 24, 2014 at 1:17 AM, Jerry Morrison jhm...@gmail.com wrote:
Does `checked { }` mean all functions within that scope use checked-integer
arithmetic? This sounds great to me.
Bikeshed: If this happens there should also be a module-level
attribute
On 24/06/14 01:34 AM, Daniel Micay wrote:
On 24/06/14 01:22 AM, comex wrote:
On Tue, Jun 24, 2014 at 1:17 AM, Jerry Morrison jhm...@gmail.com wrote:
Does `checked { }` mean all functions within that scope use checked-integer
arithmetic? This sounds great to me.
Bikeshed: If this happens
Hello,
I'm looking through the File API at http://doc.rust-lang.org/std/io/ and I
don't see a way to open a file in binary-mode vs text-mode. It seems the
default is binary mode from tests that I've done. AFAIK, this only matters
on Windows since a carriage return would not be returned to the
Folks,
I'm happy to announce that Cargo is now ready to try out!
The Cargo repository is now at https://github.com/rust-lang/cargo and you
can learn all about it at http://crates.io/. Don't forget to check out the
FAQ at http://crates.io/faq.
You can build Cargo from master using the latest
There is an Ubuntu PPA available at
https://launchpad.net/~cmrx64/+archive/cargo, for use on travis or
otherwise.
On Mon, Jun 23, 2014 at 10:50 PM, Yehuda Katz wyc...@gmail.com wrote:
Folks,
I'm happy to announce that Cargo is now ready to try out!
The Cargo repository is now at
On Mon, Jun 23, 2014 at 10:32 PM, Daniel Micay danielmi...@gmail.com
wrote:
On 24/06/14 01:17 AM, Jerry Morrison wrote:
Does `checked { }` mean all functions within that scope use
checked-integer arithmetic? This sounds great to me.
It would only apply to local operations. It's not
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
901 - 1000 of 8896 matches
Mail list logo
