Example of Rust code

Peter Alexander peter.alexander.au at gmail.com
Sat Aug 11 11:37:38 PDT 2012


On Saturday, 11 August 2012 at 18:04:29 UTC, Paulo Pinto wrote:
> On Saturday, 11 August 2012 at 16:12:14 UTC, Peter Alexander 
> wrote:
>> On Saturday, 11 August 2012 at 14:45:55 UTC, Russel Winder 
>> wrote:
>>> On Sat, 2012-08-11 at 02:19 +0200, David Piepgrass wrote:
>>> […]
>>>> I hope someday to have a programming system whose features 
>>>> are not limited to whatever features the language designers 
>>>> saw fit to include -- a language where the users can add 
>>>> their own features, all the while maintaining "native 
>>>> efficiency" like D. That language would potentially allow 
>>>> Rust-like code, D-like code, Ruby-like code and even ugly 
>>>> C-like code.
>>>> 
>>>> I guess you don't want to be the one to kickstart that PL. 
>>>> I've been planning to do it myself, but so far the task 
>>>> seems just too big for one person.
>>>
>>> <quasi-troll>
>>> Isn't that language Lisp?
>>> </quasi-troll>
>>
>> You missed the native efficiency part :-)
>>
> You mean like the Common Lisp compilers that are able to beat 
> FORTRAN compilers
> in floating point computations?
>
> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.54.5725
>
> --
> Paulo

Not sure where you read that in the paper.

 From the conclusion:

"We have demonstrated that the speed of compiled Common Lisp 
code, though today somewhat slower than that of the best compiled 
Fortran, could probably be as efficient, and in some ways 
superior."

Probably is the operative word there.

> Most modern Lisp implementations employ JITing one way or 
> another, so
> you do get native code. Just not on the first run through a bit 
> of code.

JIT has its limits. A dynamically typed language is still 
dynamically typed once compiled. Sure the JIT may be able to 
deduce the types in some cases, but not all.

I do see your point, but in general it's still not as fast as 
optimised C.


More information about the Digitalmars-d mailing list