digitalmars.D - So D will have LTS or not?
- linger (8/8) Jul 03 2023 Looks like The D Language Foundation treat D as a toy language(or
- Martyn (48/57) Jul 03 2023 I am not sure if we need another thread on this as the previous
- GrimMaple (29/56) Jul 03 2023 The more threads there are, the bigger the chance of something
- Martyn (24/32) Jul 03 2023 I am using this as an opportunity to learn some lower-level
- bachmeier (16/31) Jul 03 2023 You're going to have to clarify this part in order to make
Looks like The D Language Foundation treat D as a toy language(or only a language not a production), and the members don't care user experience LSP/documnet/vscode/github which users really care. thanks webfreak did this. DLF more like said you can do it just do it, if you can't we don't. but most of us are endpoint user not a language developer. https://forum.dlang.org/post/u6jjkn$2e7b$1 digitalmars.com https://forum.dlang.org/thread/avvmlvjmvdniwwxemcqu forum.dlang.org
Jul 03 2023
On Monday, 3 July 2023 at 07:07:13 UTC, linger wrote:Looks like The D Language Foundation treat D as a toy language(or only a language not a production), and the members don't care user experience LSP/documnet/vscode/github which users really care. thanks webfreak did this. DLF more like said you can do it just do it, if you can't we don't. but most of us are endpoint user not a language developer. https://forum.dlang.org/post/u6jjkn$2e7b$1 digitalmars.com https://forum.dlang.org/thread/avvmlvjmvdniwwxemcqu forum.dlang.orgI am not sure if we need another thread on this as the previous one is still rather active. As a regular reader of the forums I have posted little. Recently I shared my views supporting for an LTS cycle. I am not the best person to present examples. I am simply sharing my support for an LTS. I think the original poster of "D has become unbearable.." made valid points. The recent one from Z3Solver is a good read. For me, as someone who has small "to-the-point" server programs in D, I can only share my concerns when wanting to use D for big projects that requires a combination of libraries with DUB like Gtk, Zeromq/Nanomsg, JSON serializer, Database (postgres), Web (Vibe.d) etc. I see nothing more than compilation hell as each library release targeting different compiler releases. When each release can be breaking changes, it is not unreasonable for me to have this concern. *It is also worth noting posts about people wanting to use D for projects work are told to avoid doing so. One of these is one of my posts in 2020* Some references: - https://forum.dlang.org/thread/cffdqyvthqvurbcpxvbo forum.dlang.org https://forum.dlang.org/post/kfknqdjfkjbljhqrjarp forum.dlang.org Thing is, I do not see an LTS being created any time soon. It is more than to simply `git branch..` and here ya go! It will require a few people to maintain it. On top of this, it will be a cultural change in the D ecosystem especially for library developers to target target LTS, and to provide a version number standard to indicate which LTS it refers to. At least that is my opinion on the matter. I want D to be successful. To me Dlang is 'the language' that developer. I am at an age, now, where I am not sure I want to learn Rust - as I hear is a steeper curve coming from those C\C++ background. I know I can do it, obviously - but I was hoping for D to be the preferred choice for me. Rust is getting more and more momentum. Recently it has been included into the Linux kernel which, to me, has given it some extra brownie points in terms of free advertising. With Z3Solver recent comment about facebook ditching D and replaced with Rust does say a lot, along with his comments on crates not breaking (or worrying as much about breaking) if he upgrades, etc, comes back to my views on using D for larger projects. There is a lot of talent in the D community and I plan to invest some time learning the internals of D, hoping I could be one of the LTS maintainers in the near future. Of course, it is very unlikely I can do this on my own... and won't get round to "being ready" for such a task anytime soon.
Jul 03 2023
For the OP, I think D is not getting any LTS. On Monday, 3 July 2023 at 10:36:11 UTC, Martyn wrote:I am not sure if we need another thread on this as the previous one is still rather active.The more threads there are, the bigger the chance of something being actually done. At this point, I don't even know what is going to work.Thing is, I do not see an LTS being created any time soon. It is more than to simply `git branch..` and here ya go! It will require a few people to maintain it. On top of this, it will be a cultural change in the D ecosystem especially for library developers to target target LTS, and to provide a version number standard to indicate which LTS it refers to. At least that is my opinion on the matter.I share a similar opinion, that simply branching off any release point and calling it LTS isn't going to be cutting it. Not only this LTS has to be recognized, but the whole D language would need some form of feature/bugfix planning. You can't have an LTS release without planning features ahead-of-time. Inevitably, LTS is going to affect language development. And it's not going to happen when leadership wants to have the mentality of "I can add whatever I want whenever I want".I want D to be successful. To me Dlang is 'the language' that ticks 90% of the boxes and easy to transition to being a C and to learn Rust - as I hear is a steeper curve coming from those C\C++ background. I know I can do it, obviously - but I was hoping for D to be the preferred choice for me.Also same, except I'd rather go back to C because it gives much less trouble long-term.Rust is getting more and more momentum. Recently it has been included into the Linux kernel which, to me, has given it some extra brownie points in terms of free advertising. With Z3Solver recent comment about facebook ditching D and replaced with Rust does say a lot, along with his comments on crates not breaking (or worrying as much about breaking) if he upgrades, etc, comes back to my views on using D for larger projects.This just further cements my view of D being unable to retain users and being overfocused on bringing temporary users with some weird new half-baked feature. Walter complained that Facebook never "reached out to him", but why doesn't he reach out to ask why? I reached out with my complaints, for example, and where did it bring me? It only cemented my wish to drop D.There is a lot of talent in the D community and I plan to invest some time learning the internals of D, hoping I could be one of the LTS maintainers in the near future. Of course, it is very unlikely I can do this on my own... and won't get round to "being ready" for such a task anytime soon.I think, first of all, the D community must be open for the idea of LTS. As in, they need to "man up" and bring a valid set of points at which an LTS would be even possible. As long as they have the position of "do it yourself", there is an endless pit of possibiliteis for D Core Team (and Walter personally) to reject your work based on opinion. In short, I'd say don't waste your time trying to convinince people to accept your work. It's not worth it for free.
Jul 03 2023
Martyn <martyn.developer googlemail.com> On Monday, 3 July 2023 at 11:48:48 UTC, GrimMaple wrote:I think, first of all, the D community must be open for the idea of LTS. As in, they need to "man up" and bring a valid set of points at which an LTS would be even possible. As long as they have the position of "do it yourself", there is an endless pit of possibiliteis for D Core Team (and Walter personally) to reject your work based on opinion. In short, I'd say don't waste your time trying to convinince people to accept your work. It's not worth it for free.I am using this as an opportunity to learn some lower-level language development. In the past, I created my own Scheme language in C for **** and giggles which is going back a few years, now. Obviously this is a different beast so learning the internals of D is going to be a 'fun excercise' but, on a serious note, opens the door for me to be more prepared as a potential member of the `LTS team` in the future. When I am ready, I will post a new thread on `LTS proposal` and how I see it coming together, and be open to futher replies ideas and suggestions. That thread, when it happens, will be the real telling (imo) on how the D community will respond. I know my comments above are vague, and maybe I am being more positive (or ignorant?) to this plan than others. I understand there are frustrations by a number of people here and, granted, many views and opinions I totally understand. If my plans/request gets rejected then maybe I will start to be more negative, too. On the lighter side, if my proposal for LTS gets rejected then atleast I learned some internals to language development, and will decide to move on to something else. The way things are going, it will likely be Rust. Still, one person did respond in the other thread, offering help if needed. I do appreciate that, obviously. As I wrote, I do want D to be successful.
Jul 03 2023
On Monday, 3 July 2023 at 11:48:48 UTC, GrimMaple wrote:On Monday, 3 July 2023 at 10:36:11 UTC, Martyn wrote:You're going to have to clarify this part in order to make progress. What bug fixes are required? Currently we have many compilers in use out in the wild, and there are no bug fixes being ported to them from later releases. (Has a single bug fix been ported from 2.104 to 2.101, even though they're only six months apart?) Those in power are saying that *all* bug fixes would have to be ported back to an LTS, and until the manpower for that is in place, we have to stick with the current mess. If you want to push this through, you're going to have to find a compromise that's realistic. If there's an LTS release every 18 months, anything related to new features will take care of itself. New features will only enter if they're ready. Anyone wanting to operate on the cutting edge can still use the latest non-LTS release. The LTS is for folks wanting stability, not features.Thing is, I do not see an LTS being created any time soon. It is more than to simply `git branch..` and here ya go! It will require a few people to maintain it. On top of this, it will be a cultural change in the D ecosystem especially for library developers to target target LTS, and to provide a version number standard to indicate which LTS it refers to. At least that is my opinion on the matter.I share a similar opinion, that simply branching off any release point and calling it LTS isn't going to be cutting it. Not only this LTS has to be recognized, but the whole D language would need some form of feature/bugfix planning. You can't have an LTS release without planning features ahead-of-time.
Jul 03 2023
On Monday, 3 July 2023 at 12:43:30 UTC, bachmeier wrote:You're going to have to clarify this part in order to make progress. What bug fixes are required? Currently we have many compilers in use out in the wild, and there are no bug fixes being ported to them from later releases. (Has a single bug fix been ported from 2.104 to 2.101, even though they're only six months apart?) Those in power are saying that *all* bug fixes would have to be ported back to an LTS, and until the manpower for that is in place, we have to stick with the current mess. If you want to push this through, you're going to have to find a compromise that's realistic.I hate to say this, but this already was overclarified and needs no further discussion. I already said what an LTS release should be in my opinion. I already asked (dirctly) about what D foundation needs to make it happen. No concrete proposals were made in return; no roles were defined; no amount of manpower needed was specified. How do you expect me to do all this? It's not in my responsibility zone to make decisions __for__ the DLF. If they could come up with a list of roles, I could fit one of those roles on demand. I'm not gonna do extensive research of how DLF works for free. The community effort should go both ways, and I am (or, at least, _was_) ready to help in any way I could. But DLF is refusing to contribute in the same manner.If there's an LTS release every 18 months, anything related to new features will take care of itself. New features will only enter if they're ready. Anyone wanting to operate on the cutting edge can still use the latest non-LTS release. The LTS is for folks wanting stability, not features.No, it won't take care of itself. As of now, `ImportC` is still a feature that doesn't work, but it's in a __stable__ compiler. If there was an LTS release, there would be a need for release planning, as ImportC is still clearly an unfinished feature and doesn't belong in an LTS release. If we had LTS that needed to happen "here and now", the language wouldn't be ready for it. This is what I mean by feature planning.
Jul 03 2023
On Monday, 3 July 2023 at 12:43:30 UTC, bachmeier wrote:Currently **we have many compilers in use out in the wild**, and there are no bug fixes being ported to them from later releases. (Has a single bug fix been ported from 2.104 to 2.101, even though they're only six months apart?)We currently have a release cycle, released often, like so:- 2.101 --> 2.102 --> 2.103 --> 2.104 --> etc I do not expect any ~bug fixes~ for previous releases. After all, this release process, to my knowledge, is **purely sequential**. Keep moving forward type approach. Whatever the latest release is, is what's being advertised/presented on the dlang download page. It is also the default compiler when using the *.sh installer. The problem, at its core, is that a new release could, potentially, cause a *breaking change* yet we push forward the it's new/latest release. As a result, and as you put it, you end up with many `compilers out in the wild` which does not help application or library developers using D to get stuff done. A higher level developer that is trying to create a GUI application, or a Website, or a Worker app, etc, should not be presented with all these releases. They are also left in the dark when adding a DUB dependency. What version was that library tested on before its latest release to DUB? By default we are encouraged to use the latest release. Are we expecting library maintainers to keep up-to-date on a monthly basis all because "this now breaks that" attitude? The core team, in my opinion, need to reach a point of saying "Okay, time for a new TLS release" and spend the next few releases cleaning up and making it stable. Once happy (say release 2.109.0) we branch off with a new TLS stable release. Lets call it "TLS23" (as in it was released in 2023) TLS23 is the main release, and should be the main highlight of the download page. Sure, latest D releases can still be advertised, but to use at your own risk, etc.Those in power are saying that all bug fixes would have to be ported back to an LTS, and until the manpower for that is in place, we have to stick with the current messAgain I know this is not a simple job (as I mentioned in my previous post) - it will require a few people to handle TLS management. However I do not believe `all bug fixes` need to be placed back into the current TLS. Yes, the current TLS branch will start to fall behind as newer releases are out (2.110, 2.111, 112.0, etc) but some bug fixes wont be relevant to the current TLS. It all depends on what the bug fixes are. I would say **important** fixes, like major vulnerability issues should be factored into the current TLS branch. Considering, in recent D meetings, has been the idea of pushing Dlang on social media, etc, to try and entice new users to the language.. or to, atleast, get people talking/sharing about D. If TLS was taken more seriously, is also LIKELY to endice not just new members.. **but keeping existing ones!**
Jul 03 2023
On Monday, 3 July 2023 at 16:04:27 UTC, Martyn wrote:On Monday, 3 July 2023 at 12:43:30 UTC, bachmeier wrote:I couldn't agree more. If the goal is to get users, then the DLF has to support what the users want. The DLF needs to decide what it's mission is and who it is trying to serve and then do the work of understanding the people they are trying to serve. If it is themselves, then they don't need to talk to anyone. If they are trying to be more popular, then they need to talk to other developers and take the time and effort to understand. Each complaint raised in good faith is coming from someone's actual experience. Maybe it's just that they don't understand and the documentation needs to be better or more accessible. It's also possible that it's an actual problem with the way the language is being developed. It's possible they are not in the target group. Whatever the case, they have feelings about the software and want to be heard. If you hear them, you will learn their perspective. It you learn enough perspectives, you will know why the language is not popular. The only fact we can all agree on is the language is not popular and that implies that the language designers have not figured out why. If they had figured out why, it would be popular or else we would mostly just agree conditions were such that it could not be popular. Just about everyone on this forum would be willing to pitch in to help the maintainers understand the issues. Those forum users need to know how and they need to know they will be listened to before they go through the effort again. I am not saying I expect this or demand it or anything. I'm just saying if you want to be popular or even be a language people have heard of, you will have to understand the people who are complaining. If you make it their job to be understood, then it is unlikely they will do all the work for you. It might sound like I'm a hater, same as some of the previous posters, but HERE I AM trying to make it work again. Here I am looking at the D forum, trying to make another go of making this my language. I will spare my personal details and just make my pitch that I want this language to work but it is hard to justify.Currently **we have many compilers in use out in the wild**, and there are no bug fixes being ported to them from later releases. (Has a single bug fix been ported from 2.104 to 2.101, even though they're only six months apart?)We currently have a release cycle, released often, like so:- 2.101 --> 2.102 --> 2.103 --> 2.104 --> etc I do not expect any ~bug fixes~ for previous releases. After all, this release process, to my knowledge, is **purely sequential**. Keep moving forward type approach. Whatever the latest release is, is what's being advertised/presented on the dlang download page. It is also the default compiler when using the *.sh installer. The problem, at its core, is that a new release could, potentially, cause a *breaking change* yet we push forward the it's new/latest release. As a result, and as you put it, you end up with many `compilers out in the wild` which does not help application or library developers using D to get stuff done. A higher level developer that is trying to create a GUI application, or a Website, or a Worker app, etc, should not be presented with all these releases. They are also left in the dark when adding a DUB dependency. What version was that library tested on before its latest release to DUB? By default we are encouraged to use the latest release. Are we expecting library maintainers to keep up-to-date on a monthly basis all because "this now breaks that" attitude? The core team, in my opinion, need to reach a point of saying "Okay, time for a new TLS release" and spend the next few releases cleaning up and making it stable. Once happy (say release 2.109.0) we branch off with a new TLS stable release. Lets call it "TLS23" (as in it was released in 2023) TLS23 is the main release, and should be the main highlight of the download page. Sure, latest D releases can still be advertised, but to use at your own risk, etc.Those in power are saying that all bug fixes would have to be ported back to an LTS, and until the manpower for that is in place, we have to stick with the current messAgain I know this is not a simple job (as I mentioned in my previous post) - it will require a few people to handle TLS management. However I do not believe `all bug fixes` need to be placed back into the current TLS. Yes, the current TLS branch will start to fall behind as newer releases are out (2.110, 2.111, 112.0, etc) but some bug fixes wont be relevant to the current TLS. It all depends on what the bug fixes are. I would say **important** fixes, like major vulnerability issues should be factored into the current TLS branch. Considering, in recent D meetings, has been the idea of pushing Dlang on social media, etc, to try and entice new users to the language.. or to, atleast, get people talking/sharing about D. If TLS was taken more seriously, is also LIKELY to endice not just new members.. **but keeping existing ones!**
Jul 05 2023
On Monday, 3 July 2023 at 16:04:27 UTC, Martyn wrote:On Monday, 3 July 2023 at 12:43:30 UTC, bachmeier wrote:Apologies, noticed I have accidentally placed TLS rather than LTS in my comment (in places) other than that, my comment still stands. :-)LTS != TLS
Jul 06 2023