[a / b / c / d / e / f / g / gif / h / hr / k / m / o / p / r / s / t / u / v / vg / vm / vmg / vr / vrpg / vst / w / wg] [i / ic] [r9k / s4s / vip / qa] [cm / hm / lgbt / y] [3 / aco / adv / an / bant / biz / cgl / ck / co / diy / fa / fit / gd / hc / his / int / jp / lit / mlp / mu / n / news / out / po / pol / pw / qst / sci / soc / sp / tg / toy / trv / tv / vp / vt / wsg / wsr / x / xs] [Settings] [Search] [Mobile] [Home]
Board
Settings Mobile Home
/g/ - Technology

Name
Options
Comment
Verification
4chan Pass users can bypass this verification. [Learn More] [Login]
File
  • Please read the Rules and FAQ before posting.
  • You may highlight syntax and preserve whitespace by using [code] tags.

08/21/20New boards added: /vrpg/, /vmg/, /vst/ and /vm/
05/04/17New trial board added: /bant/ - International/Random
10/04/16New board for 4chan Pass users: /vip/ - Very Important Posts
[Hide] [Show All]


[Advertise on 4chan]


File: dlang.jpg (64 KB, 1024x778)
64 KB
64 KB JPG
What's the problem with this?
>>
It really is a good language, even though it does have a GC. Its GC is pretty efficient, and people who are immediately turned away by the presence of a GC are just GC-phobic. Plenty of software like Unreal Engine has a GC and doesn't have any performance deficits.

The problem is, no one wants to use it. It came out in the shadow of more popular languages, and when it first came out, it had two different standard libraries. So it was really difficult to collaborate with other people when person X is using one form of the standard library, and person Y was using the opposite.
>>
>>101424345
>can't consume C headers
>subtly incompatible types
>garbage collector
>phobos binary size
>too many features
>compile time abstraction autism
>mangled symbols

I tried adopting the BetterC subset but I could not find any excuse to use it over C or a higher level lang.

The problem is that C caught up and stopped being bad, while D has too many features for anyone valuing their time to bother with. The best languages are small, D is conceptually bloated.
>>
>>101424402
>>subtly incompatible types
What does this mean?
>>
File: Zero.png (93 KB, 500x500)
93 KB
93 KB PNG
>>101424402
>too many features

Yeah. Back when I was interested in D, there were just SO many things to learn. D has so many keywords it's insane.
>>
File: 1693097814608553.png (1.58 MB, 1024x1019)
1.58 MB
1.58 MB PNG
>>101424345
There's no problem
Just very slow adoption because no PR (compared to rust)
>>
>>101424439
Some type names like "long" mean something else than in C, which creates a bit of friction when trying to interface between languages. Should've just done it like Zig while letting people make aliases that match their C compiler.

Another problem is that while D can compile and export C ABI symbols, it can't provide a header for other langs (C, C++, LuaJIT) to consume. You have to write those manually or generate them somehow.
>>
Fundamentally it brought the wrong features at the wrong time and failed to get initial interest, and without that initial interest it never gained enough mindset to be successful and mainstream. Whether or not it's actually a good language is irrelevant at this point because it's never going to go anywhere.
>>
>>101424383
D's GC is the worst one of all languages, and probably never updated since the first version
that's the problem with D. the D team never tried to imrpove or polish the core experience, instead they just followed the trends. and even today instead of just fixing GC they're impleneting a borrow checker!
>>
>>101424345
People both love and hate the GC.
The adoption by editors is kinda bad, basically if you're not on VS you're fucked, most editors i've seen have completely broken D syntax highlighting support.
I just hope Walter can get C/C++ interop in and reconcile the GC complaints, then it should be fine. IME the GC doesn't cause problems if used properly but i understand the fear around it esp for people used to Java's GC.
>>
>Why are we compiling code anyway?
https://www.youtube.com/watch?v=8GV_TuYk3lk&t=1936s
>>
>>101424345
Its logo is a dripping bellend.
>>
>>101424383
>>101424454
I'm gonna listen to this btw
>>
>>101424345
It's literally the greatest language in existence right now.

I am dead fucking serious about that. The problem is nobody uses it, because the contributors and maintainers are just not good at getting splash and prestige and "selling it" to the world the way Rust faggots are.

D, as it stands now, is infinitely better than WHATEVER YOU'RE USING. Even C, because it is C, just better. I'm sick of the ancient tired cliche "like C++ done right" but IT IS. It's sane, safe, syntactically clean, expressive, powerful, and fucking fast.

>>101424402
>can't consume C headers
WRONG WRONG WRONG. Kill yourself you fucking liar. D's importC is oen of its greatest strengths, it literally JUST WORKS, you can literally just fucking import C code and it works.

>subtly incompatible types
What types? Be specific, this statement is meaningless.
>garbage collector
Opt-in, opt-out. You have can do malloc and reference counting.
>phobos binary size
Hey grandpa I like the Apple IIe too but it's time to grow up.
>too many features
t. "My brain is too small"
>compile time abstraction autism
???
>mangled symbols
https://dlang.org/spec/abi.html

lmao you're fucking trash. every single one of your "criticisms" is made-up garbage.
>>
>>101424345
C++ got better
>>
>>101424766
That has ALWAYS been a problem in C and C++ and the other C derivatives. It's a fucking forever-problem. D circumvents this by saying "look, an int is 32-bits and a long is 64, and this will never change". Just like ANY OTHER C derivative, if you want to interface with unknown code or architecture you need to make sure your C code is using unambiguous typedefs like int32 and int64, this has never been any different.
>>
>>101425144
I'm slowly coming around to the GC, despite explicitly avoiding it in actual commercial products and writing my own malloc-based libraries. I think the early experience of the GC in 32-bit environments soured the taste and turned me against it for years, but it's much better now in modern environments and my performance metrics haven't suffered when I venture to use it. Like any tool, it just requires understanding when and where to use it.

And I still reiterate that you can avoid it completely if you want, or are developing for archaic architecture, or are just more comfortable with manual memory/lifetime management (most GC-adherents have contempt for this, but honestly I think if you're smart enough to handle this and are aware of the risks, it's fine). The advice I offer is to just not bother with @nogc, it's a headache if you don't explicitly need it for specific realtime use cases, like say writing code for a space shuttle or something. Just vet and analyze your code during runtime, there've been improvements in phobos (std lib) over the years to make sure a long of things that don't need to GC-allocate no longer do anymore, despite not being explicitly @nogc. And yes if you want to get philosophical that is a little bit sloppy, but at the end of the day it all works unless you're trying to analyze a language under the lens of religious purity. Everything has baggage, modern D has less than most.
>>
// main.d
import std.stdio;
import cee;
void main() {
auto ci = cInt();
auto cl = cLong();
auto cll = cLongLong();
writefln("[%s] %s", typeof(ci).stringof, ci);
writefln("[%s] %s", typeof(cl).stringof, cl);
writefln("[%s] %s", typeof(cll).stringof, cll);
}

// cee.c
int cInt() {
return 1;
}
long cLong() {
return (long) 2;
}
long long cLongLong() {
return (long long) 3;
}

# rdmd main.d
[int] 1
[int] 2
[long] 3


It literally just works.
>>
import std.stdio;
import core.thread;

void foo(ref int num) {
num = 42;
Fiber.yield();
num = 43;
Fiber.yield();
num = 44;
Fiber.yield();
}

void main() {
int num;
auto f = new Fiber(() => foo(num));
f.call();
writeln(num);
f.call();
writeln(num);
f.call();
writeln(num);
}


Learning about fibers.
>>
>>101424345
kinda slow to compile for my toy projects c/c++ is way faster getting down to 100ms while dmd sits at 1s. I guess it changes at medium/large scale projects? Also lacks modern features we got used to in modern languages there is always some friction in how you do things when you pick it up. Still use it as a c# alternative because thats even slower to compile. I wish it had something like nim orc thats much more appealing than a normal gc.
>>
all they had to do was make C with batteries included for us scrubs who don't want to write our own hash maps

but they added GC and made it instantly obsolete compared to C# and Java.
>>
import std.stdio;
import std.array;

void main() {
int[] vec = [1, 2, 3, 4, 5];
auto app = appender(vec);

app.put(6);
app.put(7);
app.put(8);

vec = app.data;
writeln(vec[$ - 1]);
}


First time I see this appender approach thing.
>>
>>101424445
zig is also fucking bloat, what they're not putting in the language they're putting in the compiler with @intfromfloat(), @floatfromint(), @as(@ptr@cast@to(f32)))))) fuck you it's like rust at this point
>>
>>101424454
>There's no problem Just very slow adoption
you almost got me, but then I noticed your picrel
but still, suggesting that there's anything, anywhere, that even remotely resembles "adoption" of fucking D is outrageously silly
>>
>>101426433
Just use glib (or any other general purpose library) and GCC extensions and then C is pretty high level.
You could even use boehm gc, though I would rather use custom made allocator.
>>
C3 is better
>>
>>101426746
>No mandatory header files
dropped
>>
>>101426433
>retard can't write a hashmap
>thinks he's qualified to criticize a GC
what's it like being a cargo cultist?
>>
>>101426878
I'm not criticizing the GC, I'm saying that if I were to use a language with GC, I'd use one that has an infinite amount of money put into improving the GC, like C# and Java.
>>
>>101426904
>if I were to use a language with GC
Then don't use the GC. It's not required. With D you can (quickly and efficiently) write your own non-GC hashmaps that have the exact same syntax as language-level. I practically do it in my sleep at this point. You could base one off std.container.array. Or just get a library off dub, they already exist.

I could write one for you right now in ten minutes if you want and its usage syntax would be exactly the same as native associative arrays except for the initial variable declaration. And the benefit is you don't have to use C# or Java, which are garbage.
>>
golang really became big only after they made a sub 1ms garbage collector. that's how go won.
>>
>>101424345
>What's the problem with this?
nobody uses it
>>
>>101428425
I'm finding it kinda fun finding the libraries that do compile, like exploring a ghost town
>>
>>101424766
>it can't provide a header for other langs (C, C++, LuaJIT) to consume.
it can provide headers for C++ with the -H[xxx] options
shame it can't provide C headers. It refuses even if you use betterC mode. Would be very useful to me, maybe I can try to implement it someday, doesn't just that hard to just omit the C++ specific stuff
>>
>>101426150
https://dlang.org/library/std/concurrency/generator.html
auto r = new Generator!int({
foreach (i; 42 .. 45)
yield(i);
});


It's fairly ergonomic but not having stackless coroutines feels bloated for stuff like this
>>
>>101426433
C++ already exists, alternatively you can embed a lang like Lua in your C program to handle the more fiddly parts, or learn to abuse the bag of fun known as the preprocessor.
Any real competitor to C must be as declaration level compatible as C++ was and prioritize actual problems.
What C needs is not memory safety guard rails but ways to reduce the amount of code needed to implement something, without polluting the user's head with a zoo of autistic features and concepts.

Struct methods and some kind of compile time duck typing that doesn't rely on the preprocessor would make me happy enough. Maybe putting C++ on a diet would be a good starting point. Delete most of the OOP, redo the template system from scratch.
Maybe something with the feature level of LuaJIT but statically compiled is what we need. Maybe the preprocessor needs a buff, make it a Turing complete code generation language. Or allow some forms of compile time execution like D, and allow treating things like functions as first class types in that context - make it conceptually feel like Lua but only in the compile phase. That would be a decent replacement for template hell and the aged preprocessor.

>>101426746
looks like absolute trash
>>
>>101424345
Netflix and Facebook both experimented with it to see if it had what it takes to handle the type of tough engineering challenges that big tech companies like they face, and they decided it had no chops. If it's not good enough for them, it's just a toy and not good enough for anything other than for fun.
>>
>>101424383
>It really is a good language
No it's not. Implementing every posible feature is not a good approach to language design.
>>
>>101425738
calm down, andrei
you have been in the memelang clab forever, no reason to get upset
>>
>>101424345
don't know but something definitely isn't right.
I would point out not having a simple build system.
>>
>>101424345
It doesn't know what it is. Right now it is an amalgamation of 3 different languages, and for each case there exist better languages.
D would be much better if it focused on being either simple C-like syslang, managed GC language or safe Rust-like language. But it tries to do everything and has to suffer from it.
>>
Truth of the matter is, C is all you need.
I know, other languages have cool logos.
But just maybe do some side project in the cool logo languages or build a website.

But C is all you need and when you want to get the most performance outta something, you're going to grab C.
>>
>>101432626
>performance
this is main thing, C is portable assemble, the only language with the same perform acne as assembled, higher level always has a slowdown penalty tax from being abstract
>>
>>101424345
it's not forth
>>
>>101432626
>most performance
Zig produces far faster assembly.
>>
File: dlangcomp.jpg (56 KB, 1006x594)
56 KB
56 KB JPG
>>101429822
Then why don't they remove them from the orgs-using-d website
>>
>>101432626
>But C is all you need and when you want to get the most performance outta something, you're going to grab C.
This isn't even true. For example Rust can use the fact that mutable pointers never alias to perform optimizations that standard C can't. Being simpler doesn't mean more powerful. And hand rolled assembly will be faster than both anyway.
>>
>>101434618
Restrict is part of standard C thoughever
>>
>>101434810
You are right. It isn't present in standard C++, but C99 does have it. I had no idea.
>>
Are you supposed to use a lot of c/c++ code when using this?
>>
>>101429546
int i = 42;
generate!( () => i++).take!3

stackless version is also very readable and works in many cases, though often you have to use a struct with opCall for the state.
>>
>>101437028
No, doing so will add a bit of friction, but interop is much better than any other language (besides maybe zig), which is convenient when you need to use a specific library or already have a big codebase
>>
>>101437656
>generate!
>take!
why this language so excited? why are all these modern excited languages? not professonial
>>
>>101425904
so does this work if you only have a header file and the library? What about auto completion will the lsp be able to find the symbols?
>>
>>101432626
>C is all you need
>performance
C fags and their bullshit memes.
You don't know anything about performance until you profiled the problem. Until then STFU.
>>
>>101440182
I profile the problems wherever I go



[Advertise on 4chan]

Delete Post: [File Only] Style:
[Disable Mobile View / Use Desktop Site]

[Enable Mobile View / Use Mobile Site]

All trademarks and copyrights on this page are owned by their respective parties. Images uploaded are the responsibility of the Poster. Comments are owned by the Poster.