On Tuesday, 20 December 2016 at 06:42:10 UTC, lobo wrote:
> On Tuesday, 20 December 2016 at 04:38:03 UTC, Jerry wrote:
>> On Tuesday, 20 December 2016 at 04:14:33 UTC, Andrei Alexandrescu wrote:
>>> On 12/19/2016 11:12 PM, Andrei Alexandrescu wrote:
>>>> [...]
>>>
>>> https://issues.dlang.org/show_bug.cgi?id=16991
>>
>> Another issue onto the list of thousands, to collect dust for the next few years til someone decides they want to use their personal time to fix it. Just to highlight another problem, there's a lot of trivial to fix issues. Just maintenance really, like that one you posted. But there is no one going through fixing them. Well that one might end up getting fixed cause of the extra exposure.
>
> Maybe you could fix one or two? As you say they're trivial and apparently no one else is doing it.
>
> bye,
> lobo

I have, sadly I have better things to do like the project I'm working on that's using D. I'd rather not soak up all my time fixing the tool and focus on what matters.

On Tuesday, 20 December 2016 at 06:42:10 UTC, lobo wrote:
> On Tuesday, 20 December 2016 at 04:38:03 UTC, Jerry wrote:
>> On Tuesday, 20 December 2016 at 04:14:33 UTC, Andrei Alexandrescu wrote:
>>> On 12/19/2016 11:12 PM, Andrei Alexandrescu wrote:
>>>> [...]
>>>
>>> https://issues.dlang.org/show_bug.cgi?id=16991
>>
>> Another issue onto the list of thousands, to collect dust for the next few years til someone decides they want to use their personal time to fix it. Just to highlight another problem, there's a lot of trivial to fix issues. Just maintenance really, like that one you posted. But there is no one going through fixing them. Well that one might end up getting fixed cause of the extra exposure.
>
> Maybe you could fix one or two? As you say they're trivial and apparently no one else is doing it.
>
> bye,
> lobo

And have the patch wait in the PR queue until the end of time, not even acknowledged at all ?
The lack of focus goes hand in hand with the lack of manpower with some not-so-great results like we're seeing right now, at least IMO.

On Tuesday, 20 December 2016 at 01:45:27 UTC, Tommi wrote:
>
> Improve the standard library!
>
> Split the standard library! Forget that no other language does it!
>
> Add to the standard library!
> Add to the standard library!
> Add to the standard library!
>
> Improve documentation!
>
> Add to the standard distribution!
>
> Don't add to the standard library!
>
> Don't add to the standard library!
>
> Don't use std.experimental! It's bad!

Yea, great idea... O wait... where are people going to add things again? O right ... Simply keep yelling add to std when NOBODY WANTS TO DO THAT. Just dump everything into the one git massive library with no more control of the author!!!

Did you not read that D has a different crowd. That a lot of people using D seem to be more into propitiatory code.

No, it does not work like that. You create separate gits that are part of a D library where the authors can write / maintain the code. Its easier on them, more easy to maintain because of separate bug trackers and it fits in with the whole forum std splits / dedicated forums.

> Don't add anything anywhere!
>
> Don't add features!
>
> Don't work on the compiler or standard library! Don't use your skills! Write documentation and learn how to do editor integration!
>
> Work on the speed bloat! Wait, what?
>
> Tell people what do do!
>
> Do marketing!
>
> Respond to people on the forums!
>
>
> Don't add to the standard library!
>
> Work on the standard library! But discuss in a different forum!
>
>
> Add more forums!
>
> Stop replaying on the forums!
>
> Add more focus!
>
>
> More management!
>
> Stop replaying on the forums!
>
> Don't tell people what to do!
>
> Do use std.experimental! It's good!
>
> More forums!
>
> Add to the standard library!
>
> Let everyone add to the standard library!
>
> Half of the paragraphs contradict the other half. Walter must headbutt himself in the face reading this.

Read everything....

If you bothered reading what i write as a whole, you can clearly see where the focus points need to be and what is clearly lacking. They do not contradict each other. Only if you decide to strip them in each part and then comment like a wiseass.

Do what you want with your idiotic replies. Its this attitude that drives people away. You want people to help, well this is NOT the way to motivate people.

Simply keep yelling add to standard library when people do NOT want that. And no offense but D there standard library is one of the weakest among the new languages. Yet, there is code out there where people WANTED to add to the library that is rotting away simply because nobody here does anything beyond yelling:

> Add to the standard library!
> Add to the standard library!
> Add to the standard library!
> Add to the standard library!
> Add to the standard library!

Maybe you want to freaking ask the authors of for instants std.database etc why they feel unwilling to add it to the standard library git. And if you ever did project management, you know exactly where. People do not like to lose control over there projects. That is AGAIN why you need separate gits, under the D lang branch, but where the authors still have control over there code.

F*ck this. Its like talking to walls. Anyway, do what you want. I have my own projects to deal with and i can write around the lacking libraries, documentation etc. Unfortunately, not everybody can and its those people you are hurting with that wiseass attitude. Good luck getting new people motivated in D like that.

On Tuesday, 20 December 2016 at 08:41:21 UTC, Benjiro wrote:
> F*ck this. Its like talking to walls. Anyway, do what you want. I have my own projects to deal with and i can write around the lacking libraries, documentation etc. Unfortunately, not everybody can and its those people you are hurting with that wiseass attitude. Good luck getting new people motivated in D like that.

What did you expect with a rant like that?

You vented your anger. This is fine. Some concrete actions were already taken (e.g. Andrei filed an issue about writeln). People should do this more often, because core-devs are blind to issues such as writeln documentation. They never look that up. Thanks for that!

However, into your rant mixed proposals in a "wiseass attitude" with lots of bikeshedding potential. Naturally, people react to that and shoot it down. If you want to do something like that again, my advice would be: Delay the proposals until the very end and write in a very humble way. Describing the problems precisely is worth more than coming up with ideas for a solution anyways.

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.

On Tuesday, 20 December 2016 at 08:41:21 UTC, Benjiro wrote:
> On Tuesday, 20 December 2016 at 01:45:27 UTC, Tommi wrote:

> F*ck this. Its like talking to walls. Anyway, do what you want. I have my own projects to deal with and i can write around the lacking libraries, documentation etc. Unfortunately, not everybody can and its those people you are hurting with that wiseass attitude. Good luck getting new people motivated in D like that.

+100

On Tuesday, 20 December 2016 at 10:18:12 UTC, Kelly Sommers wrote:
> 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.

I agree.

1. takes surprisingly long. There is still no precise GC.

2. and 3. are already there. Well, libraries are never perfect, of course.

4. is proceeding, but slowly. Afaik no core dev uses an IDE.

On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:
> Documentation:
> --------------

You forgot one here. Dub's documentation is simply atrocious *and it's the official package manager*. Throw around things terms like "you can use Git submodules for that" as if it's a trivial thing. But I'm not going to say more. I realized a while back that this community is incapable of understanding what is wrong with Dub's documentation.

On Tuesday, 20 December 2016 at 09:33:22 UTC, qznc wrote:
> What did you expect with a rant like that?

A rant... Well. Rants have a background.

> You vented your anger.

Actually, i did not vent any anger until this morning when i noticed the wiseass response. All the points i wrote yesterday are items that actually bother a lot more people. But those same people who complain about it, always get shutdown with that typical: Do it yourself response / Improve the standard library / ...

Documentation:
--------------

If they want some concrete examples, here are few:

https://dlang.org/library/std/socket/tcp_socket.html

https://doc.rust-lang.org/std/net/struct.TcpListener.html

Notice how much more clean the Rust documentation is. I am only pulling that example because its something i looked up right now.

Rust:

* Example ready on the page.
* Linked to a run environment.
* New function listed below, with versioning! So you know exactly what function will work with what version your running.
* Most function or variables link to pages that again have examples on usage.
* Cleaner / Easier to read.

Dlang:

* A long list of functions/classes/...
* Most function or variables link to pages that for 80% simply state the same information. 20% has expanded information or examples.

More:

https://doc.rust-lang.org/std/net/struct.UdpSocket.html
https://dlang.org/library/std/socket/udp_socket.html

...

And stated said, i have zero experience with Rust. Never ran it, just looked at a few over complicated examples in the past ( it actually easier then expected with proper example ).

So it took me about 30 minutes to install, figure out why the example did not work (  return value ) and got it running.

How long will it take anybody to create a tcp socket in D, without resorting to google search and looking into a lot of forum posts.

Answer: A few hours because i did the same work a few days ago. Some of the forum examples are people asking for help with mixed results. From there you need to figure things out. Not everything works because some posts are so old, that the information is outdated.

> 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.

Actually, just playing around with it and you can configure more then you think. I got very fast annoyed with the enforcement of no parens on if statements ( it looks cleaner / easier to read with parens. My opinion of course ). Thinking by myself: Hello Go again!

But it only took a few minutes to figure out that you can control the warnings with #[warn(unused_parens)] > [allow(unused_parens)]


> 1. Evolve the GC like Go has.

I fear that will require a massive rewrite / totally new GC. The change that will happen is very low.

> 2. No overhead calling C libraries.

There will always be some overhead calling C libraries. There is the whole conversion of types etc.

> 3. Easily composable libraries.

... Did not see a big issue with creating your own libraries in D. Or do you mean shared libraries. Yea, that is a massive difference. Go is massive more easy ( especially the 1.8 beta ).

> 4. Good IDE support.

I know the feeling. How many hours struggling to try and get my favorite IDE's to cooperate with Dlang support. Too many are simply out of date / unsupported. Or at best have basic syntax support and that is it.

The best option right now is simply Visual Studio Code. Where WebFreak001 did a lot of great work on making it more easy ( plenty of issue at times but relative more easy ). The problem being that VSC is a more pure local editor and missing a lot of features ( SFTP comes to mind ... the 3th party plugin solution have issues ).

I have gone down the list of editors and its a mess of unsupported, incomplete or outdated plugins. Or editors with lacking features. Probably put in a dozen hours or more testing them all out. And VSC is really the only properly supported one with the full feature set.

On Monday, 19 December 2016 at 23:02:59 UTC, Benjiro wrote:
> 

Also on YN: https://news.ycombinator.com/item?id=13217529