Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Currently there is no serious alternative to C++

71 views
Skip to first unread message

Melzzzzz

unread,
Apr 3, 2015, 11:59:36 PM4/3/15
to
That is my conclusion.
With C++11 & 14, I can't see any new language that can replace it.

My considerations:

1. rust:
- Compiling of compiler does take very long time because it compiles
libraries as single source and therefore does not utilize multiple
cores
- doing simple things require unsafe blocks and ugly unsafe code
eg:
/// Pop a mutable reference off the head of a slice, mutating the slice
to no

/// longer contain the mutable reference. This is a safe operation
because the

/// two mutable borrows are entirely disjoint.

fn shift_mut_ref<'a, T>(r: &mut &'a mut [T]) -> Option<&'a mut T> {

use std::mem;

use std::raw::Repr;



if r.len() == 0 { return None }

unsafe {

let mut raw = r.repr();

let ret = raw.data as *mut T;

raw.data = raw.data.offset(1);

raw.len -= 1;

*r = mem::transmute(raw);

Some({ &mut *ret })

}

}

http://benchmarksgame.alioth.debian.org/u64q/program.php?test=nbody&lang=rust&id=1
I don;t think this requires comments...

2. go
- does not have templates, therefore there are tools to generate code
from templates which is so 90es...
- optimizer is in infant stage.
- calls through interfaces are slow
- calls to external libs are very costly (this is remedied in gccgo,
but than code isn't portable to standard go compiler)
- only good for server side programming that does not have heavy numeric
processing, because of slow code.
- java bits it hands down
+ could replace python, but no more
+ extremely fast compilation

3. nim
- one man project
- small user base
- python/pascal syntax with indentation instead of {}
- buggy
+ compiles to c/c++ and obj c even java script
+ templates and very innovative macros.
+ multi methods
+ supports both GC and manual memory management
- not nearly as good as C++ , yet, but promising

That's runt for now ;)

woodb...@gmail.com

unread,
Apr 4, 2015, 1:47:56 AM4/4/15
to
I think it's hip, but I'm working on something similar.

> - optimizer is in infant stage.
> - calls through interfaces are slow
> - calls to external libs are very costly (this is remedied in gccgo,
> but than code isn't portable to standard go compiler)
> - only good for server side programming that does not have heavy numeric
> processing, because of slow code.
> - java bits it hands down
> + could replace python, but no more
> + extremely fast compilation

I don't think Go will be able to put much of a dent in C++.

>
> 3. nim
> - one man project
> - small user base
> - python/pascal syntax with indentation instead of {}
> - buggy
> + compiles to c/c++ and obj c even java script

Why do you consider that to be a plus? It might be
too many languages.

> + templates and very innovative macros.
> + multi methods
> + supports both GC and manual memory management
> - not nearly as good as C++ , yet, but promising
>

What language is the Nim compiler written in? I saw
something on Wikipedia about it being written in Pascal.
That might be considered a weakness.

Happy Passover. Happy Holy Week.

Brian
Ebenezer Enterprises
http://webEbenezer.net

Melzzzzz

unread,
Apr 4, 2015, 1:58:14 AM4/4/15
to
It mixes nicely eg if you write C++ as it generates C++ files.
One other thing I forgot to mention it only requires libc
and C compiler in order to be compiled.

>
> > + templates and very innovative macros.
> > + multi methods
> > + supports both GC and manual memory management
> > - not nearly as good as C++ , yet, but promising
> >
>
> What language is the Nim compiler written in? I saw
> something on Wikipedia about it being written in Pascal.

Hm, no, it is written in Nim as I see sources.

> That might be considered a weakness.
>
> Happy Passover. Happy Holy Week.

Same to you ;)

red floyd

unread,
Apr 4, 2015, 3:06:12 PM4/4/15
to
On 4/3/2015 8:59 PM, Melzzzzz wrote:
> That is my conclusion.
> With C++11 & 14, I can't see any new language that can replace it.
>
> My considerations:
>
> 1. rust:

The other problem is, of course, you can't pause your program
for a specified time, because as we all know, "Rust Never Sleeps"



0 new messages