[GTALUG] Rust intro

[Nicholas Krause]

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 <xerofoify at gmail.com>, 
> 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 
>>> <talk at gtalug.org>, wrote:
>>>>
>>>>
>>>> On 12/31/19 11:57 AM, D. Hugh Redelmeier via talk wrote:
>>>>> | From: Tom Low-Shang via talk <talk at gtalug.org>
>>>>>
>>>>> | 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 talk at gtalug.org
>>>>> Unsubscribe from this mailing list 
>>>>> https://gtalug.org/mailman/listinfo/talk
>>>>
>>>> ---
>>>> Post to this mailing list talk at gtalug.org
>>>> Unsubscribe from this mailing list 
>>>> https://gtalug.org/mailman/listinfo/talk
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/talk/attachments/20200102/6c81b273/attachment.html>