>>53684848
Personally I like the D, but it might be cos I'm meet and can't get anything better.

>>53684848
I like some aspects like the symbolic module system, but I don't feel like it gets to a point where you can say "Wow, the next major release totally isn't gonna break my non-trivial software build.", simply because with the all-in-one language approach they might have bitten off more than they can chew.

I mean, they already took a decade or more to redesign the language, figure out which standard library to use and they haven't finished removing their still crap-tier garbage collector from the standard libraries.
Also some other insane decisions, like supporting every C++ ABI that will exists are things why I don't believe in Ds long term success.

So far I've read the book and played a bit, and I really like it. I only hope the GC will be optional in practice, and not only in theory in the future.
It's so much better than sepples.

>>53684848
absolutely fucking love it
to the extent that I'm willing to suffer the incredibly shit GC and use it anyway
it's just that good

wrote a markov chain generator thing the other day, and it made me really appreciate that associative and dynamic arrays are built into the language

string[][string[2]] dict;
string[2] state;

>>53685532
actually come to think of it, maybe 'incredibly shit' is a bit harsh

it's a stop-the-world mark-and-sweep kind of deal, and it's a bit slow, but it's not THAT intrusive

I think andrei's still working on making the standard library and all builtin types usable with no GC. Currently you can turn the GC off but you can't use half the language because it allocates with GC

>>53685574
Will they still put some work in the GC?

I mean, it's nice to have in some use cases, especially, if they get it to be on par with the JVM GC.

>>53684848
I hear it's a nice language with nice features, but since they designed everything around the GC, it completely ruins the language for me.
Shit, it's not even a good, impressive, state of the art GC.

>>53685641
>on par with the JVM GC
I don't think they have the resources to do something like that, but I'm no expert on garbage collectors.

I think the current java garbage collector is similar, except it's more optimised for concurrency, which is a big deal these days when every processor out there has 8 or more logical cores - but I heard the java guys are currently working on swapping it out for some spooky state of the art kind of one (I don't follow java that closely)

The latest work they've done with memory management is this
http://erdani.com/d/phobos-prerelease/std_experimental_allocator.html
which is intended to standardise allocation so they can swap out allocators more easily. It's not too usable right now, because it's not builtin, so you have to use everything explicitly, and all of the builtin allocations will just use the bog standard allocator anyway

>>53685873
It's something. That said, I'm impressed they have the ressources for most other tasks.

>>53685873
should have mentioned you can use malloc with it
http://erdani.com/d/phobos-prerelease/std_experimental_allocator_mallocator.html

currently you can call malloc from core.memory but the GC still keeps track of it and will collect it if there are no references to it open
with std.experimental's mallocator you can use it without the GC (but again, it's not builtin so it would be difficult)

>>53685947
andrei and walter are pretty amazing

>>53685994
>andrei and walter are pretty amazing
Perhaps, but relying on two elderly persons that could have heart attacks at any minute now to manage a whole language + eco system sounds dangerous.

>>53686071
They're not THAT old
Andrei's like 40 something

>>53686071
You must be a young teen if you think Alexandrescu is elderly.
And I'm saying that as a twentysomething.

>>53686151
OK, but still, if those two are doing the main part of the work, it's still a small truck number.

>>53686071
and its closed source. Shit. What happens if walter kicks the bucket. how can we take over?

>>53686227
Remember, programmers typically are kill earlier.

>>53685532
Is string[][string[2]] dict a dict mapping 2-element string arrays to dynamic string arrays?

>>53686262
Nice made up statistic.
Remember, artistic works of fiction are typically falsehoods.

>>53686251
The frontend is open source, only the Digital Mars backend is closed. But there are open source backends, one using llvm, other using gcc.

>>53686344
Last time I checked - a year ago or so - some dub packages required DMD and DMC++ for some obnoxious reason. Did that change in the meantime?

>>53686388
I have no idea what a dub package is. I only used GDC (the GCC backend) to learn D.

>>53686251
>>53686344
DMD's frontend is free and the backend is technically nonfree, but open source

https://github.com/D-Programming-Language/dmd/tree/master/src/backend

>>53686404
It's a package manager for D, which works surprisingly well for a package manager.

I'm not sure if it's the official package manager, though.

>>53686293
yep
string[2] state is the last two words that it wrote. To get the next word, it searches for state in dict and picks a random element

this is the code to create the dictionary from stdin

void create_dict() // I know I could have done this in one pass, but it's fast enough that I don't really care
{
    string[] corpus;
    
    foreach (char[] line; stdin.byLine)
        corpus ~= line.to!string.lex; // lex splits by spaces
    
    string[2] state = [ corpus[0], corpus[1] ];
    
    foreach (string word; corpus[2 .. $])
    {
        dict[state] ~= word; // ~ is the array append operator
        state[0] = state[1];
        state[1] = word;
    }
}

and the code to get the next word is

dict[state][uniform(0, $)];

($ is replaced with the array's length when in [], and uniform(a, b) gets a random number in [a, b))

>>53686475
Something like pip?
>>53686494
Thanks!

I'd like to make a project with D, but I'd like to use OpenCV, which doesn't have a proper C API, making things difficult. I'll try maybe with SWIG.

>>53686521
>Something like pip?
Basically, but unlike pip it even compiled SDL on multiple OSes whereas pip even screwed up on cherrypy.