Go vs. D [was Re: Rust vs Dlang]

[Alan]

On Tuesday, 26 March 2013 at 04:11:05 UTC, Geancarlo Rocha wrote:
> That's julia's(http://julialang.org/) goal, but of course it's 
> not nearly polished.
>
> I'm interested in this as well, since I'm not totally 
> comfortable about using a pirated MATLAB version and I hear 
> that numpy can't match its performance on "macro" code.

I have heard of Julia and have not really messed with it yet for 
the reason you mentioned (it being in its early stages).

I used MATLAB for a about a year before switching to numpy full 
time. I would totally recommend it. The performance loss (which I 
am not sure is actually there in all problems being solved) is 
really not that big of a deal unless you are doing some pretty 
heavy math, in which case MATLAB is slow compared to using C or 
fortran anyway. Another great thing is that numpy shares a lot of 
the same syntax as MATLAB, so the switch is fairly painless.

If it were just numeric stuff, fortran would work okay (albeit it 
is a chore). I have a small collection of libraries I have 
written so I can execute MATLAB-esque commands for creating 
vectors and doing basic plotting. For example, this works:

call linspace(0, pi, 100, x)
y = sin(x)
call plot2d(x,y)

It's not the cleanest looking thing, but its better than doing it 
from scratch every time :P

What if I wanted to plot a surface? Well, I need to write another 
fortran subroutine for that (which I have). The point is, it gets 
old having to write subroutines to do every little thing. 
Calculating an exponential integral requires me to link to the 
SLATEC library while MATLAB will do it with expint(x).

There are so many things that are commonly used in numeric 
programming and not standard in fortran (or any compiled 
language). Is there some rule that only scripting languages are 
allowed to do these sorts of things easily?

I would LOVE to see a compiled language that ran on par with C or 
fortran and had libraries that executed as cleanly as numpy and 
matplotlib do.