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.
I am not aware of a common issue like that but D has bugs.
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
Is this one of the dub hello worlds? Looks like it.... but it also says line 8 and the built in thing doesn't have a line 8. So what is the code there? If it is `assert(0)`, you're seeing the result of the test. The info is a bit spammy since it prints all the mostly-useless stack trace but there's some situations beyond hello world where the extra info helps explain why the test failed.
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.
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.
C# might be that language, now that .NET 7 will be bringing .NET Native into mainline .NET (Native AOT), or Swift on Apple platforms (RC is a GC algorithm).
But I still look forward to D having its place as well.
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.