Hi, Adrian,
Currently Rust uses static linking to build executables. This means that the
simplest «hello world» program utilizing standard library will take all of this
library and all dependent libraries, including Rust runtime, into itself.
That’s why the binary is large.
If you want to use
Hi Vladimir,
Awesome - got the same executable size.
Thanks a million for such quick and accurate response.
Back to my Rust tutorial... :)
Regards.
- Adrian.
On Fri, Jul 11, 2014 at 10:18 AM, Vladimir Matveev dpx.infin...@gmail.com
wrote:
Hi, Adrian,
Currently Rust uses static linking to
I tried the rust-http's comparison with go from here.
https://github.com/chris-morgan/rust-http/tree/master/comparisons
Using the default code, which I guess uses 1:1 scheduling, rust falls
behind go when concurrency goes greater than the number of cores (4). I
guess this is to be expected as
This is a known performance bug in the green schedulers being tracked
at https://github.com/rust-lang/rust/issues/11730.
To see the difference, you can run with RUST_THREADS=1 when using the
green scheduler.
On Fri, Jul 11, 2014 at 1:39 PM, Chandru chandru...@gmail.com wrote:
I tried the
Rustafarians,
As we head toward 1.0, we need to do do more than stabilize the
language: we need a broad and stable base of libraries as well.
One of the key steps in that direction is reaching firm decisions on a
number of API design questions, ranging from bikesheddy stuff like
naming
Thanks, Aaron. This is going to be an important reference for authors. I
love the sensible organization and that it's already seeded with many of
our existing conventions.
On 07/11/2014 11:49 AM, Aaron Turon wrote:
Rustafarians,
As we head toward 1.0, we need to do do more than stabilize the
On Wed, Jul 9, 2014 at 12:57 AM, Brian Anderson bander...@mozilla.com
wrote:
# Impact
Installing rustc to non-default locations will result in an installation
that puts some important libraries in a location the dynamic linker won't
find, will need to be compensated for with
LD_LIBRARY_PATH is not known about by many
The install.sh script now recommends adding an entry to this variable
if it detects that this is necessary, so it's not *entirely* unknown.
This doesn't help, however, if it's considered a bad practice.
1) Link dependencies of rustc statically to it?
On 11/07/14 03:15 PM, Alex Crichton wrote:
LD_LIBRARY_PATH is not known about by many
The install.sh script now recommends adding an entry to this variable
if it detects that this is necessary, so it's not *entirely* unknown.
This doesn't help, however, if it's considered a bad practice.
I believe the thought was for when we *can't* modify things like /usr/bin,
because the user isn't an administrator. Obviously if we were installing
things where they were supposed to go, we wouldn't have a problem finding
libraries, would we now? So no-one's proposing we dump a bunch of libraries
Hi Rust designers,
I'm curious why rust uses colon : instead of assignment = when initialize
an object. What is the rationale behind this?
From what I see, `Point { x = 2, y = 3 }` looks much better than `Point { x :
2, y : 3}`.
Since most of the syntax rules are consistent in rust, why we
Because of JavaScript, basically.
Patrick
On July 11, 2014 9:21:20 PM PDT, 范长春 changchun@qq.com wrote:
Hi Rust designers,
I'm curious why rust uses colon : instead of assignment = when
initialize an object. What is the rationale behind this?
From what I see, `Point { x = 2, y = 3 }`
The short answer is so that struct initialisation, struct types, and struct
de-structuring all have the same syntax.
For more detail, see the discussion in this (rejected and closed) RFC for
changing from using `:` to `=`.
Cheers, Nick
On Sat, Jul 12, 2014 at 4:21 PM, 范长春 changchun@qq.com
Both Issue #14758 https://github.com/rust-lang/rust/issues/14758 (Specify
that int and uint are at least 32 bits on every CPU architecture) and Issue
#9940 https://github.com/rust-lang/rust/issues/9940 (rename `int` and
`uint` to `intptr`/`uintptr`) call for RFCs.
So RFC
14 matches
Mail list logo
