this post was submitted on 06 Jan 2024
42 points (95.7% liked)

Programming

17362 readers
158 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 1 year ago
MODERATORS
 

forum post

happened a few days ago

top 15 comments
sorted by: hot top controversial new old
[–] taaz@biglemmowski.win 12 points 10 months ago (2 children)

As a primarily python programmer with some embedded C experience, I really liked the promise of Dlang when I first saw it, though somewhat it felt as dead language, especially compared to Rust, Zig or Nim - I would rarely hear about Dlang in my circles and bubbles.

Let's hope OpenD takes off, wouldn't mind tipping my toes in it once again.

[–] namingthingsiseasy@programming.dev 8 points 10 months ago

Off-topic, but I'm curious why you would put Nim in that list. While I absolutely love the language, I've never heard of anyone using it for anything serious, especially compared to Rust or even Zig. I'd even be surprised if it has more mindshare than D.

(An absolute shame by the way. Nim looks like an absolutely fantastic language.)

[–] cmeerw@programming.dev 10 points 10 months ago

Embracing the GC

I never actually liked the GC in D as it didn't seem to fit in with the general direction of the language, and Walter Bright in D at 20: Hits and Misses says:

Miss: Emphasis on GC

[–] QuadriLiteral@programming.dev 7 points 10 months ago* (last edited 10 months ago) (1 children)

I read through the better part of a linked thread: https://forum.dlang.org/thread/ncbawciyybdksecurmsc@forum.dlang.org?page=1. And wow, as a C++ user, I'm not sure if I should feel blessed about how stable and backwards-compatible the language is, or that D users must be bonkers to put up with the breakages. Using C++ both professionally and for hobby projects, in the last 5 or so years I can remember encountering exactly 1 (gcc) compiler bug. There was a simple workaround + someone else had already reported it so with the next minor update the bug was fixed. And the code that triggered it was a nested CRTP spawn of hell so I didn't blame the compiler from borking on it in the first place, it would've been better for everyone had it never compiled :p

Upgrading a major C++ compiler version was never free in my experience, but even when working in a codebase with ~2M LOC the upgrade (e.g. 14 -> 17) was something that could be prepared in a set of feature branches by one person over the span of one, maybe two weeks. That's for fixing compile errors, I don't remember if we had issues with runtime errors due to an upgrade, but if we did it must've been minor because I remember the transition to 17 was pretty smooth. Note that 14 -> 17 requires changing the requested C++ version for the project, which is different from upgrading the actual compiler, i.e. you can do the latter without the former and your code should not require any changes.

[–] lysdexic@programming.dev 5 points 10 months ago

Upgrading a major C++ compiler version was never free in my experience, but even when working in a codebase with ~2M LOC the upgrade (e.g. 14 -> 17) was something that could be prepared in a set of feature branches by one person over the span of one, maybe two weeks.

That greatly depends on your project, what dependencies it has, and what's involved in the migration. For example, I recall a previous project I worked on that experienced a considerable amount of non-trivial issues when upgrading to C++14 due to unforeseeable curve balls. One of them was caused by a third-party dependency toggling constexpr versions of its member functions only on C++14, which caused a bunch of obscure linker errors as old symbols were no longer available.

[–] lysdexic@programming.dev 6 points 10 months ago (1 children)

From the blog post, it sounds like the underlying motivation is not tied to technical aspects but control over the language. If I had invested any of my personal time onboarding onto D and migrated any of my projects to D, I would be concerned about the negative impact these political stunts have on the tech stack.

[–] Corbin@programming.dev 12 points 10 months ago (2 children)

Walter Bright has fairly odious political opinions; like many social conservatives these days, he likes to complain about wokeness and communism, and I would completely understand a community fork simply to remove his control over various parts of the D language.

Also, just for a quick sanity-check: Which languages have you invested/migrated to, only to find that "political stunts" had a "negative impact" on your planned development?

[–] valpackett@lemmy.blahaj.zone 2 points 10 months ago

Huh. I've played around with D a few years ago.. don't exactly remember his opinions coming to light, but I can't say I'm surprised either.

[–] lysdexic@programming.dev 1 points 10 months ago* (last edited 10 months ago) (1 children)

Walter Bright has fairly odious political opinions;

I fail to see the relevance of what personal opinions and beliefs he may or may not have. You're making it sound like the goal is not to improve a language ir fix issues, but to take something away from a person just because you disagree with their political opinions. That's hardly good use of anyone's time, and sounds terribly petty behavior.

I wish I had that much free time to be able to waste it being so vindictive about such trifling issues.

Which languages have you invested/migrated to, only to find that “political stunts” had a “negative impact” on your planned development?

I don't waste my time with meaningless irrelevant stuff. Either a tech stack serves it's purpose, or it doesn't. I don't have enough free time to waste it trying to cancel others.

[–] Corbin@programming.dev -4 points 10 months ago (1 children)

PLDI is political; in general, any sort of language-design process is political. This is because language is expressive and also constraining, so the expressible and easy-to-express concepts in any language are its de facto default policies.

Social conservatives tend to produce languages which are patrician and sadistic in their demands upon their users; C and Go, D, Hoon and Nock, Hare, and V all come to mind. They see these languages as offering "choice" and power to the end-user, and see languages which have redundant structures and safety, like Ada or Pascal, as "bondage & discipline".

You're likely familiar with the frustration of using designed-by-committee languages, too; say, C++ or Python. These systems tend to evolve social conservatism as a way of preventing an explosion of features, as happened to Perl and is happening to Rust.

Hopefully this is good food for thought. Your choice of language is not politically neutral, but occurs within a social context and has policy implications. Work at a PHP shop for a few years and you'll suddenly care quite a bit about which languages you use!

[–] MaoZedongers@lemmy.today 1 points 9 months ago (1 children)

People can say that everything and anything is political as much as they want, it doesn't make it true.

[–] Corbin@programming.dev 1 points 9 months ago

In this case, we are discussing the leadership of a community project; the leaders are the ones who set policy for the project. In this sense, yeah, it's a political situation.

Given your username, I'm a little surprised that you wouldn't recognize that the leaders of community projects are politically important...

[–] Tramort@programming.dev 1 points 8 months ago* (last edited 8 months ago)

As hard as it is to say this, unfortunate code breaking changese are going to be made. But only if they help achieve the goals listed above.

If this is the case then I think it is an incredibly bad choice to name it D or openD or anything similar

Names are really hard, but non compatible things should not share a name.

One of the coolest things the perl community ever did was changing the name of perl at the major version when perl 5 came out. That is so smart!, and should be the way all software projects function.