From memory running unit tests printed some weird error, which everyone just ignores. Also importC isn't what you think it is - it's for statically compiling C files in your source directory, not importing foreign C libs you've installed on your system.
I definitely think there's a place for a GC'd, memory efficient, natively compiled language. I just wish after all these years it felt mature.
I am not aware of a common issue like that but D has bugs.
> Also importC isn't what you think it is
That's contrary to my tests: I installed libplot on my system, 'import'ed its .h file to my D source code, called C functions from D, linked with -L-lplot and it worked.
> not importing foreign C libs you've installed on your system
Maybe you mean something else with "importing" but I installed a foreign C library on my system and it just worked without any hand-written D bindings for it.
Not an error I suppose, but doesn't fill me with confidence nonetheless.
$ dub test No source files found in configuration 'library'. Falling back to "dub -b unittest". Performing "unittest" build using /home/lewis/dlang/dmd-2.100.2/linux/bin64/dmd for x86_64. myproject ~master: building configuration "application"... Linking... Running myproject Hello world! (dmd-2.100.2)[lewis@lightgrey myproject]$ micro source/app.d (dmd-2.100.2)[lewis@lightgrey myproject]$ dub test No source files found in configuration 'library'. Falling back to "dub -b unittest". Performing "unittest" build using /home/lewis/dlang/dmd-2.100.2/linux/bin64/dmd for x86_64. myproject ~master: building configuration "application"... Linking... Running myproject core.exception.AssertError@source/app.d(9): unittest failure ---------------- ??:? _d_unittestp [0x555fe0e339b1] source/app.d:9 void app.__unittest_L8_C1() [0x555fe0e328b8] ??:? void app.__modtest() [0x555fe0e33888] ??:? int core.runtime.runModuleUnitTests().__foreachbody6(object.ModuleInfo) [0x555fe0e3d9c2] ??:? int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo)).__lambda2(immutable(object.ModuleInfo)) [0x555fe0e3b88f] ??:? int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo))).__foreachbody2(ref rt.sections_elf_shared.DSO) [0x555fe0e42a83] ??:? int rt.sections_elf_shared.DSO.opApply(scope int delegate(ref rt.sections_elf_shared.DSO)) [0x555fe0e42f5b] ??:? int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo))) [0x555fe0e42a11] ??:? int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo)) [0x555fe0e3b861] ??:? runModuleUnitTests [0x555fe0e3d80e] ??:? void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])).runAll() [0x555fe0e342d8] ??:? void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])).tryExec(scope void delegate()) [0x555fe0e34265] ??:? _d_run_main2 [0x555fe0e341ce] ??:? _d_run_main [0x555fe0e33f97] /home/lewis/dlang/dmd-2.100.2/linux/bin64/../../src/druntime/import/core/internal/entrypoint.d:29 main [0x555fe0e328dd] ??:? __libc_start_main [0x7f1a0be25e09] ../sysdeps/x86_64/start.S:120 _start [0x555fe0e327c9] 1/1 modules FAILED unittests Program exited with code 1
If the default project manager barfs out all of that - ??? and all - when you write a simple hello world project with a failing test...
Well I'm not filled with confidence. If you discover such a lack of care at that early of a stage, god knows what it'll be like when you actually start solving problems.
Do you have a view on OCaml?
Every value needs to be tagged, so an `int` only has 31 bits of numeric information.
There's stuff like "Int32.t", but IIRC it takes up 8 bytes for 4 bytes of inty goodness. Then there's BigArray which can store them contiguously, but that doesn't carry over to records.
But I still look forward to D having its place as well.