D is our last hope

[H. S. Teoh]

On Tue, Dec 19, 2023 at 05:36:51PM +0000, Steven Schveighoffer via Digitalmars-d wrote:
> On Tuesday, 19 December 2023 at 14:17:41 UTC, Luna wrote:
> > 
> > All the software my company (Kitsunebi Games) and my main project,
> > Inochi2D, is written in D.

Awesome!


> > I am currently also speccing out a new UI toolkit for use in the
> > Inochi2D project with a more modern look, working on a
> > [library](https://github.com/Inochi2D/numem) to make DLang usable
> > without a GC while still maintaining support for classes and such to
> > make D libraries more usable outside of D, and such.
> > 
> > Inochi2D is also by extension bringing new blood in to the D
> > community through people interested in contributing to the project,
> > as well as people getting interested in D by extension of Inochi2D
> > being written in D. And as it stands unless Walter does something
> > really stupid with the language I do not intend switching away from
> > D.
> 
> This is the way. When you write useful stuff for yourself, other
> people find it useful. D is probably one of the only languages where a
> small team (even a team of 1) can produce insanely good and useful
> libraries.

I heard Lisp can do that too. Whether that's a good thing or not, is up
for debate. :-D


> I personally wish I could do more, but have not too much time to spend
> on my open-source projects. I'm sure they seem dead, but I'm always
> thinking about them...

I'm also still using D, and don't plan to switch away in the foreseeable
future.  In spite of its flaws, it's still the least painful language
for me to use right now.


> > That being said I do sometimes feel like I need to maintain my own
> > corner of the D ecosystem due to the lack of well maintained
> > libraries, but hopefully the new blood joining through the Inochi2D
> > community will help maintain all the libraries and apps I'm
> > creating, heh.
> 
> I hope so. I think what might happen at some point is we get a set of
> "blessed" libraries that everyone uses, such that we have a robust
> ecosystem. I'd rather have this grow organically than be anointed by
> some important people.

Yeah that's what we need.


> One interesting study would be to look at the various libraries out
> there, and see which replace or supersede phobos. For example, you
> don't see a lot of std.algorithm replacements. This is probably a good
> indication that it's a solid piece. But we have like 15 json
> libraries...

I'm a heavy Phobos user, and std.algorithm / std.range are among the
best parts of Phobos.  Among the better modules are std.datetime,
std.path, std.bigint, std.regex (I'm a regex addict). std.process is
awesomely convenient for dealing with processes; one of the
better-designed APIs in Phobos IMO.  std.math / std.numeric are pretty
standard, with a few nice things in there, though there's that
strangeness with real vs. double. std.stdio is also pretty standard, but
could be improved (replace with I/O pipes?). I'm addicted to std.format
for its convenience but the implementation really could use some
improvement, same goes for std.conv. std.uni's implementation could also
use some improvement, but what's there is pretty serviceable for dealing
with Unicode (main missing features: Unicode line-breaking algorithm and
grapheme width -- I have an incomplete implementation of the latter but
never got around to finishing it).

std.meta / std.traits / std.typecons are good for metaprogramming,
though there are some weird bits.

Other parts of Phobos are meh, like std.container (I use it from time to
time but the API is klunky and rough around the edges), std.digest
(never used it, kinda random why it's in Phobos), std.encoding (hardly
ever use it), std.experimental (when it is coming out of deep freeze?),
std.json (meh), std.xml (bleh).  std.getopt gets the job done, but has
weird differences with standard Posix getopt() for no good reason, which
made me write my own getopt on at least 3 separate occasions.
std.signals - never used it, std.socket (meh), std.bitmanip (sometimes
useful), std.base64 (kinda random, used it once or twice but that's
about it -- honestly could just go in a dub library), std.csv (meh - my
fastcsv alternative runs way faster, though with no validation).
std.net.curl - weird API, std.net.isemail - seems like a totally random
thing to put in Phobos.  A lot of this stuff honestly could do better as
dub packages / external repos.


> I don't think I'll ever give up on D either. Just the power you can
> wield with so little effort is going to keep me here.
[...]

D has completely ruined me. After tasting its metaprogramming power (I
wrote my own boilerplate-less serialization in a couple o' weeks, where
in C++ I would've taken months with LOTS of nasty boilerplate), I just
can't go back to any other language anymore.  Every time I'm forced to
code in another language I find myself wishing for this or that D
feature that isn't in that language. And the more I have to write non-D
code the more I chafe inside and feel like I wanna just throw out what I
wrote and rewrite it better in D.  I've been wrecked. (And I love it!
:-D)


T

-- 
Turning your clock 15 minutes ahead won't cure lateness---you're just making time go faster!