On 1/2/20 9:59 AM, David Mason wrote:
Rust uses a reference-counting collector for allocations that go
beyond what the borrow-checker can handle. You have to explicitly use
the RC allocation. Reference counting, as you may know is a more
predictable memory allocation technique and works well for many data
structures, such as trees (binary or otherwise). It however has
problems with cyclic data structures (doubly-linked lists, general
graphs, etc.). Since the reference-counted allocations are explicit,
it is usually not onerous for the programmer to handle the
de-allocation of these data structures. Having a built-in RC collector
is a big win over C/C++ - your effective alternatives.
Thanks for letting me know. Don't know if it will be solved as that's a
problem in my view.
Nick
If you aren’t willing to deal with the reference counter, your closest
choices to Rust are D, Nim, or (less close) Go. But if you look at the
benchmark game site, you’ll see that garbage-collected languages are
often a factor of 3 slower than Rust/C/C++. If that degree of
performance matters to you, I think you should use Rust rather than C
or C++. If it doesn’t, you have a plethora of choices, including Go,
Java, C#, Haskell, Python, Lisp, or (my favoured) Smalltalk.
../Dave
On Jan 1, 2020, 6:09 PM -0500, Nicholas Krause <[email protected]>,
wrote:
On 1/1/20 11:44 AM, David Mason wrote:
Borrowing is entirely a compile-time analysis. There is no runtime
impact (other than the fact that you can get away without a garbage
collector - in a safe way).
The Learn Rust the Dangerous way article is very good, by the way! I
heartily endorse it for the C-philes among GTALUG. If you haven’t
read it, one of the things that might convince you is that the
leaderboard for this highly-optimized n-body simulation has Rust in
the first-place
https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/nbody.html -
faster than C, C++, Fortran or Ada. I’ve added it to my list of
resources for Rust: https://cps506.scs.ryerson.ca/Resources/rust.html
Ownership makes sense its a compiler version of smart pointers. My
concerns are still:
What about circular references in which the owner depends on data
from the child
but cannot free it due to the knowledge also depending on the parent.
Binary trees
are a problem here. Or you must assume like garbage collectors this
never occurs
and this is one way to get memory leaks in a lot of garbage
collectors fast.
Rust seems fine for a lot of things but this one case does not seem
solved at least
in my knowledge or is assumed to not be a big issue and I could be
wrong but
from my limited research it appears not,
Nick
../Dave
On Dec 31, 2019, 4:22 PM -0500, Nicholas Krause via talk
<[email protected]>, wrote:
On 12/31/19 11:57 AM, D. Hugh Redelmeier via talk wrote:
| From: Tom Low-Shang via talk <[email protected]>
| I'm interested in your thoughts on Rust if you attended the talk.
The talk was mostly a guided creation of a program. So I don't think
that it answered any of your questions.
| I'm currently learning Rust the old fashioned hacker way (from
books and
| other people's code :)). My biggest mistake was trying to use
Rust with
| SDL2 to display some graphics. My head still hurts from banging
it into
| a wall called 'lifetimes'. :)
The whole idea of borrowing etc. is fundamental to Rust and how it
ensures safety. Without garbage collection. If you don't like or
understand this approach, Rust isn't useful.
Hugh,
I've a question about how borrowing is implemented internally as it
can lead
to a problem, if I allow lots of memory can my program stall
because of this
at the end of a block. In addition due to this does borrow checking
limit or
not implement something like freelists or caching to get better
usage of the
CPU cache as that's also a concern.
Thanks,
Nick
---
Post to this mailing list [email protected]
Unsubscribe from this mailing list
https://gtalug.org/mailman/listinfo/talk
---
Post to this mailing list [email protected]
Unsubscribe from this mailing list
https://gtalug.org/mailman/listinfo/talk
---
Post to this mailing list [email protected]
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
