Hacker News Reader

Well you would say that, would you ;-) I will agree with you that it is a very good language from my explorations, which is why I recommended it. It's one of the most mature languages that I've listed and has three excellent compilers. Some might say that its relatively slow GC is it's main disadvantage but that is obviously only going to affect certain classes of applications and the parent already stated that GC is not an issue for their work. The programs that I wrote in D were all highly performant compared with other languages. I also didn't find the language level support for concurrency to be as easy to use as either Go's or Rusts, but again, that's probably just me. Anyhow, I wanted to thank you for all of your efforts with D.

You're welcome!

Alright, I'm going to check out D then. :)

This is just more propaganda from Mr so called 'Bright'.

Sure some things in D are 'interesting', but it's also a very, very complex beast, full of bugs (some known, and heaps more not-known).

btw. Do not participate on the D forums either, it's just a propoganda tool for the D Foundation (i.e. they filter (or moderate as they like to call it), anything that says anything negative about d.

In the end, if D has anything interesting, that we can't live without, we can just take it and integrate it one or the many 'proper' programming languages.

Don't waste your time with d. You'll only ever end up wishing you had spent that time on a proper language, that has a well supported ecosphere.

> anything that says anything negative about d.

Hardly, or half the posts would be gone :-)

What we do moderate is posts where one person harasses another. This happens only rarely, except we had a recent large volume of such coming from a Tor node. So posts coming from the Tor node need approval from one of the moderators for the time being (until that person goes away).

You can also use the NNTP interface to access the forums, which doesn't moderate in advance (that only happens if you use the web interface to post).

The web forum software is a shell around the NNTP interface. It's a bit difficult to make a HackerNews/Reddit style moderation system work on it because of the way NNTP works.

sorry, but there are countless examples, where well known members of the community harassed non-members, because they said something negative about d.

but the only ones that are considered to be harassers, or subject to moderation, are the non-members.

In addition, there is no visibility into does the moderation, how long it might take, what would be filtered, and for what reason.

Therefore the forum's use of moderation is at best, suspicious, and can easily become a tool for abuse.

There should be a record of who filters what, when, and why.

And this should be made public also (although people should not be forced to subscribe to them).

In any case, people are better of spending their time on stuff that is actually supported, and can get them employment.

> sorry, but there are countless examples, where well known members of the community harassed non-members, because they said something negative about d.

If you've got specific messages in mind, email me the message numbers. Ex-post-facto moderation relies on someone letting us know of a problem message. The alternative is pre-moderation, which you've said you don't like.

> well known members of the community

Note that the troll I referred to would sock-puppet well known members, including myself.

How would you suggest dealing with such a disruptive person? (The volume of his postings, all with different pseudo-accounts, was pretty large for a while.)

> for no reason

We've posted several times that professional demeanor is expected.

I doubt other HN'ers are interested in this exchange, so I'd prefer taking it offline and you can email me. See walterbright.com for the address.

Don't bother, it's the narcissist KingJoffrey who got no traction in the forum with his complaint of private access at module level. He shows all the symptoms of narcissism like "exaggerated feelings of self-importance, excessive need for admiration, and lack of empathy". They also are feel entitled and vindictive so they don't hesitate to use unethical behavior for vengeance, like using fake accounts to post garbage (he had even posted under your name). So be careful, I don't know what we can do against that but awareness is imho at least a start.

Here the list of traits that could be observed in the private complain thread:

- Grandiosity with expectations of superior treatment from other people - Fixated on fantasies of power, success, intelligence, attractiveness, etc. - Self-perception of being unique, superior, and associated with high-status people and institutions - Needing continual admiration from others - Sense of entitlement to special treatment and to obedience from others - Exploitative of others to achieve personal gain - Unwilling to empathize with the feelings, wishes, and needs of other people - Intensely envious of others, and the belief that others are equally envious of them - Pompous and arrogant demeanor

See. This is what will happen to you on the D forums too, when you say anything negative about D (that the D community disagree with).

A comment like this would not raise the attention of D moderators though.

So who's the real sockpuppter, troll, narcisist, that makes all the post like these (that you'll see all over the D forums, in response to anyone that says negative things about D).

Well the HN account 'schlupa' sure suggest it is 'Patrick Schluter'. Well known on the D forums.

(aka.. dave?.. aka many other aliases too??)

I don't know about the moderation stuff, but yes, from what I have read, D is very very complex.

Also it seems to have a multiple personality disorder.

Mr Bright seemingly wants it to be the next C.

Mr Andrescu seemingly wants it to be the worlds best meta template programming language.

D users are equally split (is it a better C#, a better Python, a better this, a better that??).

It does seem to be very complex, undisciplined vision for a language that aims for mainstream use.

Then you have all the problems with the lack of library support for this or that, lack of support tools for this or that ...etc etc.

If you read the forums, people spend far too much time debugging their code, due to a variety of strange things that occur in the language due to all its different personalities trying to live in the same place.

So don't be decieved - there really are plenty of disadvantages in using D (and perhaps they outweigh the advantages).

> karma: 2

You are astroturfing HN like you were impersonating people on the D forums. Please stop.

What? I just expressed an opinion about a programming language. I didn't realised that was a crime on HN.

You must be one of those D forum members that don't like other expressing opinions about D, (i.e. ones like TorUser warns us of.)

Did you try to use it?

I did, not very intensively for now, but the general feeling has been good:

- I can use it from day one if I know C++, something to consider if you want to get things done

- it interoperates better than other languages with my C++ stuff

- the metaprogramming capabilities are nice and familiar to someone coming from C++

- the standard library is well prepared and the ranges, algorithms, named tuples and others are well-thought designs that have zero overhead (they use compile-time mechanisms for algorithm selection or tuple code generation)

- std.experimental.allocator: you can control memory management, though I did not use this myself and I do not know how mature it is

- there are efforts to make the language more gc-free friendly if that is what you need

- there is a switch for betterC that allows you to use a subset that is powerful yet still very light

- compile times are good

Is it complex? Well, it can get as complex as you want, but using it without being too fancy is joyful and easier than C++, definitely. I have been investigating several of these languages for a while, concretely, a bit closer Nim, Go and D.

Go is very nice at what it does, but that's it. It can be written and used in teams easily, but it is too specialized: by specialized I mean you have the GC with the channels and goroutines systems but you do not have control on memory layout or indirection or allocation AFAIK. Interoperability is also more difficult than with D.

Nim looks promising. The problem is that it looks promising, but the reality is that it is not ready for production use yet. Also, something that should look like an advantage looks like a disadvantage to me: it looks clean because it follows a Python syntax. D chose to follow C and C++. That is an advantage, no matter how clean Nim looks, because at the end, most people know C. The library ecosystem is far better in D also. Interoperability: I think Nim is easy to mix with C, but not with C++ and Objective-C. Do you really know of anyone that would adopt a language without a realistic migration path of their code bases? Maybe for hobby projects yes, but for enterprise? Because these things can get painful easily and they make for a lot of time wasted.

D: powerful and understandable metaprogramming if you come from C++ (I saw Nim's metaprogramming and I must say it also impressed me, that is true). Good migration path. More mature than Nim. General purpose, can control memory allocation. Trying to solve real world problems. The most pragmatic tool for general purpose programming if you want good performance and getting things done, something I care a lot, because at the end the language is just a tool. I do not need a perfect tool, I need something convenient that lets me finish things.

From this pack, for me, D is the only one that is a positioned candidate to be both general purpose and mature enough at this moment. Nim is not there yet, unfortunately, and interoperability and lack of maturity play against it strongly. If you add that almost anyone knows C and many people know C++, but many people will just not know Python, that is something else to consider. As for Go, it is too specialized in one area, which does very well. But it is what it is.

> Interoperability: I think Nim is easy to mix with C, but not with C++ and Objective-C.

What gave you that idea? Nim is easier to interoperate with C++ and Objective-C than any language that I know of (including D!).

In addition I personally also consider Nim to be production ready (and know many others who do too). But I can appreciate that the pre-1.0 state makes people nervous.

Yes, I spent 6mths with it.

As with any programming langauge, if you do simple things, and do them often, then you'll probably have little to worry about. D certainly makes many things simple for you.

On the otherhand, the language has no personality that you get your head around. It tries to be everything to everyone.

If you are presented with some code for D app, it's not possible to understand what 'style' programming you'll see, until you see it - because the language supports so many paradigms.

Although, not all paradigms are faithfully represented.

For example, class-oriented programmers will get at least an intial shock, when they realise that private class members are public witin a module. Any code in a module can change any part of your encapsulated classes.

Then, you have the issue of public being the default.

Then, you have the issue of class instances being able to share mutable data.

And the list goes on..and on... and on..

If you've never programmed before, these might not be such a big deal, but if you're an experience programmers from a mainstream langauges, you'll spend a large amount of your time working out all these things for yourself, most of the time.

I personally do not see the benefit for experienced programmers to switch from a well supported, well maintained, mainstream langauges, to D. It just does not make sense to me.

Sure D does some interesting things. Other languages can learn and take from D, just as D has taken so much from other langauges.

In the end, there is nothing in D that really changes the nature of programming. It's all the stuff we already know, all wound up into one big monstrosity, that lacks any real supporting ecosphere.

> On the otherhand, the language has no personality that you get your head around

I do not get this point. I use D as a C++ improvement (which is what it was since the beginning) and I can do from functional, to OOP to structured or generic programming. No personality? You mean it does not favor any paradigm? That is another of the reasons why I chose it. By this measure, Nim is another non-personality language: the package offers the same things -> soft real-time gc, generic, structured and OOP (with Nim Style programming), metaprogramming. Should I say that Nim has no personality and conclude it is not useful? Nim is not useful due to "metaproblems" -> tools, maturity, worse interoperability than D. I do not say the language is not nice, I just say that it is more complicated to get things done with it from a perspective of someone looking for something that can work. Also, following Python makes it for very nice-looking code, but I am not sure it was the right decision from a social point of view (more people know C/C++ than know Python).

> For example, class-oriented programmers will get at least an intial shock, when they realise that private class members are public witin a module

I consider that a design mistake, but that does not preclude powerful metaprogramming or superior interoperability, which are far more important to my use case.

> Then, you have the issue of class instances being able to share mutable data.

I make primarily use of structs and all gc stuff and mutability problems disappear.

> I personally do not see the benefit for experienced programmers to switch from a well supported, well maintained, mainstream langauges, to D

The case for C++ is still very strong for me. But try to get good compile times and do something along the lines of static if (I do not mean only if constexpr in C++ with templates, try to avoid macros for config if you want and you will see, or add a conditional member to a class, or simulate something like version, or generate code without messing with macros)

> In the end, there is nothing in D that really changes the nature of programming.

That is a fair opinion, but I can say that in D there are these small nice things that I value in day-to-day programming like static if (a powerful one, not one that is in the middle between useful and full-featured), overloading opDispatch for forwarding, fast compile times and a module system. The faster compile-times are really, really something that makes more of an impact, maybe, than everything else.

I understand your point, D has nothing "revolutionary". D is not revolution, it is evolution. But D is targeted at doing and using techniques that have been useful for years (and not experimental) easier and convenient: from memory allocation control to gc-free programming, immutability or better interoperability (something that should not be underestimated when using older code bases). I really think that people that see nothing "new" in D should try and see how the full package works together. They will be surprised. And they will also be surprised at how much of the older techniques, in improved versions, they can use. Techniques that have been useful for decades, not experiments of the last FP trends or experiments for which drawbacks are not well known.

I used to think things along the lines you say. I still use C++ mainly, but, when I have another chance, I will insist on D a bit more. I think it is worth the time.

> It's all the stuff we already know, all wound up into one big monstrosity, that lacks any real supporting ecosphere.

That is precisely the strong point of it. It is evolution, not revolution. Did anyone discover lately a better general programming paradigm suddenly that makes all the other obsolete? Not AFAIK. Packaging things in familiar ways has real advantages of lowering the learning curve or figuring out more easily how to interoperate with older code bases. As I said before, that should not be underestimated if you really want to get things done and deliver stuff. If you are just toying around maybe you enjoy more something more revolutionary. But if I have to get things finished, I would bet on D rather than Nim or Go for most use cases.

You keep repeating the line that D is far more interoperable than Nim. Did you miss my reply below? Or did you simply not believe me and downvote it?

Once again. Nim is superior to D in terms of interoperability with C, C++, and Objective C because Nim can compile to either of those languages. For C++ interoperability this is a huge benefit.

I'd love to hear why you disagree if you do disagree. Otherwise please give Nim a try and stop spreading this as a disadvantage of Nim.

> You keep repeating the line that D is far more interoperable than Nim. Did you miss my reply below? Or did you simply not believe me and downvote it?

I did not downvote anyone unless it was an accident :)

> Nim is superior to D in terms of interoperability with C, C++, and Objective C because Nim can compile to either of those languages.

I did not try myself. Well, I did not try Nim to the level I tried D, starting bc I know C++ better than D, though I also know quite a bit of Python (my "second" language).

I have a question, though, about interoperability: you can output Nim code to C++, and mix it. Fair point. But that would be useful to integrate my Nim code into C++ (C++ being the "driver" app). What about the other direction where I can consume C++ from Nim? I have no idea and I ask this question with the best of the intentions :) You thought very bad about me and the downvotes before.

> I have a question, though, about interoperability: you can output Nim code to C++, and mix it. Fair point. But that would be useful to integrate my Nim code into C++ (C++ being the "driver" app). What about the other direction where I can consume C++ from Nim? I have no idea and I ask this question with the best of the intentions :)

I was actually talking about it from that direction, i.e. using C++ libraries in Nim. You can wrap pretty much any C++ feature in Nim: destructors, namespaces, you name it. Because Nim compiles to C++ it can interface with it incredibly well.

Happy to answer any more questions in case I'm not clear.

> You thought very bad about me and the downvotes before.

Apologies. I just saw you reiterating the line I challenged without replying to me and was wondering what happened. Was just asking, not blaming :)

Yes, I am genuinely interested. So I am going to ask a bit more. I am open to new and better tools :)

> I was actually talking about it from that direction, i.e. using C++ libraries in Nim. You can wrap pretty much any C++ feature in Nim: destructors, namespaces, you name it.

Is there any documentation about how to wrap my C++ code into Nim? I do get I can generate C++ from Nim, but I am not sure how it would look to use C++ from Nim. In D for me it is quite clear (with extern (C++) and there is a clear mapping for interfaces and other things. I do not need anything spectacularly fancy, just smooth. Y' know, I am a person who likes to finish things without getting too lost on the details.

You also mentioned many people consider Nim "production-ready". My question here is, if I start to try it, how many breakages can I expect? 4-5, in the tens? Until version 1.0 I mean.

And my last question: how does it compare to D if I have to:

- use a well-mantained GUI library in at least one system (multiplatform would be a big plus)

- how mature is the standard (and other libraries also if that is easy to add) library for: json handling, binary serialization, algorithmic code (a la range-v3 or ranges in D. Something along the lines of python iterators, functools, comprehensions and itertools also ok).

- would I be able to use Nim in embedded if I do a port of some software? Namely, would I be able to remove the GC?

One thing that worries me is that I am much more familiar with metaprogramming in C++ and D's metaprogramming is much closer than Nim's I guess. If you could refer me to good (as in up-to-date) Nim style I would highly appreciate it, specially in the areas of how to manage runtime polymorphism and metaprogramming with an eye on generative programming (basically I want to generate a bunch of things from 3 or 4 basic building blocks in arbitrary combinations).

Thanks for your time!

> Apologies. I just saw you reiterating the line I challenged without replying to me and was wondering what happened. Was just asking, not blaming :)

No problem, I just did not mean to make anyone offended :)

> Is there any documentation about how to wrap my C++ code into Nim?

Here is some docs: https://nim-lang.org/docs/manual.html#implementation-specifi...

> My question here is, if I start to try it, how many breakages can I expect? 4-5, in the tens? Until version 1.0 I mean.

Depends which features you are using. The newer features (concepts for example) will likely have more breakages than the rest of the language. We already have a lot of code written in Nim and a book published (which we are committed to keep compatible with 1.0) so breakages should be minimal (unforeseen circumstances of course may happen).

> how does it compare to D if I have to: > > - use a well-mantained GUI library in at least one system (multiplatform would be a big plus)

I'm not sure about the status of GUI support for D. Nim has bindings to GTK/QML/libui and some other more experimental GUIs rendered using pure OpenGL (nimx). They are all cross-platform (although GTK on macOS is a PITA).

> - how mature is the standard (and other libraries also if that is easy to add) library for: json handling, binary serialization, algorithmic code (a la range-v3 or ranges in D. Something along the lines of python iterators, functools, comprehensions and itertools also ok).

JSON handling is very mature.

I don't think we have binary serialisation in the stdlib.

Algorithmic code - sequtils is what you're after I guess: http://nim-lang.org/docs/sequtils.html

> - would I be able to use Nim in embedded if I do a port of some software? Namely, would I be able to remove the GC?

Sure, but you won't be able to use a lot of the stdlib.

> One thing that worries me is that I am much more familiar with metaprogramming in C++ and D's metaprogramming

I suppose Nim by Example is a good place to look, it has some good metaprogramming examples: https://nim-by-example.github.io/

Also my book has a chapter on metaprogramming :) https://book.picheta.me/

Hope that answers your questions!

Thanks for all the info! Really grateful :)

I must say that, even if unfamiliar to me, I am quite impressed about the C++ interoperability :)

D has _split_ or _multiple_ personalities which makes it very flexible.

Oh, look the annoying D forum troll KingJoffrey / DigitalDesigns / many other sock puppets.

Have you had a chance to try out Nim?

If so I would like to hear your perspective on it. What would you say to convince a Nim core dev to switch to D? :)