6 ms·

All these languages (D, nim, crystal and many others) look nice but unfortunately the lack of adoption means few ressources and a small community which in turns

All these languages (D, nim, crystal and many others) look nice but unfortunately the lack of adoption means few ressources and a small community which in turns means lack of adoption in a vicious circle. I now think the most important skill a language creator can have is to be able to create hype (as long as the language itself is good enough of course).

qwery 3y ago
I've been interested in D since about 2010 and I'm pretty sure it's about ten years older than that. So if there's a vicious circle, I'm not sure what the effect of that is.
FireInsight 3y ago
Universal Function Call Syntax, the syntax feature where you can call a function in a procedular language you can call function in a multitude of ways. For example (pseudocode): ``` func toUpperCase(s: string) <IMPLEMENTATION> a = "hello world" echo toUpperCase(a) # HELLO WORLD echo a.toUpperCase # HELLO WORLD echo toUpperCase a # HELLO WORLD echo a.toUpperCase # HELLO WORLD ``` With the dot syntax, the first argument is the one indicated by the dot, and the rest of the arguments are in the parentheses. In nim, you can leave out the parentheses too, which makes `echo` statements cleaner. It's a shame more mainstream languages don't have this feature.
- rjha 3y ago
  formatting the above function for better readability ``` func toUpperCase(s: string) <IMPLEMENTATION> a = "hello world" echo toUpperCase(a) # HELLO WORLD echo a.toUpperCase # HELLO WORLD echo toUpperCase a # HELLO WORLD echo a.toUpperCase # HELLO WORLD ```
- usrusr 3y ago
  Why would you ever want the dotless version though, in cases where it's not terrible? (e.g when there are multiple arguments of equal importance and calls where the argument is appears more as an option for esoteric cases than the implementation's main subject) I really like the option to "semantically scope" a function to its main subject, like in kotlin extension methods. But I fail to see why I'd ever want to have both options. Is it just a compatibility thing, to be able to call code written for conventional languages? Or from developers who don't like that approach?
  - dmit 3y ago
    Here's one case. Instead of let letters = word.chars().filter(|ch| ch.is_alphabetic()); you can just write let letters = word.chars().filter(is_alphabetic); since the difference between "methods" and "functions" is purely syntactic.
    - usrusr 3y ago
      Most languages that have a way to define dot-syntax functions that aren't actually methods of the type also come with the ability to use any zero-arg method (both true methods and dot-syntax extension functions) as a one-arg function reference, or rather n-arg methods as n+1-arg function references. No need to crowd the unqualified namespace just to be able to use them without wrapping in a lambda.
- lifthrasiir 3y ago
  UFCS only works well when the language also supports function overloading, which is a questionable feature by itself because it greatly complicates resolution processes and constrains other type system features. For example, function overloading in Rust will definitely conflict with traits (and Rust trait system is already complex enough). UFCS increases the complexity on top of that, and the resulting convenience is more or less marginal in my opinion. Yes, it would be great to have a way to turn a method into a function. That doesn't necessarily mean that they have to be unified---an explicit conversion is enough.
  - 3836293648 3y ago
    UFCS is not the feature to call anything like `a.f(b)`, it's to make all functions callable the same way. Calling a method like `A::f(a, b)` is also UFCS and Rust does have that.
    - lifthrasiir 3y ago
      I'm specifically referring to UFCS as in D and Nim (possibly more). Rust's `A::f(a, b)` was also called UFCS in the past, but it is a distinct syntax and the term is no longer used [1]. The UFCS in question would look like `f(a, b)` instead, and conversely, you may be able to call an ordinary function `f` with `a.f(b)` as well. Rust allows neither of them. [1] https://doc.rust-lang.org/reference/expressions/call-expr.html#disambiguating-function-calls https://doc.rust-lang.org/reference/expressions/call-expr.ht...
      - WalterBright 3y ago
        D supports both `f(a,b)` and `a.f(b)`.
- cassepipe 3y ago
  It's in cpp2/cppfront I believe, for the record
- camgunz 3y ago
  (your formatting got a little lost but I get the gist) I've done a little langdev and I've found that UFCS interferes with stuff like field access (person.name) or things like interfaces. Let's say you have a person struct like { name: str } but then also a Label interface like Label { name: fn () -> str }. It's kind of a broader problem of being able to extend things in any place you might imagine, like I'll implement a trait on this struct here, I'll implement a function on this struct here, etc. etc. and before you know it your code is extremely nonlocal. There are ways to temper this, e.g. Rust combats this a little by having to have traits in scope for them to apply, but that's annoying in its own way. I'm just saying it's not a free lunch, I think anyway.
  - FireInsight 3y ago
    Sorry about the formatting, typing this on my phone. The preview looked alright, but ig that didn't translate. For the function-field interference, I'd probably just work it based on situation. And usually naming functions clearly as actions with verbs and fields/variables with nouns.
    - camgunz 3y ago
      Sure yeah but like, you gotta deal with clashes. The problem itself isn't hard, but trying to get the ergonomics right is pretty tough, especially when you're talking about multiple dependencies that didn't coordinate at all with each other (this trait adds a "name", this one adds a "getName", this one adds a "display_name", this one adds a "get_name").
      - FireInsight 3y ago
        The mixing of snake_case and camelCase is solved by Nim by ignoring capitalization and underscores. This feature is often controversial when talked about on HN, but I love it. I like camelCase, but I understand why a python user would be more comfortable with snake_case. Of course one codebase should set its internal style to prevent faults in control-f.
- WalterBright 3y ago
  D has had UFCS for maybe a decade. It's a very popular feature.
nindalf 3y ago
I agree with you on the hype front. Hype is necessary to help a language escape this vicious cycle. But then it’s kinda funny seeing developers being especially hostile to promotion/advertising of new languages. I’ve seen a lot of protest on HN and Reddit from people who feel the currently popular language is being “shoved down their throat”. But if you’re not open to that we would be writing C forever, let alone C++ or Java (which had their own hype cycles). > The world is often unkind to new talent, new creations. The new needs friends.
- eigenspace 3y ago
  As an enthusiastic Julia user, I can definitely attest to this. It's frustrating to just want to share with people what you find cool about a language, only to be accused of being part of some astroturfing campaign, or for any discussion of the language being immediately derailed by people complaining about 1-based indexing. Granted, there are definitely cases out there where Julia users have been overzealous and undersensitive when trying to convince others to come try out the language, but my experience with these people is that they're almost always coming at it from a place of just being excited about finding a language that works well for them and solved so many of their issues, and so they want to share that with others. ____ D is a cool language and it's a shame it seems to get ignored so much. I hope D people continue to work at it.
  - xyproto 3y ago
    Julia is the only programming language that makes me annoyed when I think of it, because it was so troublesome to package for Arch Linux and because of how little they care about increasing the safety in the language (like Rust or Ada).
    - majoe 3y ago
      What made Julia so difficult to package? I'm genuinely curious. > ... because of how little they care about increasing the safety in the language (like Rust or Ada). I think it's a bit harsh to compare Julia to Rust on that front. Julia has completely different design goals. Compared to Rust's borrow checker and C++'s move semantics, Julia's immutability-by-default (+ clever compiler optimizations) gives a good trade off between performance, safety and ease of use. While Rust goes for safety + performance, Julia goes for performance + ease of use (respectively dynamicity). Nevertheless, I miss some features related to type driven development in Julia, which would improve safety: - A newtype idiom - Sum types - Explicit, type-checked interfaces : I actually would prefer something like C++20 concepts (a blacklist approach) to Rust's trait (or typeclasses, a whitelist approach), because it would be a better fit for Julia's design goals.
mratsim 3y ago
V-style hype?
seanalltogether 3y ago
Ruby is an interesting use case because the Rails framework was the hype train that pushed it into the mainstream. Also would Rust or GO have gotten as much adoption if not for the strong dependency system built right in? New languages clearly need more then just a compiler or runtime to attract developers now.
silent_cal 3y ago
It also has to be very easy to use. There are a lot of languages I won't even look at because they're not intuitive, and there's no clear reason for me to invest the time to learn them. I think developers tend to focus on "innovations" that only nerds will care about, and neglect making innovations in how easy the language is to learn, use and read. At the end of the day these features are the main factors determining whether or not a language will be adopted.
- neuromanser 3y ago
  https://sr.ht/~rne/dram https://sr.ht/~rne/dram was my first software in D, I don't remember having any issues with the language itself. Documentation (language and stdlib) was mostly ok, same with compiler diagnostics (watch out for long method call chains involving lambdas). I agree with the diagnosis elsewhere in the thread: D is where it is today (IOW, isn't where it could be) because of the Tango/Phobos schism and closed-source license issues from almost twenty years ago.
WalterBright 3y ago
What D has is an excellent community. Many users have told me that the D community is just the kind of community they were looking for in a programming language. For example, we don't do politics. Our forums are D only.

qwery 3y ago

I've been interested in D since about 2010 and I'm pretty sure it's about ten years older than that. So if there's a vicious circle, I'm not sure what the effect of that is.

FireInsight 3y ago

Universal Function Call Syntax, the syntax feature where you can call a function in a procedular language you can call function in a multitude of ways. For example (pseudocode): ``` func toUpperCase(s: string) <IMPLEMENTATION> a = "hello world" echo toUpperCase(a) # HELLO WORLD echo a.toUpperCase # HELLO WORLD echo toUpperCase a # HELLO WORLD echo a.toUpperCase # HELLO WORLD ``` With the dot syntax, the first argument is the one indicated by the dot, and the rest of the arguments are in the parentheses. In nim, you can leave out the parentheses too, which makes `echo` statements cleaner. It's a shame more mainstream languages don't have this feature.

rjha 3y ago
formatting the above function for better readability ``` func toUpperCase(s: string) <IMPLEMENTATION> a = "hello world" echo toUpperCase(a) # HELLO WORLD echo a.toUpperCase # HELLO WORLD echo toUpperCase a # HELLO WORLD echo a.toUpperCase # HELLO WORLD ```
usrusr 3y ago
Why would you ever want the dotless version though, in cases where it's not terrible? (e.g when there are multiple arguments of equal importance and calls where the argument is appears more as an option for esoteric cases than the implementation's main subject) I really like the option to "semantically scope" a function to its main subject, like in kotlin extension methods. But I fail to see why I'd ever want to have both options. Is it just a compatibility thing, to be able to call code written for conventional languages? Or from developers who don't like that approach?
- dmit 3y ago
  Here's one case. Instead of let letters = word.chars().filter(|ch| ch.is_alphabetic()); you can just write let letters = word.chars().filter(is_alphabetic); since the difference between "methods" and "functions" is purely syntactic.
  - usrusr 3y ago
    Most languages that have a way to define dot-syntax functions that aren't actually methods of the type also come with the ability to use any zero-arg method (both true methods and dot-syntax extension functions) as a one-arg function reference, or rather n-arg methods as n+1-arg function references. No need to crowd the unqualified namespace just to be able to use them without wrapping in a lambda.
lifthrasiir 3y ago
UFCS only works well when the language also supports function overloading, which is a questionable feature by itself because it greatly complicates resolution processes and constrains other type system features. For example, function overloading in Rust will definitely conflict with traits (and Rust trait system is already complex enough). UFCS increases the complexity on top of that, and the resulting convenience is more or less marginal in my opinion. Yes, it would be great to have a way to turn a method into a function. That doesn't necessarily mean that they have to be unified---an explicit conversion is enough.
- 3836293648 3y ago
  UFCS is not the feature to call anything like `a.f(b)`, it's to make all functions callable the same way. Calling a method like `A::f(a, b)` is also UFCS and Rust does have that.
  - lifthrasiir 3y ago
    I'm specifically referring to UFCS as in D and Nim (possibly more). Rust's `A::f(a, b)` was also called UFCS in the past, but it is a distinct syntax and the term is no longer used [1]. The UFCS in question would look like `f(a, b)` instead, and conversely, you may be able to call an ordinary function `f` with `a.f(b)` as well. Rust allows neither of them. [1] https://doc.rust-lang.org/reference/expressions/call-expr.html#disambiguating-function-calls https://doc.rust-lang.org/reference/expressions/call-expr.ht...
    - WalterBright 3y ago
      D supports both `f(a,b)` and `a.f(b)`.
cassepipe 3y ago
It's in cpp2/cppfront I believe, for the record
camgunz 3y ago
(your formatting got a little lost but I get the gist) I've done a little langdev and I've found that UFCS interferes with stuff like field access (person.name) or things like interfaces. Let's say you have a person struct like { name: str } but then also a Label interface like Label { name: fn () -> str }. It's kind of a broader problem of being able to extend things in any place you might imagine, like I'll implement a trait on this struct here, I'll implement a function on this struct here, etc. etc. and before you know it your code is extremely nonlocal. There are ways to temper this, e.g. Rust combats this a little by having to have traits in scope for them to apply, but that's annoying in its own way. I'm just saying it's not a free lunch, I think anyway.
- FireInsight 3y ago
  Sorry about the formatting, typing this on my phone. The preview looked alright, but ig that didn't translate. For the function-field interference, I'd probably just work it based on situation. And usually naming functions clearly as actions with verbs and fields/variables with nouns.
  - camgunz 3y ago
    Sure yeah but like, you gotta deal with clashes. The problem itself isn't hard, but trying to get the ergonomics right is pretty tough, especially when you're talking about multiple dependencies that didn't coordinate at all with each other (this trait adds a "name", this one adds a "getName", this one adds a "display_name", this one adds a "get_name").
    - FireInsight 3y ago
      The mixing of snake_case and camelCase is solved by Nim by ignoring capitalization and underscores. This feature is often controversial when talked about on HN, but I love it. I like camelCase, but I understand why a python user would be more comfortable with snake_case. Of course one codebase should set its internal style to prevent faults in control-f.
WalterBright 3y ago
D has had UFCS for maybe a decade. It's a very popular feature.

nindalf 3y ago

I agree with you on the hype front. Hype is necessary to help a language escape this vicious cycle. But then it’s kinda funny seeing developers being especially hostile to promotion/advertising of new languages. I’ve seen a lot of protest on HN and Reddit from people who feel the currently popular language is being “shoved down their throat”. But if you’re not open to that we would be writing C forever, let alone C++ or Java (which had their own hype cycles). > The world is often unkind to new talent, new creations. The new needs friends.

eigenspace 3y ago
As an enthusiastic Julia user, I can definitely attest to this. It's frustrating to just want to share with people what you find cool about a language, only to be accused of being part of some astroturfing campaign, or for any discussion of the language being immediately derailed by people complaining about 1-based indexing. Granted, there are definitely cases out there where Julia users have been overzealous and undersensitive when trying to convince others to come try out the language, but my experience with these people is that they're almost always coming at it from a place of just being excited about finding a language that works well for them and solved so many of their issues, and so they want to share that with others. ____ D is a cool language and it's a shame it seems to get ignored so much. I hope D people continue to work at it.
- xyproto 3y ago
  Julia is the only programming language that makes me annoyed when I think of it, because it was so troublesome to package for Arch Linux and because of how little they care about increasing the safety in the language (like Rust or Ada).
  - majoe 3y ago
    What made Julia so difficult to package? I'm genuinely curious. > ... because of how little they care about increasing the safety in the language (like Rust or Ada). I think it's a bit harsh to compare Julia to Rust on that front. Julia has completely different design goals. Compared to Rust's borrow checker and C++'s move semantics, Julia's immutability-by-default (+ clever compiler optimizations) gives a good trade off between performance, safety and ease of use. While Rust goes for safety + performance, Julia goes for performance + ease of use (respectively dynamicity). Nevertheless, I miss some features related to type driven development in Julia, which would improve safety: - A newtype idiom - Sum types - Explicit, type-checked interfaces : I actually would prefer something like C++20 concepts (a blacklist approach) to Rust's trait (or typeclasses, a whitelist approach), because it would be a better fit for Julia's design goals.

mratsim 3y ago

V-style hype?

seanalltogether 3y ago

Ruby is an interesting use case because the Rails framework was the hype train that pushed it into the mainstream. Also would Rust or GO have gotten as much adoption if not for the strong dependency system built right in? New languages clearly need more then just a compiler or runtime to attract developers now.

silent_cal 3y ago

It also has to be very easy to use. There are a lot of languages I won't even look at because they're not intuitive, and there's no clear reason for me to invest the time to learn them. I think developers tend to focus on "innovations" that only nerds will care about, and neglect making innovations in how easy the language is to learn, use and read. At the end of the day these features are the main factors determining whether or not a language will be adopted.

neuromanser 3y ago
https://sr.ht/~rne/dram https://sr.ht/~rne/dram was my first software in D, I don't remember having any issues with the language itself. Documentation (language and stdlib) was mostly ok, same with compiler diagnostics (watch out for long method call chains involving lambdas). I agree with the diagnosis elsewhere in the thread: D is where it is today (IOW, isn't where it could be) because of the Tango/Phobos schism and closed-source license issues from almost twenty years ago.

WalterBright 3y ago

What D has is an excellent community. Many users have told me that the D community is just the kind of community they were looking for in a programming language. For example, we don't do politics. Our forums are D only.