February 18, 2017
On 2/18/2017 1:37 PM, ketmar wrote:
> i think that we should have an article on wiki for client writers. no, really,
> some knowledge is here but never written, so people like me have to figure it
> out each time. not that there are so many client writers, of course, but... oh,
> ok, i guess that i'll write a short summary on this later. ;-)

I'm curious about your client project. Can you post a link?
February 18, 2017
Walter Bright wrote:
> On 2/18/2017 1:37 PM, ketmar wrote:
>> i think that we should have an article on wiki for client writers. no, really,
>> some knowledge is here but never written, so people like me have to figure it
>> out each time. not that there are so many client writers, of course, but... oh,
>> ok, i guess that i'll write a short summary on this later. ;-)
> I'm curious about your client project. Can you post a link?

sure:

http://repo.or.cz/knntp.git
https://files.catbox.moe/wxga1k.png

it is really titled "dingo", not "knntp", but it is not possible to rename repos on repo.or.cz. ;-)

but please note that it is not "pure D", i'm using my slightly modified dmd/druntime/phobos fork. it is completely compatible with "vanilla", but i am usually never "vanilizing" code that i'm not intending to announce/present to other people. so you won't be able to build it out of the box (yet required changes to "vanilize" it are minimal).

i added a screenshot, so you can make your eyes bleed without building my code. ;-)

and i am now writing an email client, with the slightly modified dingo engine as backend (and the same eye-bleeding frontend ;-).

it is also using Adam D. Ruppe's simpledisplay.d module to do all the low-level gfx, and his email.d module to decode mime messages. and alot of my own "iv" modules, of course.
February 18, 2017
On 2/18/2017 2:11 PM, ketmar wrote:
> Walter Bright wrote:
>> On 2/18/2017 1:37 PM, ketmar wrote:
>>> i think that we should have an article on wiki for client writers. no, really,
>>> some knowledge is here but never written, so people like me have to figure it
>>> out each time. not that there are so many client writers, of course, but... oh,
>>> ok, i guess that i'll write a short summary on this later. ;-)
>> I'm curious about your client project. Can you post a link?
>
> sure:
>
> http://repo.or.cz/knntp.git
> https://files.catbox.moe/wxga1k.png
>
> it is really titled "dingo", not "knntp", but it is not possible to rename repos
> on repo.or.cz. ;-)
>
> but please note that it is not "pure D", i'm using my slightly modified
> dmd/druntime/phobos fork. it is completely compatible with "vanilla", but i am
> usually never "vanilizing" code that i'm not intending to announce/present to
> other people. so you won't be able to build it out of the box (yet required
> changes to "vanilize" it are minimal).
>
> i added a screenshot, so you can make your eyes bleed without building my code. ;-)
>
> and i am now writing an email client, with the slightly modified dingo engine as
> backend (and the same eye-bleeding frontend ;-).
>
> it is also using Adam D. Ruppe's simpledisplay.d module to do all the low-level
> gfx, and his email.d module to decode mime messages. and alot of my own "iv"
> modules, of course.

I'm curious what problem this solves that other nntp clients do not. I see that its display is in text mode. One nice thing about text mode is it works well on low-bandwidth connections.

I've been heavily criticized for not using a graphical IDE, but I work a lot through remote connections, and I've never been able to get a remote desktop to work at a reasonable speed, even when it is in my house and the connection is not speed limited.

Text mode tools present no problems there.
February 19, 2017
Walter Bright wrote:
> On 2/18/2017 2:11 PM, ketmar wrote:
>> Walter Bright wrote:
>> I'm curious about your client project. Can you post a link?
> sure:
> http://repo.or.cz/knntp.git


> I'm curious what problem this solves that other nntp clients do not.
it perfectly fits my needs. i usually see little reason to "adapt" myself to something if i can write my own thingy. besides, writing code is fun.

i tried pan, snews, some other readers i forgot, and they aren't fit. i wanted the UI i did, i wanted twitlists i wrote, and so on. and i wanted reader written in D, 'cause i hate to work with a code in another language. ;-)


> I see that its display is in text mode.
no. ;-) it looks like it, but it isn't. just take a closer look on screenshot: the font is proportional. but is was designed to look old-fashioned, yeah.


> One nice thing about text mode is it works well on low-bandwidth connections. I've been heavily criticized for not using a graphical IDE, but I work a lot through remote connections, and I've never been able to get a remote desktop to work at a reasonable speed, even when it is in my house and the connection is not speed limited.
> Text mode tools present no problems there.
tbh, most of my tools are console-based. but this time i wanted to do something with graphics. yet my terminal tastes still manifest 'emselves, i guess.


for writing my code i am using my own terminal-based editor. it has support for simple syntax highlighting, but that's all: no fancy "integration" features, no "project management" (besides multiple edit buffers), no autocompletion. the only "advanced" thing it does is rdmd output parsing, so i can jump to error location with a single keypress. yet it is lightning fast. no, really, no slowdowns even with 25+ megabyte(!) files.

i am also using my own terminal emulator too. this one is in C, 'cause i didn't finished D rewrite yet. ;-)
February 19, 2017
On Tuesday, 20 December 2016 at 02:24:28 UTC, Ali Çehreli wrote:
> On 12/19/2016 06:19 PM, Adam D. Ruppe wrote:
>> On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:
>>> Vim: Lets not go there.
>>
>> Why not? If you already know vim at least, it is very easy to use with D
>> - things just work quite well out of the box.
>>
>>> Try remote editing D and see how much fun it is.
>>
>> works in vim out of the box...
>
> No need to mention Emacs. If vi[m] can do something so can Emacs. :p
>
> Ali

I, for one, concur.
February 19, 2017
On Tuesday, 20 December 2016 at 10:18:12 UTC, Kelly Sommers wrote:
> As an outsider to the D community but someone who has really wanted to love D the last few years I hope to shed some light from "outside the bubble" on why I haven't used D and why I use what I use and what I'm looking for. I hope this can be well received.
>
> I write a lot of C and Go. But they aren't what I truly want in "systems" programming languages. I write high performance infrastructure code like databases or server software that handles millions of requests per second. One of my projects is an OSS HTTP server written in C that can serve 10 million requests/second.
>
> Let's clarify a couple things about C and Go. C's advantages/disadvantages are:
> 1. Manual memory management. This could also be seen as a disadvantage but having the power to tailor memory access is an advantage for memory usage, allocation and access optimizafions. Let's face it, high perfowmcne code is all about memory access.
> 2. No GC pauses impacting request response times. Java, Go, .NET etc all have this problem.
> 3. Harder to write and write well, safely and securely.
> 4. Few concepts to learn.
> 5. Composability of libraries is poor. No package system, often not cross platform.
> 6. A lot of low level fundamental libraries are written in C like async I/O libraries or storage engine libraries.
> 7. Static compilation.
>
> Go's advantages/disadvantages:
> 1. Static compilation.
> 2. No manual memory management.
> 3. Suffers from GC pauses.
> 4. Great composability of libraries. For example, you can easily "go get" a Redis protocol library, an ACID memory mapped persisted b+tree library and build a little database quite quickly.
> 5. Few concepts to learn.
> 6. Performance overhead when calling C libraries like storage engines.
> 7: The statement that Go is mostly used in scripting-like contexts isn't correct. It's very popular in the infrastructure space like databases and distributed systems implementations.
> 8. Lack of generics causes a lot of boilerplate code in comparison to other modern languages.
>
> As an engineer who works on distributed systems in the scale of thousands of nodes I have to point out that GC'd languages need to be thought more as in the same category because of how they operate in production. You have to spend significant effort keeping these processses happy so that the GC's don't pause too much hurting response times. I argue all the time that GC'd languages are not systems languages. There's not enough control and you can't eliminate GC pauses completely and these GC's don't scale to modern physical hardware well.
>
> But Go is popular in this category of space despite the GC/generics because of how composable infrastructure code is in the Go community. "go get" a Raft library, gossip library, storage library and you're off and running much faster than in other languages. However the overhead of calling C libraries and the GC impact performance. Go knows this weakness of the GC and has been working hard to eliminate GC pauses as much as possible. A great effort into sub-millisecond pauses with large heaps was recently achieved: https://github.com/golang/proposal/blob/master/design/17503-eliminate-rescan.md
>
> What I really want is what C++ wanted to deliver but it doesn't. I want something better than writing C but with the same performance as C and the ability to interface with C without the performance loss and with easily composable libraries.
>
> D in my opinion in some ways is close to these goals. It's simpler to understand and write than C++. It has the problem of being a GC'd language however and it's unclear to me if the GC in D is evolving like the Go GC is. I'm not happy about having to use a GC but if I have to I hope to see the one I'm investing on evolve because it most certainly impacts production systems very much.
>
> The things I really want from D to really sway me would be the following (some already exist):
> 1. Evolve the GC like Go has.
> 2. No overhead calling C libraries.
> 3. Easily composable libraries.
> 4. Good IDE support.
>
> #2 is really why Go has gained a lot of popularity but #1 is extremely important on how production systems behave. #2 is likely something Go cannot solve and why there's an opportunity for another language to jump in with better performance.
>
> The programming community hasn't found a good modern systems language yet that aligns with these tradeoffs. I actually think D and Swift (no GC, ARC, no calling C overhead) are closest to having the potential for the correct tradeoffs to be systems languages.
>
> Rust probably is aligned more than anyone with these goals at the moment but every time I try to learn rust my head hurts and it's not enjoyable.
>
> I hope this sheds some light on why I really like D but as an outsider what I'm looking and need in the space I build software and why I think D could fill a gap others aren't yet.
>
> Thank you for reading my thoughts.

As a complete beginner in D, your post makes a lot of sense to me. Also, that bit about Rust is spot on. It's nice for fancy little programs (and I've written quite a few of those), but babysitting the ownership and lifetimes system detracts away from the problem I'm trying to solve itself. That's too bad indeed.

I had given Go a try as well, but it does seem to have a very narrow focus (which Rob Pike has not been shy to claim) plus the lack of generics is very stultifying (at least for me). I do believe that Go did well for a few reasons - Rob Pike's strong hand in carrying out his mandate, a fabulous marketing team, and the simplistic but consistent nature of the language's design. In fact, Rust is also "popular" for very much the same marketing spearheaded by the likes of Steve Klabnik, but the language is way too complex, and the team in Mozilla just does not care about that.

I do love C++11 and newer, but I'd rather not use it for any new projects barring some weekend projects of my own. The type system is horrendously outdated. If they could make a clean break and make C++11 the basis, improve error checking, bounds-checking, and warning messages, and get rid of the C legacy (of course, that's never going to happen), it would make for a fine language.

I've come to D primarily because I want a modern safe(r) systems language with an excellent type system that I can use for my small-to-medium projects without having to spend days figuring out why the damned things is segfaulting all the time. I have been reading the threads on this forum, and not everything is perfect (understandably so), but it's been good going thus far!
February 19, 2017
On Tuesday, 20 December 2016 at 15:42:16 UTC, bachmeier wrote:
> On Tuesday, 20 December 2016 at 15:17:56 UTC, Benjiro wrote:
>> I do not recall seeing on the C++ and other forums this constant attitude from fix it yourselves or put it in the libraries or ... Its mostly on the smaller languages where they lack people. And at the same time, that is a very scary though for companies who want to use a language.
>
> I think it's important to be realistic. One of D's limitations is that it does not have the money of Microsoft or Intel behind it, and it does not have hundreds of billion-dollar corporations depending on it for critical business operations. Volunteer organizations will be run differently from outfits that have large budgets to pay people to do the ugly work. This is not an excuse, it is simply the current state of affairs.

I'm completely new to the D scene, but I do want to make a comment here. One of the reasons why a language like Rust is seeing a surge in popularity is because the core team in Mozilla are evangelising it like you wouldn't believe it. Rust is a fairly old language, and yet the way they present it would fool anybody new to the language. Some things I noticed about their approach (having been part of the community for a little while) -

  1). Have a nifty, minimalistic website (D has a pretty good website as well, but I feel it is a bit overwhelming for newbies).

  2). Present the core strengths of the language on the main page itself in a brief sentence (even though they are more half-truths than anything else).

  3). They hired someone like Steve Klabnik to give talk after talk, and no matter what you may think of him, he is very good at "connecting" with the younger folks, and like it or not, the next generation is the target audience that will decide if a language is succesful or not.
    In my opinion (also based on posts that some D users have made on the Rust user group), D is actually a much more coherent and powerful language than Rust, but most people (including myself) wouldn't have known about it on face value.

Self-promotion is something that needs to be done, and the Rust group is very good at it. Go, on the other hand, benefits from the Google name, of course. I doubt it would have had a quarter of its success just based on Rob Pike's status and the merits of the language itself.

Also, community-building is something that absolutely needs to be done to convince users to join in with fresh minds, and start building things in the language. Only then will a community really flourish, no matter how good or bad the language is.

  4). Spam the tech arena - have tons of blogs floating around talking about the "cool" features of the language while downplaying the complexity hiding around the corner, have a very helpful IRC channel where people answer even the silliest questions with a smile, and have active forums and users on Reddit, HN, and the like.

   5). Have regular online meetups and offline and online conferences as well.


February 20, 2017
On 20/02/2017 1:25 AM, timmyjose wrote:
> On Tuesday, 20 December 2016 at 15:42:16 UTC, bachmeier wrote:
>> On Tuesday, 20 December 2016 at 15:17:56 UTC, Benjiro wrote:
>>> I do not recall seeing on the C++ and other forums this constant
>>> attitude from fix it yourselves or put it in the libraries or ... Its
>>> mostly on the smaller languages where they lack people. And at the
>>> same time, that is a very scary though for companies who want to use
>>> a language.
>>
>> I think it's important to be realistic. One of D's limitations is that
>> it does not have the money of Microsoft or Intel behind it, and it
>> does not have hundreds of billion-dollar corporations depending on it
>> for critical business operations. Volunteer organizations will be run
>> differently from outfits that have large budgets to pay people to do
>> the ugly work. This is not an excuse, it is simply the current state
>> of affairs.
>
> I'm completely new to the D scene, but I do want to make a comment here.
> One of the reasons why a language like Rust is seeing a surge in
> popularity is because the core team in Mozilla are evangelising it like
> you wouldn't believe it. Rust is a fairly old language, and yet the way
> they present it would fool anybody new to the language. Some things I
> noticed about their approach (having been part of the community for a
> little while) -
>
>   1). Have a nifty, minimalistic website (D has a pretty good website as
> well, but I feel it is a bit overwhelming for newbies).
>
>   2). Present the core strengths of the language on the main page itself
> in a brief sentence (even though they are more half-truths than anything
> else).
>
>   3). They hired someone like Steve Klabnik to give talk after talk, and
> no matter what you may think of him, he is very good at "connecting"
> with the younger folks, and like it or not, the next generation is the
> target audience that will decide if a language is succesful or not.
>     In my opinion (also based on posts that some D users have made on
> the Rust user group), D is actually a much more coherent and powerful
> language than Rust, but most people (including myself) wouldn't have
> known about it on face value.
>
> Self-promotion is something that needs to be done, and the Rust group is
> very good at it. Go, on the other hand, benefits from the Google name,
> of course. I doubt it would have had a quarter of its success just based
> on Rob Pike's status and the merits of the language itself.
>
> Also, community-building is something that absolutely needs to be done
> to convince users to join in with fresh minds, and start building things
> in the language. Only then will a community really flourish, no matter
> how good or bad the language is.
>
>   4). Spam the tech arena - have tons of blogs floating around talking
> about the "cool" features of the language while downplaying the
> complexity hiding around the corner, have a very helpful IRC channel
> where people answer even the silliest questions with a smile, and have
> active forums and users on Reddit, HN, and the like.

We do try on our Freenode channel, but answering with a smile can be quite hard. Especially when simple answers are ignored (I am definitely guilty of this).

It really doesn't help that we only have one person with OP rights who acts upon them. Its annoying since we get spammed every 6-8 months with nothing we can do assuming no Freenode admins are on (this is very common!).

February 19, 2017
On 02/19/2017 02:50 AM, ketmar wrote:
> i usually see little reason to "adapt"
> myself to something if i can write my own thingy.
>

Ditto to that. Thunderbird (or rather whatever version I've frozen it at) is the closest match to my needs I've seen so far, but it still irks the heck out on me on various things. And as for modifying it, meh, well Mozilla's earned a reputation for being difficult to talk any user-oriented sense into, and life's too short for a big C++ codebase (I dunno, maybe they've started switching to Rust? In any case, rather just use D.) There's a ton of other things I'd like to do my own version of for similar reasons: Editor, browser, music/media manager, etc. Too much to do, not enough motivation ;)

February 19, 2017
"Nick Sabalausky (Abscissa)" wrote:
> On 02/19/2017 02:50 AM, ketmar wrote:
>> i usually see little reason to "adapt"
>> myself to something if i can write my own thingy.
>> 
> Ditto to that. Thunderbird (or rather whatever version I've frozen it at) is the closest match to my needs I've seen so far, but it still irks the heck out on me on various things. And as for modifying it, meh, well Mozilla's earned a reputation for being difficult to talk any user-oriented sense into, and life's too short for a big C++ codebase (I dunno, maybe they've started switching to Rust? In any case, rather just use D.) There's a ton of other things I'd like to do my own version of for similar reasons: Editor, browser, music/media manager, etc. Too much to do, not enough motivation ;)

btw, i almost finished my own little email client. i was using Claws Mail, but finally got tired of it's awful speed, strange filtering and so on. so i took the backend engine from my NNTP reader, improved it a little, and created Chiroptera. wrote support for subset of Claws Mail filters, converted mail archives (~1GB of data, wow!), and now i can retrieve and read mail from all my accounts. sending UI is almost done too (but hey, who needs that anyway?!).

as Chi is based on the same code as NNTP reader, i think that i'll eventually merge NNTP parts into it -- 'cause i already tired of backporting enhancements and bugfixes. ;-)

lucky me: as i don't have to support all possible servers and use cases, i can keep Chi small and fast: it is at least a magnitude faster than Claws Mail on my mail db.

after working with some C++ codebase it is a joy to write in D again. that's prolly why i finally found enough motivation and willpower to do Dingo and Chiroptera.