I constantly feel like inferior languages are picked up, while superior languages are discarded. It's almost as if the universe had a law: "inferior technology is always preferred no matter how hard you seethe".
Examples:
* Python preferred over Ruby
* TypeScript preferred over Dart or even JavaScript (which is fine and, as a bonus, doesn't require compilation step like TS)
* Go is preferred over Crystal and D.
While Python, TypeScript and Go are quite alright, there is no doubt in my mind that their alternatives are absolutely superior as languages. Yes, in case of Dart, Crystal and D the ecosystem doesn't have the abundance of well-tested libraries, but as languages they are simply better. The Go argument that it's popular because it's simpler is absurd in the sense that no one really forces you to write complex code and use classes or other advanced OOP features in D.
The superior languages on your list just reflect your personal preferences. There are not perfect languages, just appropriate languages for given application.
What pains me in Python adoption, beyond its use as Perl replacement, is that we have so much better dynamic languages with advanced JIT implementations, but have to reach out writing extensions in native languages instead.
At least Python as DSL for GPU JIT compilers is a thing now.
Yes, I know about PyPy in the corner looking for attention.
> we have so much better dynamic languages with advanced JIT implementations
What are some of these better languages that you're referring to? (The usual dynamic language JITs I hear people praise are LuaJIT and Chez. And V8. And the JVM?)
Smalltalk, Self, whose research lead to Hotspot and V8, Common Lisp.
And the usual, in Python everything is dynamic, well it is even more so in an image based live coding environment, where any break into the debugger, with code changes and resume execution can come back to a complete different world.
Additionally there are features like Smalltalk become: message, where two objects can change places everywhere they are used in the image, and current execution.
Clojure could never really be a thing since it ignores the most important rule: fast startup. Because of this, and for no other reason, Clojure will always be an "also ran". It's not about competency of the people working on it. It's a solvable problem the community doesn't acknowledge exists, unless you press them on it, in which case they think "graal" and "babashka" is a valid response, and you're back to square 1.
You missed my remark about PyPy feeling abandoned on the corner, well the same applies to GraalPy.
The Ruby JITs I mentioned are used in production.
While other dynamic language comunities embrace their JITs, in Python world, outside using it as a DSL for GPGPU JITs, it is pretty much let's just keep using CPythion with C and C++ extensions. Adding a JIT to CPython only became a thing after Facebook and Microsoft decided to push for its development.
Languages do not matter as much as you think. Ecosystems are everything. Twice in my life I started companies (the first one took all my life savings) and in both cases the right call was what you called an "inferior language".
I actually liked D very much, and WB had been a personal hero of mine when I was in college. But I am not betting my career on an ecosystem built around by a single brilliant guy. For high-stakes projects, a wise decision is building on a platform with several deep-pocketed backers.
And for toy/personal projects... do you even need a language anymore? Just ask your favorite LLM to generate you an executable which does what you want (partially joking here).
D's ImportC feature makes it super easy to access C libraries from D code. That means D fits right in with a C ecosystem, as it's no longer necessary to attempt to translate the .h files into D.
It's not perfect, as some people cannot resist using the C preprocessor for some bizarre constructions.
I used to write those bizarre things myself in C, and was proud of my work. But one day I decided to remove them all, and the code was better.
One area where Go, C# and Rust beat D is packages in a few different ways.
For C# Microsoft eventually embraced NuGet their package manager, and used it to put core packages that don't need to be fully available OOTB but can then benefit from frequent updates on a per project basis as opposed to updating the entire language runtime.
For Go it was the out of the box packages, like if I want to make a website, I can pull in net/http and their templating packages that come out of the box with Go, maybe a reasonably simple core maintainer package or packages that go into Dub would be a strong selling point. Right now Vibe.d is the only option for web dev, but there's no reason a much simpler web server couldn't exist.
For Rust, I just really love Cargo, I think its one of the nicest package managers I've ever used.
The other thing that would really help D is if something significant is built around D, whether it be a framework (like what Rails did for Ruby) or some major application that needs D to function at its core and is used by many, this could be a groundbreaking modern IDE, or anything really, a database that uses the best bits and pieces of D to scale, or even a really rich cross-platform GUI stack (my kingdom for std.gui to be a thing in D, and reasonably exhaustive).
I wish I had unlimited time and money, I would invest it in D. Alas, I'm not a language maintainer, just a guy who loves really good tools.
It seems like the parent was trying to paint a situation of you being a bottleneck to success. It seems a bit Schrödinger's BFDL though.. is Linus a bottleneck to the most used server operating system? Did Guido hold back Python? The existence of the GDC and LDC compilers torpedoes toolchain concerns.. I'd be more worried about Java or Golang suffering from some eventual corporate buffoonery.
To the parent's point of startups, betting the farm on something like a particular language out of some sense of superiority might mean you are not focusing on the right problems. But if the founders happen to know a less widely used tool it doesn't seem inappropriate either. The type of employee that can drive a startup or a big tech project forward is not going to be thwarted by a language, and they might find something new to learn fun.
D can do C++ interop when the C++ code is "C with classes" style. Some templates are supported. But then things get so complicated with C++ that it's impractical to go further.
... and the job of a programmer will be to explain, in as precise terms as possible, what they need the executable to do. (Reminds me of the idea of programming based on a natural language.)
Dart is much worse than TypeScript. The over-reliance on codegen for the most simple things (e.g. https://pub.dev/packages/freezed#primary-constructors), the lack of expressiveness of the type system (it only got sum types very recently), and a lot of other little annoyances are ever present when having to write Dart.
It's quite subjective what you consider to be better. Is Ruby better than Python? Maybe so, but Ruby only ever had one killer app that is Rails while Python has a vast ecosystem. Is Crystal better than Go? Maybe so, but Go ist just so much more mature (plus the ecosystem argument).
Regarding ruby and python I thought the 2 were in the same league, esp compared to perl. Over 20 years ago I evaluated both and went ruby because of the more consistent api and of course pythons forced whitespace is an easy tie breaker against it. At this point I'm not to pleased that many younger programmers that python as some sort of default and tend to end up writing far too fancy code in it when it ends up being the wrong tool.
> The Go argument that it's popular because it's simpler is absurd in the sense that no one really forces you to write complex code and use classes or other advanced OOP features in D.
The same argument applies to C++. No one is forcing you to create complex nested templates or other difficult features.
Yet many criticisms to the language are in the form: "But it is possible to write very complex code that no one understands!"
Its really calming that Haxe is not moving as fast as the JS/TS ecosystem. You upgrade once every 3-4 years. Everything just usually "works"
We use Haxe for PHP and its really a secret hidden superpower, im amazed people dont know about / use.
Its mostly marketing, i guess. But i wish more devs tried it as an alternative to PHP or TypeScript, as the language is WAY better in almost every way.
yeah, I know it's alive :) but I was hoping it would be one of the standard recommendations for javascript devs to reach for when they wanted a better type system. (I was also sad that it never developed a good option for desktop apps, the language itself was very pleasant to use but the ecosystem seemed very focused on game dev the couple of times I tried it)
... Perhaps what you're describing is having a niche opinion. If you had some opinions, like a preference for "Everything must be done in as many ways as possible with funky characters" or "I hate indentation", it would certainly seem that the world is against you. But, perhaps, you just really smart and can remember the intention of all the complicated code you wrote a year ago, so you don't even need to write comments, and thats great. However, being special does not mean that some technolgoy is objectively inferior, unless you can actually come up with a provably objective metric.
Overall, the technology that is there, solving most of the problems for most of the cases is the technology that is superior, by the law of the universe, not the other way around.
I don't agree with any of your examples, but I have my own, like Pascal is a better language than C, by many metrics. I can also accept that C, is what people who invented unix, also invented. And that makes Pascal inferior to C, now, as choice for any project that requires that you hire embedded software developers. That's what the universe decided.
> "Everything must be done in as many ways as possible with funky characters"
Are you sure you're not talking about Perl here? Because there are very few "funky characters" in Ruby and code written in it tends to be very readable, more so than Python in many cases.
I agree with OP. While Python is not a bad language, Ruby is a better language in general, and I'm reminded of it every time I have to work in Python (which is pretty often nowadays, due to Python's dominance in ML ).
I can give many examples as to why, but here's a quick toy example to show off the difference in philosophy between Ruby and Python. You have a list of numbers, you want to keep only odd numbers, sort them, and convert them to a string where each number is separated by comma. Here's the Ruby code:
xs = [12, 3, 5, 8, 7, 10, 1, 4]
ys = [x for x in xs if x % 2 != 0]
ys.sort()
ys = ", ".join(str(y) for y in ys)
Or alternatively in a single line (but in more complex cases this gets extremely unwieldy since, unlike Ruby, Python forces you to nest these, so you can't write nice pipelines that read top-to-bottom and left-to-right):
xs = [12, 3, 5, 8, 7, 10, 1, 4]
ys = ", ".join(str(y) for y in sorted(x for x in xs if x % 2 != 0))
And this matches my experience pretty well. Things I can do in Ruby in one line usually take two or three lines in Python, are more awkward to write and are less readable.
To a beginner who is used to ordinary imperative languages, that Ruby line is extremely difficult to understand. Is `.filter` a method or a property of `xs`? Is `{ |x| x.odd? }` an argument to a method or just a statement that comes after `xs.filter`? If it is passed to `.filter`, why does it not have parentheses around it but the `", "` passed to `join` does?
This all makes sense to a person who knows the language a lot, but wrinkles the brain of a newcomer. Too many concepts to juggle in order to understand. On the other hand, the Python one reads quite easily, even if you may have to go right to left.
Python seems to be the odd one out. Imo, its list comprehensions are confusing as hell to "newcomers". For example, when a list comprehension has multiple `for`s, what order are they nested in?
Those both seem a little bit more consistent than the Ruby example, however. To understand the JS example for example, you only need know that to call a method on an object, you do `object.method(arguments)`, and this is chained in a straightforward manner, with methods called on the returned values left to right. Ditto for the Haskell example. Maybe the Ruby one does the same thing, but even in this extremely simple example, we still have two different ways of doing the same thing.
For Python, you don't really have to use list comprehensions in the place of multiple for loops, you can sacrifice the brevity afforded to write the same thing in a more easily understandable fashion.
> ... confusing as hell to "newcomers". For example, when a list comprehension has multiple `for`s, what order are they nested in?
I get that this is just a rhetorical question to make a point about newcomers, and I do agree it's not immediately obvious, but for the record: you can imagine any "if"s and "for"s in a list comprehension are nested statements in the same order. So, for example, this:
l = [
y.foo()
for x in my_list
if x.blah() > 7
for y in x.ys()
]
Is equivalent to this:
l = []
for x in my_list:
if x.blah() > 7:
for y in x.ys():
l.append(y.foo())
So the least comprehension is basically in left to right order with the one exception of the actual expression to be added to the list (like y.foo() in the example above).
Yeah, I know, I know. But I imagine many people would mentally want to bracket [e for x in xs for y in ys] like [(e for x in xs) for y in ys] and thus conclude that y is the outer loop.
>Python seems to be the odd one out. Imo, its list comprehensions are confusing as hell to "newcomers". For example, when a list comprehension has multiple `for`s, what order are they nested in?
The order is mentioned right in the docs, for Python 3:
>Note how the order of the for and if statements is the same in both these snippets.
And it is mentioned even more clearly in corresponding section in the Python 2 docs - last I checked, years ago,
Update: IOW, the nested list comprehension syntax is confusing only to newcomers or even experienced devs who are lazy or stupid enough to not read the docs for the language feature they want to use, before using it, IOW, "winging it", whether to try to seem cool or due to peer pressure or other reasons, all of which are stupid ones, even in the short term, because the cost is higher than the benefit in most cases.
The only difficulty in Ruby code is the block notation. Even then, it is very similar to constructs in JavaScript, Go, D and a number of other languages -- the only difference form JS would be that instead of `(x) => ...` you write `{ |x| ... }`.
Questions such as
> why does it not have parentheses around it but the `", "` passed to `join` does?
would be exactly the same for JavaScript, Go or D. Ruby has the best syntax with regards to blocks/lambdas/closures.
I don't know much Ruby outside of a few toy examples I wrote a long time ago. For most languages, there would be parentheses around objects you pass to functions, like `.filter({|x| x.odd? })`. This lends some consistency and makes it easy (for me at least) to understand that an anonymous function is passed to `filter`. Just separating it using spaces feels like Bash, something I find difficult to write anything slightly complicated in.
> To a beginner who is used to ordinary imperative languages, that Ruby line is extremely difficult to understand.
I don't understand this argument. You are a beginner only for a tiny fraction of your time using a given programming language. Why are we optimizing a programming language for people who don't know it, instead of optimizing it for people who actually program in it?
> Why are we optimizing a programming language for people who don't know it, instead of optimizing it for people who actually program in it?
Everyone who actually programs in a language was once a person who didn't know it. Languages which optimize for succinct terseness might be powerful once you master them, but they will never enter mainstream use, which I guess is not necessarily the aim.
Ruby is in the running, so to speak, so of course that means there are thousands of people who agree with you. I'm not one of them. The fact that Ruby did not take of as much as Python did, even though there was all that RnR hype, is a testament to that. I don't think your examples are readable. What is |x| x.odd? ? (question mark pun intended) This is just "cleverness". I, personally, want my programming language to use method to use a keyword like "is" instead of operand?[question mark operator]
Your critique rests heavily on a small part of the language and specificaly the odd? trick. Python has filter available as well, but you did not use it:
ys = sorted(x for x in xs if x % 2)
# vs
ys = sorted(filter(lambda x: x % 2, xs))
ys = ", ".join(str(y) for y in ys)
I find Python a better language in total, more regular and readable, when one-liners are avoided (though "".join() is not my favorite). I do however like shell and gleam style pipelines, a bit more than fluent style.
Having coffee almost 30 years in c++ I really good tired of the complexity of it. Some of the newer complexity being workarounds for (in retrospect) poor decisions made decades ago. Build system situation never helped, and I still despise cmake. When D came out I was interested but garbage collection immediately turned me off, in my opinion the boost shared pointers (later adopted into the standard) solved and shut the door on memory leaks as a serious issue.
And then the d2 fiasco sort of blew it all up. Doesn't help that the language always felt very heavy to me. Likewise Rust feels heavy and cumbersome itself.
So it ends up that I'm another one of those who feels the itch getting scratched by zig.
Currently I'm working on adding an AArch64 code generator to the venerable dmd D compiler. It's fun as it's completely differernt from the X86_64. In some ways very clever and in some ways completely wacky.
D deserves more recognition. It's a cool language under the radar for too long. I wish a major corporation backed it. I had a great time learning D. Also I admire Walter Bright If I could achieve even a fraction of his productivity, that would be awesome.
Sincere question, not meant to be a shallow dismissal: Where is D a better choice than C++? In what aspects is it enough of an improvement over C++ to justify using a niche language?
Programming in D after C++ is like the opposite of death by 1000 cuts - its just a constant stream of finding nice little things that simplify your life or avoid footguns. You become accustomed to all the niceties very fast and its hard to justify going back haha.
D is by no means perfect (and over the years it has accumulated lots of warts) but if you know what you are doing it enables amazing productivity and almost never gets in your way. If you have an idea about solving a problem in a particular way there's almost always a path available to do just that without running into "computer says no" situations (stares at Go).
D is technically better than C++ in most features. (It has always lead C++. For example, among about 100 new feauters that C++11 brought, only 2 were not already in D. No C++ designer will ever admit this fact.)
D is safer and more productive. It's a joy to write in D because most of the time it feels like whatever you think, you code. This is unlike C++ where you fight the language all the time. C++ is not a productive programming language. I say this with experience: I coded in C++ as an "expert" for many many years, including these last couple of years. It's not fun to write in C++, which translates to another kind of loss of productivity.
C++ is a burden and liability for companies but no CTO will be blamed for chosing it because it's popular. I can list so many popular things and persons that worth nothing but I will refrain from getting political.
Yes, on paper, there are way more C++ programmers out there than D programmers. But I interview these C++ programmers occasionally. Most of them don't even have an inkling that they don't know C++ at all.
How about engineering with C++? That is such a difficult task. I went over header file hygiene with a colleague a couple of months ago. The number of points that you should pay attention to is mind boggling: Don't #include unnecessarily, do forward declare as much as possible (but what can be forward declared is hard to understand even for experienced programmers), #include your own API header first to prove that it's complete (and good luck!), don't forget header guards, don't reuse header guards, etc. etc. This is just efficient header file usage! We haven't started coding yet!
My friends, the emperor doesn't have clothes. C++ simply is not a tool that is designed well. People who choose it do so because they have to or they are masochists. (True story: I asked a relatively young Google meetup presenter once why he was using C++ instead of a modern language and he said "because it is hard".) C++ separates the elite from the masses; I used to strive to be a C++ elite; I am not interested a bit anymore; I want to write useful programs with D; and I do.
D is niche only because humans are populists. We are not encouraged to use tools (or products) that are designed better. We follow popular leaders. It takes one some time to find his or her own voice to reject bad products and use only good ones. I am extremely lucky to work for a company that allows me to use D to write useful products.
I still take the same joy from programming that I did when I first learned it.
Then there is the human aspect of it: I want to be associated with real people isntead of snobby elites. (Remember how C++ was marketed at around 2000? "Yes, C++ is hard but it was never meant to be for normal programmers anyway." Ha ha ha! I am old enough now to reject that mentality. Bad design is bad design my friends; you can't defend it by blaming the user for not being elite.)
I can go on and on...
Now it's my turn to ask: Why would anyone choose C++ for their projects despite the production costs that it brings? None of your programmers really know it; they introduce hidden liabilities in the projects, their source code become non-refactorable monsters. Why waste that money on C++ when you can produce products easily. Products that just work...
> Why would anyone choose C++ for their projects despite the production costs that it brings?
Familiarity, and all the libraries and tools available for C++. I see that D has a section on C++ interop,[0] but it looks about as painful as FFI usually is, and even more painful given how template-heavy C++ code tends to be.
(Completely unrelated: I can't mention FFI without also mentioning how amazing LuaJIT's C FFI is. The developer(s) really nailed it.)
I actually don’t think C++98 was that bad or complex. Yes nobody knew how to use it and wrote Java instead, but I think the hate comes from having code spanning so many different features and idioms that also require a compiler expert to understand.
Slightly off topic:
Is D a good language for creating tiny windows or Linux executables?
There is an upcoming game jam (4mb jam 2025) which gives extra points for game submissions <= 8KB.
With c you can fit a window with graphics update in an executable of less than 900 bytes[0]. Granted it's using crinkler for linking which does some compression.
Instead of being an ass, maybe you can take the time to educate me why you think I'm wrong?
I think that at least the garbage collection not being available qualifies my statement as somewhat being true. For game development, as it's closer to what grand-parent asked, classes not being usable would also be an issue...
For game development? I imagine having to use only structs but not classes would be something that forces a "non idiomatic D" experience. Dynamic arrays sound like something that's very useful for a game. I don't know, there are plenty of features that are incompatible with better C that makes D, D. Generally speaking, garbage collection would be the biggest in my opinion.
I fully agree with you, but I think that if you present it as an option to somebody you should write a line or two about the potential downsides, so they have a better picture. Sorry if I was too abrupt in my criticism of your post. :)
Just to add, I learned D in a day and finished most of project euler without needing to look up the manual. D is more "python" than python in that it makes coding very.
IMHO, Zig is the closest thing to being D-esk (like with comptime), but it's still not a mainstream option yet.
Yes, UVU. And also yes. If I find myself needing something low-level and performant, I have a hard time justifying the ramp-up time required to use D since there is a near zero chance I would use it in my current or future employment. While that isn't always how I decide what technologies to use in my personal time, it definitely is a factor that tips the scales towards a more mainstream language
It's been about 10 years since I last dipped my toes in the D waters.
At the time (v 2.067) I stumbled across some surprisingly bad warts in the standard library that prevented me from using it for my intended purposes which writing software tools for bioinformatics.
As other posters have noted, language elegance is secondary to the ecosystem when you want to get things done.
For anyone who has been using D for an extended period, has the D ecosystem improved / expanded considerably in the last 5-10 years?
I recently read almost the whole book in a week or so. It's excellent and I feel like I can write in D pretty well after reading it. Too bad that I most likely won't be writing in D, but, at least, I'm confident I can come back to it anytime and be up to speed if I ever need to. This book should be the goto for anyone who wishes to quickly learn the language.
Been a heavy user of the language since 2013. This book was very helpful at the time. I don't think it was a book at that time, though, more a lengthy collection of notes as I recall.
Really wanted to like Dlang but I just did not have a good time with it.
One of my projects has a really simple server written in nodejs that's basically (in terms of complexity) just an auth'd chatroom, and I wanted to switch it from using raw tcp sockets to websockets. And since the server is so simple, why not refactor it to another language and see if there's no some performance gains from that? I ended up doing something pretty similar to that "Comparing 10 programming languages. I built the same app in all of them." video from Tom Delalande (https://www.youtube.com/watch?v=-MbTj8DGOP0). I had several working versions of the server in:
And Dlang was, by far, the worst experience out of the lot. Firstly is the lack of adequate, comprehensive, and centralised tooling. I almost gave up when dmd could not even compile a freshly init'd project. The impression I got is that you're not really meant to use dmd directly, you're meant to use dub, like how you compile Java projects with Maven/Gradle, not javac. Except that there's also apparently three competing compilers (https://wiki.dlang.org/Compilers)? And good luck remembering the names of the tooling because they're all some random three-letter combination.
Serverino makes heavy use of mixins and attributes (think Java annotations), which is not ideal. But what really killed the deal was (despite using the recommended intellij plugin (https://wiki.dlang.org/IDEs) with the recommended tools installed and setup) not being able to inspect[1] serverino's mixin or its attributes. So I look at serverino's source code, except its source also has mixins... which I can't inspect. I'm not going to use something when I cannot easily ascertain its control flow. And while, yes, I probably should have gone with vibe-d (https://code.dlang.org/packages/vibe-d%3Ahttp) in the first place, mixins and attributes are nonetheless part of the language and the tooling should be able to tell me about them.
- [1] When I say "inspect" I mean requesting the IDE to show me the source/definition so I can see what it is, what it does, and where it's known to be used.
I found the lack of mature tooling to be hugely problematic. The Visual D extension always felt flimsy and unreliable when debugging D.
DUB also exhibits weird behavior. For example, I wanted it to produce separate debug and release binaries, which it won't do out of the box. Instead, it'll create the same binary for both configurations. Changing that behavior was more difficult than it needed to be. Maybe it's changed since then, but I didn't have a pleasurable experience.
> And Dlang was, by far, the worst experience out of the lot. Firstly is the lack of adequate, comprehensive, and centralised tooling. I almost gave up when dmd could not even compile a freshly init'd project.
Yep this also happened to me when I tried D. I love the idea of the language and the syntax is great, but I really don't want to fight my tools when I'm working on a project.
Oh the issue isn't with serverino itself but with the lack of tooling-support for the language features that serverino makes heavy use of. And while serverino is open source, so one can ultimately view its source code, not having access to modern IDE type inspection adds a lot of unnecessary friction.
Might seem silly, but the choice just came from looking at (https://code.dlang.org/search?q=websockets) and seeing that serverino is the only one maintained. vibe-d isn't listed there, I only learned about that later. Basically, serverino has good SEO.
Well, you might have searched for GitHub or got there from some page where serverino was mentioned (forum, ...) or maybe someone suggested it to you in the community. Once a program of mine was mentioned in a telegram channel and I started seeing a lot of stars on github and I didn't understand why.
It's a tossup between Dart and Bun: Dart has better language features but Bun has better APIs. Since Bun is first and foremost a Javascript runtime, it inherits its annoyances and issues, like the complete lack of pattern matching, or switch expressions at all, or decent enums, etc. That said, Bun includes SQLite support and encryption out of the box, whereas Dart is heavily compartmentalised (https://pub.dev/publishers/dart.dev/packages). Imagine if, in Bun, importing "node:crypto" meant needing a "node:crypto" npm dependency. Dart ekes out the win though, I think.
> Most Rust programmers don't invoke rustc directly, but instead do it through Cargo. It's all in service of rustc though! If you want to see how Cargo calls rustc, you can
I constantly feel like inferior languages are picked up, while superior languages are discarded. It's almost as if the universe had a law: "inferior technology is always preferred no matter how hard you seethe".
Examples:
While Python, TypeScript and Go are quite alright, there is no doubt in my mind that their alternatives are absolutely superior as languages. Yes, in case of Dart, Crystal and D the ecosystem doesn't have the abundance of well-tested libraries, but as languages they are simply better. The Go argument that it's popular because it's simpler is absurd in the sense that no one really forces you to write complex code and use classes or other advanced OOP features in D.The superior languages on your list just reflect your personal preferences. There are not perfect languages, just appropriate languages for given application.
What pains me in Python adoption, beyond its use as Perl replacement, is that we have so much better dynamic languages with advanced JIT implementations, but have to reach out writing extensions in native languages instead.
At least Python as DSL for GPU JIT compilers is a thing now.
Yes, I know about PyPy in the corner looking for attention.
> we have so much better dynamic languages with advanced JIT implementations
What are some of these better languages that you're referring to? (The usual dynamic language JITs I hear people praise are LuaJIT and Chez. And V8. And the JVM?)
Smalltalk, Self, whose research lead to Hotspot and V8, Common Lisp.
And the usual, in Python everything is dynamic, well it is even more so in an image based live coding environment, where any break into the debugger, with code changes and resume execution can come back to a complete different world.
Additionally there are features like Smalltalk become: message, where two objects can change places everywhere they are used in the image, and current execution.
I'd suggest F#, Clojure, Elixir, Scala, and TS, if that counts.
Clojure could never really be a thing since it ignores the most important rule: fast startup. Because of this, and for no other reason, Clojure will always be an "also ran". It's not about competency of the people working on it. It's a solvable problem the community doesn't acknowledge exists, unless you press them on it, in which case they think "graal" and "babashka" is a valid response, and you're back to square 1.
Even Ruby has JIT now
True! But pjmlp was referring specifically to advanced JIT implementations, so I wondered which JITs he was referring to as advanced.
In Ruby's case that would be RubyMotion, TruffleRubby and JRuby.
That trace back to Apple's efforts with MacRuby, or Sun's (for a while Netbeans even had Ruby support).
If you go that route, GraalPy is there too, so the argument is not as strong as it seems.
You missed my remark about PyPy feeling abandoned on the corner, well the same applies to GraalPy.
The Ruby JITs I mentioned are used in production.
While other dynamic language comunities embrace their JITs, in Python world, outside using it as a DSL for GPGPU JITs, it is pretty much let's just keep using CPythion with C and C++ extensions. Adding a JIT to CPython only became a thing after Facebook and Microsoft decided to push for its development.
Languages do not matter as much as you think. Ecosystems are everything. Twice in my life I started companies (the first one took all my life savings) and in both cases the right call was what you called an "inferior language".
I actually liked D very much, and WB had been a personal hero of mine when I was in college. But I am not betting my career on an ecosystem built around by a single brilliant guy. For high-stakes projects, a wise decision is building on a platform with several deep-pocketed backers.
And for toy/personal projects... do you even need a language anymore? Just ask your favorite LLM to generate you an executable which does what you want (partially joking here).
D's ImportC feature makes it super easy to access C libraries from D code. That means D fits right in with a C ecosystem, as it's no longer necessary to attempt to translate the .h files into D.
It's not perfect, as some people cannot resist using the C preprocessor for some bizarre constructions.
I used to write those bizarre things myself in C, and was proud of my work. But one day I decided to remove them all, and the code was better.
One area where Go, C# and Rust beat D is packages in a few different ways.
For C# Microsoft eventually embraced NuGet their package manager, and used it to put core packages that don't need to be fully available OOTB but can then benefit from frequent updates on a per project basis as opposed to updating the entire language runtime.
For Go it was the out of the box packages, like if I want to make a website, I can pull in net/http and their templating packages that come out of the box with Go, maybe a reasonably simple core maintainer package or packages that go into Dub would be a strong selling point. Right now Vibe.d is the only option for web dev, but there's no reason a much simpler web server couldn't exist.
For Rust, I just really love Cargo, I think its one of the nicest package managers I've ever used.
The other thing that would really help D is if something significant is built around D, whether it be a framework (like what Rails did for Ruby) or some major application that needs D to function at its core and is used by many, this could be a groundbreaking modern IDE, or anything really, a database that uses the best bits and pieces of D to scale, or even a really rich cross-platform GUI stack (my kingdom for std.gui to be a thing in D, and reasonably exhaustive).
I wish I had unlimited time and money, I would invest it in D. Alas, I'm not a language maintainer, just a guy who loves really good tools.
It seems like the parent was trying to paint a situation of you being a bottleneck to success. It seems a bit Schrödinger's BFDL though.. is Linus a bottleneck to the most used server operating system? Did Guido hold back Python? The existence of the GDC and LDC compilers torpedoes toolchain concerns.. I'd be more worried about Java or Golang suffering from some eventual corporate buffoonery.
To the parent's point of startups, betting the farm on something like a particular language out of some sense of superiority might mean you are not focusing on the right problems. But if the founders happen to know a less widely used tool it doesn't seem inappropriate either. The type of employee that can drive a startup or a big tech project forward is not going to be thwarted by a language, and they might find something new to learn fun.
Any plans to implement Swift like C++ interop?
D can do C++ interop when the C++ code is "C with classes" style. Some templates are supported. But then things get so complicated with C++ that it's impractical to go further.
It would be great if D supported something like OpenAPI generator https://github.com/OpenAPITools/openapi-generator
Maybe it exists and I am just ignorant but it doesn't seem to be in the list of supported languages.
I belive asking the favorite LLM to generate an executable will be the future, just like high level languages drove Assembly development into a niche.
Yes it isn't here today, just like it took several decades for optimizing compiler backends to do a very good job.
In fact one of the reasons why Matt Goldbolt created Compiler Explorer was to have a way to settle arguments he was having in the games industry.
> LLM to generate an executable
... and the job of a programmer will be to explain, in as precise terms as possible, what they need the executable to do. (Reminds me of the idea of programming based on a natural language.)
Grace Hopper would find the future of programming so ironic.
Dart is much worse than TypeScript. The over-reliance on codegen for the most simple things (e.g. https://pub.dev/packages/freezed#primary-constructors), the lack of expressiveness of the type system (it only got sum types very recently), and a lot of other little annoyances are ever present when having to write Dart.
> Python preferred over Ruby
Python's syntax is closer to written human language, and it uses more obvious words.
> TypeScript preferred over Dart or even JavaScript
Typescript is a strict superset of JavaScript.
> Go is preferred over Crystal and D
Go is backed by a big Corp
It's quite subjective what you consider to be better. Is Ruby better than Python? Maybe so, but Ruby only ever had one killer app that is Rails while Python has a vast ecosystem. Is Crystal better than Go? Maybe so, but Go ist just so much more mature (plus the ecosystem argument).
Regarding ruby and python I thought the 2 were in the same league, esp compared to perl. Over 20 years ago I evaluated both and went ruby because of the more consistent api and of course pythons forced whitespace is an easy tie breaker against it. At this point I'm not to pleased that many younger programmers that python as some sort of default and tend to end up writing far too fancy code in it when it ends up being the wrong tool.
Performance matters (as long as most other things are the same).
Python won over Ruby because of performance. Ruby is easily the slowest of all mainstream languages.
It's scary to not have type checks in JavaScript. I do them by eyeballing the code, but ugh.
Also all languages you mentioned support complex code and OOP.
Code can be complex in any language. TypeScript itself can produce some really complex types. OOP isn’t a bad thing either; it’s just a tool.
https://en.wikipedia.org/wiki/Worse_is_better
> The Go argument that it's popular because it's simpler is absurd in the sense that no one really forces you to write complex code and use classes or other advanced OOP features in D.
The same argument applies to C++. No one is forcing you to create complex nested templates or other difficult features.
Yet many criticisms to the language are in the form: "But it is possible to write very complex code that no one understands!"
It is absurd.
speaking of typescript and dart, the language i was really rooting for in that niche was haxe. wish it had gotten more mainstream.
Haxe is still alive!
The devs are working on 5.0 as we speak!
Its really calming that Haxe is not moving as fast as the JS/TS ecosystem. You upgrade once every 3-4 years. Everything just usually "works"
We use Haxe for PHP and its really a secret hidden superpower, im amazed people dont know about / use.
Its mostly marketing, i guess. But i wish more devs tried it as an alternative to PHP or TypeScript, as the language is WAY better in almost every way.
yeah, I know it's alive :) but I was hoping it would be one of the standard recommendations for javascript devs to reach for when they wanted a better type system. (I was also sad that it never developed a good option for desktop apps, the language itself was very pleasant to use but the ecosystem seemed very focused on game dev the couple of times I tried it)
> Python preferred over Ruby
... Perhaps what you're describing is having a niche opinion. If you had some opinions, like a preference for "Everything must be done in as many ways as possible with funky characters" or "I hate indentation", it would certainly seem that the world is against you. But, perhaps, you just really smart and can remember the intention of all the complicated code you wrote a year ago, so you don't even need to write comments, and thats great. However, being special does not mean that some technolgoy is objectively inferior, unless you can actually come up with a provably objective metric.
Overall, the technology that is there, solving most of the problems for most of the cases is the technology that is superior, by the law of the universe, not the other way around.
I don't agree with any of your examples, but I have my own, like Pascal is a better language than C, by many metrics. I can also accept that C, is what people who invented unix, also invented. And that makes Pascal inferior to C, now, as choice for any project that requires that you hire embedded software developers. That's what the universe decided.
> "Everything must be done in as many ways as possible with funky characters"
Are you sure you're not talking about Perl here? Because there are very few "funky characters" in Ruby and code written in it tends to be very readable, more so than Python in many cases.
I agree with OP. While Python is not a bad language, Ruby is a better language in general, and I'm reminded of it every time I have to work in Python (which is pretty often nowadays, due to Python's dominance in ML ).
I can give many examples as to why, but here's a quick toy example to show off the difference in philosophy between Ruby and Python. You have a list of numbers, you want to keep only odd numbers, sort them, and convert them to a string where each number is separated by comma. Here's the Ruby code:
Now let's do the same in Python: Or alternatively in a single line (but in more complex cases this gets extremely unwieldy since, unlike Ruby, Python forces you to nest these, so you can't write nice pipelines that read top-to-bottom and left-to-right): And this matches my experience pretty well. Things I can do in Ruby in one line usually take two or three lines in Python, are more awkward to write and are less readable.To a beginner who is used to ordinary imperative languages, that Ruby line is extremely difficult to understand. Is `.filter` a method or a property of `xs`? Is `{ |x| x.odd? }` an argument to a method or just a statement that comes after `xs.filter`? If it is passed to `.filter`, why does it not have parentheses around it but the `", "` passed to `join` does?
This all makes sense to a person who knows the language a lot, but wrinkles the brain of a newcomer. Too many concepts to juggle in order to understand. On the other hand, the Python one reads quite easily, even if you may have to go right to left.
The Ruby syntax doesn't seem that different to many other languages. For example:
Python seems to be the odd one out. Imo, its list comprehensions are confusing as hell to "newcomers". For example, when a list comprehension has multiple `for`s, what order are they nested in?Those both seem a little bit more consistent than the Ruby example, however. To understand the JS example for example, you only need know that to call a method on an object, you do `object.method(arguments)`, and this is chained in a straightforward manner, with methods called on the returned values left to right. Ditto for the Haskell example. Maybe the Ruby one does the same thing, but even in this extremely simple example, we still have two different ways of doing the same thing.
For Python, you don't really have to use list comprehensions in the place of multiple for loops, you can sacrifice the brevity afforded to write the same thing in a more easily understandable fashion.
> ... confusing as hell to "newcomers". For example, when a list comprehension has multiple `for`s, what order are they nested in?
I get that this is just a rhetorical question to make a point about newcomers, and I do agree it's not immediately obvious, but for the record: you can imagine any "if"s and "for"s in a list comprehension are nested statements in the same order. So, for example, this:
Is equivalent to this: So the least comprehension is basically in left to right order with the one exception of the actual expression to be added to the list (like y.foo() in the example above).Yeah, I know, I know. But I imagine many people would mentally want to bracket [e for x in xs for y in ys] like [(e for x in xs) for y in ys] and thus conclude that y is the outer loop.
[flagged]
>Python seems to be the odd one out. Imo, its list comprehensions are confusing as hell to "newcomers". For example, when a list comprehension has multiple `for`s, what order are they nested in?
The order is mentioned right in the docs, for Python 3:
https://docs.python.org/3/tutorial/datastructures.html#list-...
>Note how the order of the for and if statements is the same in both these snippets.
And it is mentioned even more clearly in corresponding section in the Python 2 docs - last I checked, years ago,
Update: IOW, the nested list comprehension syntax is confusing only to newcomers or even experienced devs who are lazy or stupid enough to not read the docs for the language feature they want to use, before using it, IOW, "winging it", whether to try to seem cool or due to peer pressure or other reasons, all of which are stupid ones, even in the short term, because the cost is higher than the benefit in most cases.
"RTFM" could excuse literally any syntax decision in any language.
The hostility in your response to "lazy or stupid" devs is really funny given what a bad response it is.
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
The only difficulty in Ruby code is the block notation. Even then, it is very similar to constructs in JavaScript, Go, D and a number of other languages -- the only difference form JS would be that instead of `(x) => ...` you write `{ |x| ... }`.
Questions such as
> why does it not have parentheses around it but the `", "` passed to `join` does?
would be exactly the same for JavaScript, Go or D. Ruby has the best syntax with regards to blocks/lambdas/closures.
I don't know much Ruby outside of a few toy examples I wrote a long time ago. For most languages, there would be parentheses around objects you pass to functions, like `.filter({|x| x.odd? })`. This lends some consistency and makes it easy (for me at least) to understand that an anonymous function is passed to `filter`. Just separating it using spaces feels like Bash, something I find difficult to write anything slightly complicated in.
Lua, Haskell, ML, plenty of other languages where one-argument functions don't need parentheses. I think it makes a lot of code more readable.
All not-exactly-popular languages.
Maybe relative to juggernauts like C or Java. But Lua is pretty widely used.
Kotlin too
> Ruby has the best syntax with regards to blocks/lambdas/closures.
A bit of Smalltalk shining through Ruby.
> To a beginner who is used to ordinary imperative languages, that Ruby line is extremely difficult to understand.
I don't understand this argument. You are a beginner only for a tiny fraction of your time using a given programming language. Why are we optimizing a programming language for people who don't know it, instead of optimizing it for people who actually program in it?
> Why are we optimizing a programming language for people who don't know it, instead of optimizing it for people who actually program in it?
Everyone who actually programs in a language was once a person who didn't know it. Languages which optimize for succinct terseness might be powerful once you master them, but they will never enter mainstream use, which I guess is not necessarily the aim.
Ruby is in the running, so to speak, so of course that means there are thousands of people who agree with you. I'm not one of them. The fact that Ruby did not take of as much as Python did, even though there was all that RnR hype, is a testament to that. I don't think your examples are readable. What is |x| x.odd? ? (question mark pun intended) This is just "cleverness". I, personally, want my programming language to use method to use a keyword like "is" instead of operand?[question mark operator]
Your critique rests heavily on a small part of the language and specificaly the odd? trick. Python has filter available as well, but you did not use it:
I find Python a better language in total, more regular and readable, when one-liners are avoided (though "".join() is not my favorite). I do however like shell and gleam style pipelines, a bit more than fluent style.On what planet is JS better than TS. You ever work with JS?
Having coffee almost 30 years in c++ I really good tired of the complexity of it. Some of the newer complexity being workarounds for (in retrospect) poor decisions made decades ago. Build system situation never helped, and I still despise cmake. When D came out I was interested but garbage collection immediately turned me off, in my opinion the boost shared pointers (later adopted into the standard) solved and shut the door on memory leaks as a serious issue.
And then the d2 fiasco sort of blew it all up. Doesn't help that the language always felt very heavy to me. Likewise Rust feels heavy and cumbersome itself.
So it ends up that I'm another one of those who feels the itch getting scratched by zig.
> When D came out I was interested but garbage collection immediately turned me off,
Only a small amount of D uses the garbage collector. It's quite easy to write D code that doesn't use it.
> in my opinion the boost shared pointers (later adopted into the standard) solved and shut the door on memory leaks as a serious issue.
Reference counting is slow and memory intensive.
Currently I'm working on adding an AArch64 code generator to the venerable dmd D compiler. It's fun as it's completely differernt from the X86_64. In some ways very clever and in some ways completely wacky.
D deserves more recognition. It's a cool language under the radar for too long. I wish a major corporation backed it. I had a great time learning D. Also I admire Walter Bright If I could achieve even a fraction of his productivity, that would be awesome.
Sincere question, not meant to be a shallow dismissal: Where is D a better choice than C++? In what aspects is it enough of an improvement over C++ to justify using a niche language?
Programming in D after C++ is like the opposite of death by 1000 cuts - its just a constant stream of finding nice little things that simplify your life or avoid footguns. You become accustomed to all the niceties very fast and its hard to justify going back haha.
D is by no means perfect (and over the years it has accumulated lots of warts) but if you know what you are doing it enables amazing productivity and almost never gets in your way. If you have an idea about solving a problem in a particular way there's almost always a path available to do just that without running into "computer says no" situations (stares at Go).
D is technically better than C++ in most features. (It has always lead C++. For example, among about 100 new feauters that C++11 brought, only 2 were not already in D. No C++ designer will ever admit this fact.)
D is safer and more productive. It's a joy to write in D because most of the time it feels like whatever you think, you code. This is unlike C++ where you fight the language all the time. C++ is not a productive programming language. I say this with experience: I coded in C++ as an "expert" for many many years, including these last couple of years. It's not fun to write in C++, which translates to another kind of loss of productivity.
C++ is a burden and liability for companies but no CTO will be blamed for chosing it because it's popular. I can list so many popular things and persons that worth nothing but I will refrain from getting political.
Yes, on paper, there are way more C++ programmers out there than D programmers. But I interview these C++ programmers occasionally. Most of them don't even have an inkling that they don't know C++ at all.
How about engineering with C++? That is such a difficult task. I went over header file hygiene with a colleague a couple of months ago. The number of points that you should pay attention to is mind boggling: Don't #include unnecessarily, do forward declare as much as possible (but what can be forward declared is hard to understand even for experienced programmers), #include your own API header first to prove that it's complete (and good luck!), don't forget header guards, don't reuse header guards, etc. etc. This is just efficient header file usage! We haven't started coding yet!
My friends, the emperor doesn't have clothes. C++ simply is not a tool that is designed well. People who choose it do so because they have to or they are masochists. (True story: I asked a relatively young Google meetup presenter once why he was using C++ instead of a modern language and he said "because it is hard".) C++ separates the elite from the masses; I used to strive to be a C++ elite; I am not interested a bit anymore; I want to write useful programs with D; and I do.
D is niche only because humans are populists. We are not encouraged to use tools (or products) that are designed better. We follow popular leaders. It takes one some time to find his or her own voice to reject bad products and use only good ones. I am extremely lucky to work for a company that allows me to use D to write useful products.
I still take the same joy from programming that I did when I first learned it.
Then there is the human aspect of it: I want to be associated with real people isntead of snobby elites. (Remember how C++ was marketed at around 2000? "Yes, C++ is hard but it was never meant to be for normal programmers anyway." Ha ha ha! I am old enough now to reject that mentality. Bad design is bad design my friends; you can't defend it by blaming the user for not being elite.)
I can go on and on...
Now it's my turn to ask: Why would anyone choose C++ for their projects despite the production costs that it brings? None of your programmers really know it; they introduce hidden liabilities in the projects, their source code become non-refactorable monsters. Why waste that money on C++ when you can produce products easily. Products that just work...
> Why would anyone choose C++ for their projects despite the production costs that it brings?
Familiarity, and all the libraries and tools available for C++. I see that D has a section on C++ interop,[0] but it looks about as painful as FFI usually is, and even more painful given how template-heavy C++ code tends to be.
(Completely unrelated: I can't mention FFI without also mentioning how amazing LuaJIT's C FFI is. The developer(s) really nailed it.)
[0]: https://dlang.org/spec/cpp_interface.html
I actually don’t think C++98 was that bad or complex. Yes nobody knew how to use it and wrote Java instead, but I think the hate comes from having code spanning so many different features and idioms that also require a compiler expert to understand.
Slightly off topic: Is D a good language for creating tiny windows or Linux executables? There is an upcoming game jam (4mb jam 2025) which gives extra points for game submissions <= 8KB. With c you can fit a window with graphics update in an executable of less than 900 bytes[0]. Granted it's using crinkler for linking which does some compression.
0: https://gist.github.com/ske2004/336d8cce8cd9db59d61ceb13c1ed...
Yes. Just use the “better C” mode
... which is not D any more though.
It's like saying "C is no longer C if you don't link with libc", it just is not true at all, and honestly, a pretty stupid thing to say
Instead of being an ass, maybe you can take the time to educate me why you think I'm wrong?
I think that at least the garbage collection not being available qualifies my statement as somewhat being true. For game development, as it's closer to what grand-parent asked, classes not being usable would also be an issue...
What essential features are missing for you?
For game development? I imagine having to use only structs but not classes would be something that forces a "non idiomatic D" experience. Dynamic arrays sound like something that's very useful for a game. I don't know, there are plenty of features that are incompatible with better C that makes D, D. Generally speaking, garbage collection would be the biggest in my opinion.
You can still use classes in BetterC - you just have to allocate them yourself. D recently acquired "placement new" which makes that more convenient.
Yeah this person is asking how to make the smallest executable. They don’t want garbage collection.
Garbage collection was about what I would be missing. I mentioned before what could be missing from OP's point of view.
Ok. I think the better C mode is cool and I think it’s worth a try for his interest and project.
I fully agree with you, but I think that if you present it as an option to somebody you should write a line or two about the potential downsides, so they have a better picture. Sorry if I was too abrupt in my criticism of your post. :)
I feel like D is such an underrated language.
We're not good at marketing! But we're very good at language ergonomics.
Just to add, I learned D in a day and finished most of project euler without needing to look up the manual. D is more "python" than python in that it makes coding very.
IMHO, Zig is the closest thing to being D-esk (like with comptime), but it's still not a mainstream option yet.
* makes coding very straight forward. Most of the time I find what I needed in the language just using intuition.
Love D! I used it a bit in college when it was required for a programming language class. It's hard to justify using it nowadays though.
Utah Valley University? Or Romania, or Turkey? And why is D's usage hard to justify (because of Rust and/or contemporary C++)?
Mike Shah has been using D for teaching software engineering at Northeastern University and Yale. Here is his DLang playlist: https://www.youtube.com/playlist?list=PLvv0ScY6vfd9Fso-3cB4C...
We have also been using D for computer graphics and game programming as of this year! :D
Totally forgot about that; sorry Mike ;)
No worries at all! :)
Lecture videos or notes?
YouTube series has tutorials, and course videos are on my website. More slides and such will be posted on my website otherwise.
Yes, UVU. And also yes. If I find myself needing something low-level and performant, I have a hard time justifying the ramp-up time required to use D since there is a near zero chance I would use it in my current or future employment. While that isn't always how I decide what technologies to use in my personal time, it definitely is a factor that tips the scales towards a more mainstream language
Anything compiled with LDC2 >=1.29 (3y old) will immediately crash/segfault on macOS >=15.4
A fix is on master/beta but will still take some time to be released.
https://github.com/dlang/dmd/issues/21126
Good thing there's the DMD and GDC compilers too then
DMD is also affected
It's been about 10 years since I last dipped my toes in the D waters.
At the time (v 2.067) I stumbled across some surprisingly bad warts in the standard library that prevented me from using it for my intended purposes which writing software tools for bioinformatics.
As other posters have noted, language elegance is secondary to the ecosystem when you want to get things done.
For anyone who has been using D for an extended period, has the D ecosystem improved / expanded considerably in the last 5-10 years?
The Youtube channel Tsoding did a great overview of the D language, overall, he liked it!
Author here... AMA.
I recently read almost the whole book in a week or so. It's excellent and I feel like I can write in D pretty well after reading it. Too bad that I most likely won't be writing in D, but, at least, I'm confident I can come back to it anytime and be up to speed if I ever need to. This book should be the goto for anyone who wishes to quickly learn the language.
Planning on an update? Some new features made it into the language (I think).
All I need is another wave of motivation. I'm searching. :)
Looking forward to that swell :)
Been a heavy user of the language since 2013. This book was very helpful at the time. I don't think it was a book at that time, though, more a lengthy collection of notes as I recall.
Exactly. It really was a happy accident. I talked about it here: https://dlang.org/blog/2016/06/29/programming-in-d-a-happy-a...
I tried D several years ago, and liked the language. I didn't stick with it because of the lack of libraries compared to perl, python, C++, etc.
Is D runtime still crashing when host has more than 128 cpu cores? I learned this the hard way ...
Are you talking about "Issue 24254 - LDC crash on Epyc Bergamo"?
That was fixed within the week, with a notification given that it had been sent to the reporter.
One of the best language reference manuals out there...
...could need an update, though.
Really wanted to like Dlang but I just did not have a good time with it.
One of my projects has a really simple server written in nodejs that's basically (in terms of complexity) just an auth'd chatroom, and I wanted to switch it from using raw tcp sockets to websockets. And since the server is so simple, why not refactor it to another language and see if there's no some performance gains from that? I ended up doing something pretty similar to that "Comparing 10 programming languages. I built the same app in all of them." video from Tom Delalande (https://www.youtube.com/watch?v=-MbTj8DGOP0). I had several working versions of the server in:
- Bun, using Bun APIs (https://bun.sh/docs/api/websockets)
- Dart, using Dart APIs (https://api.dart.dev/stable/latest/dart-io/WebSocket-class.h...)
- Java, using Java-WebSocket (https://github.com/TooTallNate/Java-WebSocket)
- Kotlin, using Ktor (https://start.ktor.io/p/ktor-websockets)
- Rust, using tokio-tungstenite (https://docs.rs/tokio-tungstenite/latest/tokio_tungstenite/i...)
- Zig, using websocket.zig (https://zigistry.dev/packages/karlseguin/websocket.zig/)
- D, using serverino (https://code.dlang.org/packages/serverino)
And Dlang was, by far, the worst experience out of the lot. Firstly is the lack of adequate, comprehensive, and centralised tooling. I almost gave up when dmd could not even compile a freshly init'd project. The impression I got is that you're not really meant to use dmd directly, you're meant to use dub, like how you compile Java projects with Maven/Gradle, not javac. Except that there's also apparently three competing compilers (https://wiki.dlang.org/Compilers)? And good luck remembering the names of the tooling because they're all some random three-letter combination.
Serverino makes heavy use of mixins and attributes (think Java annotations), which is not ideal. But what really killed the deal was (despite using the recommended intellij plugin (https://wiki.dlang.org/IDEs) with the recommended tools installed and setup) not being able to inspect[1] serverino's mixin or its attributes. So I look at serverino's source code, except its source also has mixins... which I can't inspect. I'm not going to use something when I cannot easily ascertain its control flow. And while, yes, I probably should have gone with vibe-d (https://code.dlang.org/packages/vibe-d%3Ahttp) in the first place, mixins and attributes are nonetheless part of the language and the tooling should be able to tell me about them.
- [1] When I say "inspect" I mean requesting the IDE to show me the source/definition so I can see what it is, what it does, and where it's known to be used.
I found the lack of mature tooling to be hugely problematic. The Visual D extension always felt flimsy and unreliable when debugging D.
DUB also exhibits weird behavior. For example, I wanted it to produce separate debug and release binaries, which it won't do out of the box. Instead, it'll create the same binary for both configurations. Changing that behavior was more difficult than it needed to be. Maybe it's changed since then, but I didn't have a pleasurable experience.
> And Dlang was, by far, the worst experience out of the lot. Firstly is the lack of adequate, comprehensive, and centralised tooling. I almost gave up when dmd could not even compile a freshly init'd project.
Yep this also happened to me when I tried D. I love the idea of the language and the syntax is great, but I really don't want to fight my tools when I'm working on a project.
Hi there. I'm the serverino's author.
Could you please explain better what's wrong with it?
It could be useful to improve newcomers experience.
How did you choose serverino over other frameworks?
Oh the issue isn't with serverino itself but with the lack of tooling-support for the language features that serverino makes heavy use of. And while serverino is open source, so one can ultimately view its source code, not having access to modern IDE type inspection adds a lot of unnecessary friction.
Still curious: How did you choose Serverino among the many servers?
Might seem silly, but the choice just came from looking at (https://code.dlang.org/search?q=websockets) and seeing that serverino is the only one maintained. vibe-d isn't listed there, I only learned about that later. Basically, serverino has good SEO.
Thanks, good to know. Also the fact that you searched directly on the site is a clue for me :)
How so, if I may ask?
Well, you might have searched for GitHub or got there from some page where serverino was mentioned (forum, ...) or maybe someone suggested it to you in the community. Once a program of mine was mentioned in a telegram channel and I started seeing a lot of stars on github and I didn't understand why.
Tangential, but which of the 7 ended up being the best experience?
It's a tossup between Dart and Bun: Dart has better language features but Bun has better APIs. Since Bun is first and foremost a Javascript runtime, it inherits its annoyances and issues, like the complete lack of pattern matching, or switch expressions at all, or decent enums, etc. That said, Bun includes SQLite support and encryption out of the box, whereas Dart is heavily compartmentalised (https://pub.dev/publishers/dart.dev/packages). Imagine if, in Bun, importing "node:crypto" meant needing a "node:crypto" npm dependency. Dart ekes out the win though, I think.
How did you build the rust project? The docs say:
> Most Rust programmers don't invoke rustc directly, but instead do it through Cargo. It's all in service of rustc though! If you want to see how Cargo calls rustc, you can
$ cargo build --verbose
Sure, but everything seems to point users towards using the compiler, not the package manager. For example:
- The tour guide first recommends dmd (https://tour.dlang.org/tour/en/welcome/run-d-program-locally), though it does mention dub at the bottom
- Clicking "Documentation -> Command-line Reference" takes you to dmd, with only the barest mention of dub
- Even this post, the "Programming in D" book, tells you to use dmd and doesn't mention dub at all.