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).
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.
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.
I think Julia has a very bright future. There's no fundamental reason for Python to be so popular in the number crunching sector. I expect a lot of that to migrate to Julia over the next decade. Unlike D, I believe it has significant funding.
If all Python needed was a JIT, this would have been addressed over a decade ago. The problem isn't a lack of a compiler, it's language semantics that make the job of a JIT nearly impossible.
The usual urban myth, ignoring JIT work in language semantics like Smalltak, Common Lisp, SELF, where anything goes and the whole process space can change in a method call.
JIT doesn't happen in Python because the community rather rewrites code in C, than support projects like PyPy.
NVidia and Microsoft had to come into play to change this.
None of the languages you mention there get even close to C levels of performance when you hit "anything goes" dynamic language features. Those JITs are only competitive (i.e. within an order of magnitude perf) when you are accelerating very barebones code on native types and non-generic functions, or you strip out dynamism.
In julia, there is no separation between generic functions and fast functions, and no separation between user defined types and inline allocated structs.
This is not the case with Python, Smalltalk, Common Lisp, etc.
To actually take hold and stop people from relying on C libraries for everything in Python, the Python JIT is going to have to be as fast as C, and it's also going to need to have a CPython compatible ABI because people are not going to abandon all these pre-existing libraries overnight.
Python's semantics make both of those prospects incredibly dubious.
So I am lost, are talking about Python JIT compilers or C performance?
Smalltalk, Lisp and SELF were used to write complete graphical workstations, where a debugger code change or dynamic code load across the network could impact JIT decisions across the whole OS stack.
Python JIT compilers don't exist in a vacuum. If you want one to take over, it needs to be worth using. So comparing the performance of that JIT compiler to C performance is very relevant, since the goal has to be to replace code which was written in C with Python code.
At the same time though, because Python has such a tremendously big ecosystem, all written in C, and targeting specifically the CPython interpreter ABI, even if you make a JIT compiler that is as fast as C, it'd also need to support the CPython interpreter ABI, otherwise it'd never catch on because the JIT compiled implementation of the language would have to start fresh with almost no ecosystem support.
The situation is even worse if we take the realistic view that such a JIT compiler will make some serious performance compromises relative to the existing C code everywhere in the ecosystem, and the fact that the CPython interpreter ABI is so entangled with the internal implementation details that it's impossible to support in a way that's even approaching being performant.
Which goes back to the point of the community not caring about JITs, which is embodied in the way Python libraries that are thin wrappers around C code, get called as "Python" libraries.
They are as much Python as they could be Tcl.
Ironically it sufficed to Microsoft and CUDA step in, followed by Facebook as well, Guido gets out of his Python retirement, and JIT, GIL-removal are suddenly issues that matter.
That person seems to just think that so long as the JIT is kinda fast, it's good enough. But that's really not the world we live in most of the time, especially if using that JIT broke binary compatibility with existing fast libraries.
There's a gigantic graveyard littered with dozens of abanoned Python JITs, Psyco is hardly unique. The community has not at all gone down the PyPy route, nobody uses PyPy either, even if it's technically not abandoned.
There's little reason to think these new JITs will fare any better.
Python doesn't need JIT, python's strengths is "it's interpreted", therefore it runs everywhere without having to compile anything in one go, JIT is only useful for servers and long lasting processes, python doesn't fall into that category
At best it needs an AOT compiler, to accelerate final scripts, and that's where projects like Mojo start to become interesting
I think biggest Julia problem is deployment and focus on Academia/HPC, its nice language and pretty fun to write, but it seems to be not good enough to replace Python and lost tons of momentu from hype train in 2017-2018?.
Julia still have a sucess story and is a lot bigger compared to D.
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).
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.
The main problem with packaging julia is that it requires a custom version of LLVM (since LLVM ships breaking versions every 2 years and doesn't do downstream testing for projects other than Clang). Lots of linux distros have repeatedly tried shipping Julia with random LLVM versions and as a result, shipped broken Julia versions to people.
>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).
This was Rust for a decade. It was really annoying. But now we have a wonderful new language with tons of support that could legitimately challenge C++ some day. So I tend to agree.
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.
(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.
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.
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").
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.
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.
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.
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.
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?
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.
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 ```
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.
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.
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.
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.
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.
