Jump to page: 1 25  
Page
Thread overview
Future of D
Dec 09, 2020
Imperatorn
Dec 11, 2020
IGotD-
Dec 11, 2020
Abdulhaq
Dec 13, 2020
data pulverizer
Dec 13, 2020
Max Haughton
Dec 13, 2020
Paul Backus
Dec 13, 2020
H. S. Teoh
Dec 13, 2020
Max Haughton
Dec 15, 2020
Dylan Graham
Dec 15, 2020
Paulo Pinto
Dec 15, 2020
Araq
Dec 15, 2020
Paulo Pinto
Dec 15, 2020
Max Haughton
Dec 15, 2020
Max Haughton
Dec 13, 2020
Bastiaan Veelo
Dec 13, 2020
Max Haughton
Dec 13, 2020
IGotD-
Dec 13, 2020
Paul Backus
Dec 13, 2020
IGotD-
Dec 13, 2020
Paul Backus
Dec 13, 2020
IGotD-
Dec 14, 2020
aberba
Dec 14, 2020
H. S. Teoh
Dec 15, 2020
Max Haughton
Dec 15, 2020
German Diago
Dec 13, 2020
Max Haughton
Dec 13, 2020
Max Haughton
Dec 14, 2020
Paul Backus
Dec 14, 2020
Dukc
Dec 14, 2020
IGotD-
Dec 13, 2020
Bastiaan Veelo
Dec 13, 2020
Dukc
Dec 15, 2020
a11e99z
Dec 15, 2020
a11e99z
Dec 16, 2020
ddcovery
Dec 16, 2020
Max Haughton
Dec 16, 2020
ddcovery
Dec 16, 2020
Max Haughton
Dec 16, 2020
Basile B.
Dec 16, 2020
aberba
Dec 16, 2020
Paulo Pinto
Dec 16, 2020
ddcovery
Dec 13, 2020
data pulverizer
December 09, 2020
https://aberba.com/2020/why-i-still-use-d/

Valid points?
December 11, 2020
On Wednesday, 9 December 2020 at 15:42:15 UTC, Imperatorn wrote:
> https://aberba.com/2020/why-i-still-use-d/
>
> Valid points?

Yes, I think this is pretty much my impression as well. In order to get more contributors, people needs to know what should be done.
December 11, 2020
On Wednesday, 9 December 2020 at 15:42:15 UTC, Imperatorn wrote:
> https://aberba.com/2020/why-i-still-use-d/
>
> Valid points?

Well written article and good points.
December 13, 2020
On Wednesday, 9 December 2020 at 15:42:15 UTC, Imperatorn wrote:
> https://aberba.com/2020/why-i-still-use-d/
>
> Valid points?

It's an interesting article. For me I'm not that bothered whether D becomes huge as long as it keeps growing, and remains "vital". It's more important to me to be able to do funded/paid projects with D - that's the cirlce I'm trying to square. Other than that I'm more interested in the "quality of the language", whether it works well, remains powerful and productive, and feels "good" when I write it.

I'm also more interested in the community. One thing that initially shocked me about the D language is that random people would suddenly turn up and start "dissing" the language and the community seemed to take these criticisms in its stride, which I really liked. I wouldn't like D community to become toxic, aloof, or to drive out criticisms even if they seem unfair. These can easily happen in programming language forums/communities. Even if it leads to nothing dissent can be healthy.

I think that funded projects in academic departments can be a one way of increasing the popularity of D. For example an academic keen on D chooses to implement some government funded application in D, which other people use and become familiar with the language. This is often the way languages become more popular - or gain widespread use, e.g. Scala (from Spark) and Julia (from many different projects).

December 13, 2020
On Sunday, 13 December 2020 at 18:47:39 UTC, data pulverizer wrote:
> On Wednesday, 9 December 2020 at 15:42:15 UTC, Imperatorn wrote:
>> https://aberba.com/2020/why-i-still-use-d/
>>
>> Valid points?
>
> It's an interesting article. For me I'm not that bothered whether D becomes huge as long as it keeps growing, and remains "vital". It's more important to me to be able to do funded/paid projects with D - that's the cirlce I'm trying to square. Other than that I'm more interested in the "quality of the language", whether it works well, remains powerful and productive, and feels "good" when I write it.
>
> I'm also more interested in the community. One thing that initially shocked me about the D language is that random people would suddenly turn up and start "dissing" the language and the community seemed to take these criticisms in its stride, which I really liked. I wouldn't like D community to become toxic, aloof, or to drive out criticisms even if they seem unfair. These can easily happen in programming language forums/communities. Even if it leads to nothing dissent can be healthy.
>
> I think that funded projects in academic departments can be a one way of increasing the popularity of D. For example an academic keen on D chooses to implement some government funded application in D, which other people use and become familiar with the language. This is often the way languages become more popular - or gain widespread use, e.g. Scala (from Spark) and Julia (from many different projects).

I really think properly killing the GC would give us a big boost in fresh blood to the community. It would still be there, but it's a huge turn off to new users. That and a bit of blog-spam, I constantly see articles for new languages that are (frankly) a bit rubbish compared to various D features but because they are post-(new generation of languages) they are "cooler"
December 13, 2020
On Sunday, 13 December 2020 at 18:47:39 UTC, data pulverizer wrote:
> On Wednesday, 9 December 2020 at 15:42:15 UTC, Imperatorn wrote:
>> https://aberba.com/2020/why-i-still-use-d/
>>
>> Valid points?
>
> It's an interesting article... [SNIP]

p.s. There are great points on documentation, tooling, libraries, overall plan, but I think these are getting better with time. I am certainly excited with the scheduled changes and upgrades to the language. Could things be better? Yes, but I think progress is definitely being made.

December 13, 2020
On Sunday, 13 December 2020 at 19:33:30 UTC, Max Haughton wrote:
>
> I really think properly killing the GC would give us a big boost in fresh blood to the community. It would still be there, but it's a huge turn off to new users. That and a bit of blog-spam, I constantly see articles for new languages that are (frankly) a bit rubbish compared to various D features but because they are post-(new generation of languages) they are "cooler"

As far as I know, the major obstacles to making the GC truly pay-as-you-go are things like

- stabilization of std.experimental.allocator
- allocator-aware containers in Phobos (à la emsi_containers [1])
- @safe reference counting in Phobos or Druntime (à la automem [2])

Unfortunately, to my knowledge, nobody is actively working on these, and the D Language Foundation has not made any effort to prioritize them. Which is a shame, since so much of the work has already been done.

[1] https://code.dlang.org/packages/emsi_containers
[2] https://code.dlang.org/packages/automem
December 13, 2020
On Sun, Dec 13, 2020 at 07:33:30PM +0000, Max Haughton via Digitalmars-d wrote: [...]
> I really think properly killing the GC would give us a big boost in fresh blood to the community. It would still be there, but it's a huge turn off to new users.

Honestly, IMNSHO the anti-GC crowd is only a vocal minority.  For most normal applications the GC is actually a big plus.  (And I say this as someone coming from a strong C/C++ background who used to hate anything GC-related.)  It eliminates an entire class of bugs that are extremely time-consuming to debug and work around, and cleans up your internal APIs in a significant way that allows clean integration of a lot of components, without constantly having to fiddle with low-level memory allocation details at every turn.

And I'm almost 100% certain that if D were to eliminate the GC tomorrow, we would not see a big increase in users -- the naysayers will merely move on to the next thing to hate.  Probably the lack of native refcounting / borrowing support.  Or the state of `shared`.  Or any of various favorite whipping boys that we love to pick on.


T

-- 
MS Windows: 64-bit rehash of 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand 1-bit of competition.
December 13, 2020
On Sunday, 13 December 2020 at 19:33:30 UTC, Max Haughton wrote:
> I really think properly killing the GC

What do you mean by this? What would take its place, and what practical steps would need to be taken? And above all, how can the language and library features that rely on the GC today be replaced by alternatives that are as appealing?

> would give us a big boost in fresh blood to the community. It would still be there, but it's a huge turn off to new users.

I don’t understand, when it’s still there, GCfobics will still think there is reason to look elsewhere. There are various ways to use D without garbage collection today, so it is important to define what this imaginary language will look like.

I don’t think there is a boatload of fresh blood just waiting for a different D even if is has a GC that has been killed.

I love the features that are enabled by the GC and I love not needing to worry about the problems that manual memory management brings.

Above all, I just don’t buy that “it's a huge turn off to new users”.

I think D hits the sweet spot with a pluggable, configurable, profilable and optional garbage collector!

— Bastiaan.


December 13, 2020
On Sunday, 13 December 2020 at 20:35:15 UTC, H. S. Teoh wrote:
> On Sun, Dec 13, 2020 at 07:33:30PM +0000, Max Haughton via Digitalmars-d wrote: [...]
>> I really think properly killing the GC would give us a big boost in fresh blood to the community. It would still be there, but it's a huge turn off to new users.
>
> Honestly, IMNSHO the anti-GC crowd is only a vocal minority.  For most normal applications the GC is actually a big plus.  (And I say this as someone coming from a strong C/C++ background who used to hate anything GC-related.)  It eliminates an entire class of bugs that are extremely time-consuming to debug and work around, and cleans up your internal APIs in a significant way that allows clean integration of a lot of components, without constantly having to fiddle with low-level memory allocation details at every turn.
>
> And I'm almost 100% certain that if D were to eliminate the GC tomorrow, we would not see a big increase in users -- the naysayers will merely move on to the next thing to hate.  Probably the lack of native refcounting / borrowing support.  Or the state of `shared`.  Or any of various favorite whipping boys that we love to pick on.
>
>
> T

Oh, I agree. Having the GC is mainly a PR problem, but we absolutely do need a real alterative. We should aim to be closer to Rust than C++. FWIW I would never get rid of it completely but I also don't think ours will ever be good enough to really challenge RC.

Borrowing is definitely doable, @live is a start but we need to be able to (say) invalidate an immutable range when it's data changes.

Shared is probably the "easiest" to fix economically, but requires very subtle specification work.
« First   ‹ Prev
1 2 3 4 5