On Fri, Jul 26, 2013 at 1:47 AM, Jonathan S. Shapiro <[email protected]>wrote:

> On Wed, Jul 24, 2013 at 3:24 AM, Ben Kloosterman <[email protected]>wrote:
>
>> Since were discussing rust and gcs this is an interesting post ****
>>
>> ** **
>>
>>
>> http://pcwalton.github.io/blog/2013/06/02/removing-garbage-collection-from-the-rust-language/
>>
>
> Yeah. I had seen this. It's not well thought-out.
>
> GC doesn't need to be the only mechanism or even the majority mechanism,
> but it needs to be part of the portfolio, and it's been shown repeatedly
> that it can't be done in a library. If nothing else, accurate GC support
> imposes constraints on the optimizer and code generator.
>

I agree.

It interests me  more becuase of the direction and social structure of rust
..  Graydon seems to be losing a battle to pull it towards a more C like
language and libs, this may be because somethings are not performing as
expected  ( partially due to the segmented stacks ) . I would see early on
in a language once the syntax   matures that people benchmark it and try to
get efficient libraries, and the more efficient then the more abstract
concepts they will add / use in trhe standrad libs.  eg more string vs
fmt.printf  style .  The gc as a lib is a manifestation of this eg C++ does
it.

As a positive note this will make rust better for embedded systems etc as
the approach is more natural as those systems and the developers come from
 C  , I feel ( how can it be more)  that they will be more successful in
this space  than go etc , (the mongo company just  added a rust driver (
alpha)) .  On a sadder note it  reduces  the higher end eg large server
apps , 3D games , eventing systems all of which would like more use of the
GC .  And as you mentioned before that the language itself could often
decide between a shared and local pointer anyway so they dont always need
to be explicit  making for a nicer and easier syntax..

Ben
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to