For the specific issue of exponentiation, you might be interested in
https://github.com/rust-lang/rfcs/pull/172
On Fri, Jul 25, 2014 at 9:26 AM, Gregor Cramer rema...@gmx.net wrote:
Hi Marijn,
Firstly, blanket statements like This makes generic programming
impossible and it does not
I'd be in.
On Thursday, March 13, 2014, Clark Gaebel cg.wowus...@gmail.com wrote:
Hey I'm in NYC and think some sort of rust meet-up would be neat. Anyone
out there?
___
Rust-dev mailing list
Rust-dev@mozilla.org
Can you point to any scripting langs whose lines equivalent just silently
ignores errors? I'm not aware of any; even perl will at least populate $!.
I opened https://github.com/mozilla/rust/issues/12130 a little while ago
about if_ok!/try! not being usable from main and the limitations for
I'm not a huge fan of this proposal. It makes declarations longer, and it
removes the visual consistency of FooT,U everywhere, which I think
introduces its own pedagogical issue.
The recent addition of default type parameters, though, makes me think
there's a reasonable change that increases
3 extra characters isn't doing anything to stop consenting adults.
Nobody's saying get rid of mutable variables, just that it seems like a
waste of limited resources to figure out how to streamline them when in
general their use should be limited to where necessary.
Python isn't busy trying to
You *should* get sick of writing 'let mut' all over the place, not just b/c
of the syntax but b/c you're using mutable variables all over the place.
Casual mutability kills maintainability.
Affordances matter. I'm convinced that the reason Option.unwrap() is used
so frequently is b/c it's the
open() feels like the clear winner here. Channel::new_pipe is annoying
because it's long and because channels and pipes are different things (
http://en.m.wikipedia.org/wiki/Pipe_flow),
And aren't we down to naming? I thought the design sounded mostly settled
from the last conversation, and
Also, +1 for source and sink, I still get port and channel mixed up.
On Thursday, January 23, 2014, Jason Fager jfa...@gmail.com wrote:
open() feels like the clear winner here. Channel::new_pipe is annoying
because it's long and because channels and pipes are different things (
http
If you're pushing to an unbounded vec in a tight loop you've got
fundamental design issues. If you're pushing to a channel, you've got
something like a server under load. Use cases matter.
About the deadlock scenario, why aren't non-blocking sends sufficient to
address that concern? I'd
I work on a system that handles 10s of billions of events per day, and we
do a lot of queueing. Big +1 on having bounded queues. Unbounded
in-memory queues aren't, they just have a bound you have no direct control
over and that blows up the world when its hit.
The only reason to have a queue
and make it easy to apply back pressure when the assumptions
behind those purposes go awry.
On Thursday, December 19, 2013, Patrick Walton wrote:
On 12/19/13 6:31 AM, Jason Fager wrote:
I work on a system that handles 10s of billions of events per day, and
we do a lot of queueing. Big +1
AM, Jason Fager jfa...@gmail.com wrote:
Okay, parallelism, of course, and I'm sure others. Bad use of the word
'only'. The point is that if your consumers aren't keeping up with your
producers, you're screwed anyways, and growing the queue indefinitely isn't
a way to get around
I solved these problems somewhat clunkily using an enum:
https://github.com/jfager/d3cap/blob/master/multicast.rs
It's not pretty but it gets the job done until the various issues around
this get worked out.
On Thursday, November 14, 2013, Diego Ongaro wrote:
Hi all,
My program starts a
or recursive data structures. But beyond that, am I ever going
to get myself in trouble not remembering the details of the difference
between how ~T works vs ~[T]?
On Thursday, November 7, 2013, Daniel Micay wrote:
On Thu, Nov 7, 2013 at 7:49 PM, Jason Fager jfa...@gmail.com wrote:
Can you
Doesn't seem like enough bang for the buck to me. In your first example you
save 3 vertical lines but get a really wide one in return, and lose
some indentation
levels but add more syntax and conceptual overhead to the language.
Might be my lack of imagination, but the feature doesn't seem to
an Option.
-Kevin
On Aug 4, 2013, at 4:45 PM, Jason Fager jfa...@gmail.com wrote:
Of course. I think I'm reacting more to the possible use cases you
described for option 3 than the actual meaning of it. It seems like a
really bad idea to design iterators that would take advantage
future. Works for me for now,
though.
On Sat, Jul 6, 2013 at 11:31 AM, Ashish Myles marci...@gmail.com wrote:
On Sat, Jul 6, 2013 at 5:45 AM, Jason Fager jfa...@gmail.com wrote:
I've started implementing traits for fixed-length vectors with a few
macros:
https://gist.github.com/jfager
17 matches
Mail list logo
