On Thu, Feb 13, 2014 at 10:05 AM, Simon Sapin simon.sa...@exyr.org wrote:
Proposal:
0. An iterator is said to be well-behaved if, after its .next() method has
returned None once, any subsequent call also returns None.
I agree with the spirit of your proposal. But I would change that
On 04 Mar 2014, at 15:59, Simon Sapin simon.sa...@exyr.org wrote:
On 04/03/2014 13:23, Tommi wrote:
On Thu, Feb 13, 2014 at 10:05 AM, Simon Sapin simon.sa...@exyr.org
mailto:simon.sa...@exyr.org wrote:
Proposal:
0. An iterator is said to be well-behaved if, after its .next()
method has
On 04/03/2014 14:42, Tommi wrote:
I agree that this should be an ill-behaved iterator, but my point is
that according to the specification [1], this is_not_ an ill-behaved
iterator, it's a completely valid one. Given that self.n is less than
10, it correctly returns some elements as Some(...)
On 3/3/14 11:00 PM, Nathan Myers wrote:
My concern is that the examples presented in tutorials must be
compelling to skilled C++ programmers. If we fail to win them over, the
whole project will have been a waste of time. The most skilled
C++ programmers know all too well what mistakes show up
On Mar 4, 2014, at 5:23 AM, Tommi rusty.ga...@icloud.com wrote:
I agree with the spirit of your proposal. But I would change that first
clause above to read:
An iterator is said to be well-behaved when its .next() method always
returns None if the iterator logically has no elements to
As someone looking strongly at rust for things i normally use c++ for, I'm
not switching for memory safety. When I need real performance (i.e. When
I'm likely to switch to c++), i frequently do a lot of unsafe things in
either language.
I was sold on rust because it's a syntactically
Every time there is a new language, developers have to start to
developing from scratch the same algorithms.
The alternative has been to use C libraries already built since is much
easier to interface with other languages and a lot of languages will let
you call C functions directly.
But C
On 3/4/14 11:43 AM, John Mija wrote:
I'm supposed that a linker could be built to link that intermediate file
together to a Rust program.
Just use cgo to call Rust.
Patrick
___
Rust-dev mailing list
Rust-dev@mozilla.org
On Tue, Mar 4, 2014 at 11:43 AM, John Mija jon...@proinbox.com wrote:
So, why don't use a simple language but safe like Go?
Go isn't a systems programming language. Go is a low-level managed language
with a mandatory runtime and garbage collector.
--
Tony Arcieri
El 04/03/14 19:51, Tony Arcieri escribió:
On Tue, Mar 4, 2014 at 11:43 AM, John Mija jon...@proinbox.com
mailto:jon...@proinbox.com wrote:
So, why don't use a simple language but safe like Go?
Go isn't a systems programming language. Go is a low-level managed
language with a mandatory
...and the garbage collector?
On Tue, Mar 4, 2014 at 2:56 PM, John Mija jon...@proinbox.com wrote:
El 04/03/14 19:51, Tony Arcieri escribió:
On Tue, Mar 4, 2014 at 11:43 AM, John Mija jon...@proinbox.com
mailto:jon...@proinbox.com wrote:
So, why don't use a simple language but safe
El 04/03/14 20:04, Clark Gaebel escribió:
...and the garbage collector?
The compiler introduces the FUNCDATA and PCDATA directives which contain
information for use by the garbage collector:
http://golang.org/doc/asm
So, that information would not used by the linker like it's used by the
On 04/03/14 02:56 PM, John Mija wrote:
El 04/03/14 19:51, Tony Arcieri escribió:
On Tue, Mar 4, 2014 at 11:43 AM, John Mija jon...@proinbox.com
mailto:jon...@proinbox.com wrote:
So, why don't use a simple language but safe like Go?
Go isn't a systems programming language. Go is a
The other option that I had in mind, would be to build a modified
version of Go (removing some statements) which could be used like
universal language.
Finally, to build an automatic transformer to the desired language,
like a transformer from Go to Rust.
El 04/03/14 20:14, John Mija
El 04/03/14 20:24, Daniel Micay escribió:
On 04/03/14 02:43 PM, John Mija wrote:
So, why don't use a simple language but safe like Go?
Go isn't safe. It has data races.
True, but Go includes a built-in data race detector:
http://golang.org/doc/articles/race_detector.html
Anyway, this
On 04/03/14 03:37 PM, John Mija wrote:
El 04/03/14 20:24, Daniel Micay escribió:
On 04/03/14 02:43 PM, John Mija wrote:
So, why don't use a simple language but safe like Go?
Go isn't safe. It has data races.
True, but Go includes a built-in data race detector:
The problem:
When you iterate over elements of an Iterator in a for-loop, you effectively
end up checking whether the Iterator is empty or not twice per element, i.e.
once inside the Iterator's next method and once in doing match for the Option
returned by the next method.
Example:
struct
On Tuesday, March 4, 2014, John Mija jon...@proinbox.com wrote:
True, but Go includes a built-in data race detector:
http://golang.org/doc/articles/race_detector.html
A data race detector can only detect problems when it observes them.
Unfortunately data races are typically finnickey,
On 2014-03-04, at 21:37 , John Mija jon...@proinbox.com wrote:
El 04/03/14 20:24, Daniel Micay escribió:
On 04/03/14 02:43 PM, John Mija wrote:
So, why don't use a simple language but safe like Go?
Go isn't safe. It has data races.
True, but Go includes a built-in data race detector:
On 04/03/14 03:55 PM, Tony Arcieri wrote:
On Tuesday, March 4, 2014, John Mija jon...@proinbox.com
mailto:jon...@proinbox.com wrote:
True, but Go includes a built-in data race detector:
http://golang.org/doc/__articles/race_detector.html
On 04/03/14 03:51 PM, Tommi wrote:
The problem:
When you iterate over elements of an Iterator in a for-loop, you effectively
end up checking whether the Iterator is empty or not twice per element, i.e.
once inside the Iterator's next method and once in doing match for the
Option returned
On 04/03/14 04:04 PM, Clark Gaebel wrote:
I like the current interface for iterators. :( Couldn't a similar
transformation be done as a special-purpose optimization pass?
The check is already eliminated by LLVM in most cases. The exceptions
are caused by a fixable limitation:
That works for the 90% case (pointer/reference types), but it'd be nice to
have something more generic that works for everything.
- Clark
On Tue, Mar 4, 2014 at 4:08 PM, Daniel Micay danielmi...@gmail.com wrote:
On 04/03/14 04:04 PM, Clark Gaebel wrote:
I like the current interface for
On 04 Mar 2014, at 23:05, Daniel Micay danielmi...@gmail.com wrote:
On 04/03/14 03:51 PM, Tommi wrote:
The problem:
When you iterate over elements of an Iterator in a for-loop, you effectively
end up checking whether the Iterator is empty or not twice per element, i.e.
once inside the
On 04/03/14 04:09 PM, Clark Gaebel wrote:
That works for the 90% case (pointer/reference types), but it'd be nice
to have something more generic that works for everything.
- Clark
The optimization already works in other cases. It only fails to work in
a subset of cases where the iterator
I assumed the compiler might be able to optimize the extra check away if
the .next() method gets inlined, but not in the general case. Thus I was
trying to provide a general solution that wouldn't rely on back-end
optimizations. Are you saying I assumed wrong?
Optimization passes are almost
Then, would be a bad idea to use a sub-set of Go to build algorithms
(i.e. decodecs of audio/video) and with an automatic transformer to
generate the code to other language?
So, the code is written once, but it could be transformed to whatever
language --once there is a transformer--.
El
On Tue, Mar 4, 2014 at 3:29 PM, John Mija jon...@proinbox.com wrote:
Then, would be a bad idea to use a sub-set of Go to build algorithms (i.e.
decodecs of audio/video) and with an automatic transformer to generate the
code to other language?
So, the code is written once, but it could be
This is getting off topic but...
C++ has legitimate reasons (no modules, no jit) why it can't be
fast-building. Rust has much less. I really hope one day a JIT will be
supported to get REALLY fast turnaround times during development.
- Clark
On Tue, Mar 4, 2014 at 9:31 PM, comex
Well, since comments are disabled in the blog, I will analyze the points
made in the article.
** Ownership **
int *dangling(void)
{
int i = 1234;
return i;
}
First, the way it is written. Please!
This is not C++ ! (Well, it is C, therefore it is also C++, OK)
I think it is written so in
You are only considering the simplest uses of references. Consider iterator
invalidation, deletion of the object referenced by the this pointer,
truncation of a vector containing an object to which references are live, etc.
C++ references are not memory safe and no compiler warnings can make
If I select Rust as my main language, I don't think I have any reason to
write new code in Go. Go away!
2014年3月5日 上午3:44于 John Mija jon...@proinbox.com写道：
Every time there is a new language, developers have to start to developing
from scratch the same algorithms.
The alternative has been to
I'm seeing unnecessarily hostile and dismissive comments from several
participants here. If you can't be civil, then ignore the thread and move
on.
On Tue, Mar 4, 2014 at 11:40 PM, Liigo Zhuang com.li...@gmail.com wrote:
If I select Rust as my main language, I don't think I have any reason to
As follow up to the recent discussion about limited versus unlimited
channels consider the following story. There is an expensive commercial
Java software that consists of several components that run on different
servers for performance and fault tolerance.
The software extensively uses bounded
34 matches
Mail list logo
