I can strongly relate to that. You can write a custom "fill" method for your array and just do "arrray.fill", bam! It just works. You want numpy "zeros"?
Scala has a strong type system and when working with it on a daily basis I was not programming, I was thinking about types and fighting with the compiler. And that is the language which has a pretty decent IDE plugin. When I moved to D, it felt like a breathe of fresh air to me. Therefore, the whole talk above about auto and types looks like subjective nitpicking.
In practice though, D codes fast and runs fast, as promised on the official site.
And that's the whole problem with Scala. When you work with it, you are having a battle with types and compiler more often than you should. Funny but it is not the first typed language I had to write code in. Never did I have to do so much unnecessary dancing around and asking senior colleagues for help. I guess not all of us are capable of grasping such expressiveness at the cost of such complexity. The majority just need simpler tools to be productive.
Scala is a beautiful and elegant language. I really thought that it would be one of my favourite languages when I first started working with it. However, after some time I got disenchanted.
First, Scala is hard. Projects written by one person quickly become a deep functional labyrinth and custom architectural patterns because Scala is so expressive and you can do all kind of twists.
Second, the entrance level remains high. Your more experienced colleagues will not allow to write anything that even remotely smells OOP. This delays the time when you can be productive.
Third, on paper Scala tries to serve both object oriented and functional worlds but in practice the the latter is the unconditional standard.
Although I like the positive tone of the article, I find it difficult to agree with Scala ever becoming mainstream.
It is, and C/C++ are used in so many areas which are not system programming right? Being a scientific Python backbone is one of them for example. My claim was that it is nothing out-of-ordinary. In fact, I really dislike the article's somewhat evangelist attempt to target newbies. These so-called benefits existed and do exist in so many other languages. The only thing that Rust comes with is memory safety which on closer look is actually an illusion and is a pretty evil one.
I would praise Rust for speed, yes. For ecosystem, yes. But that's it.
This is great, please do! It would be nice to share it not only on dlang forum too. How does it compare to scid btw?
I like R but generally use it for basic stat tasks and plotting instead of Python. It would awesome if you could share your experience on how to set it up with D in blog post or whatever form you find useful.
Unfortunately with scientific computing the only place I see D could be writing custom performance critical algorithms but then again for university folk it is more straightforward to do it in C++ or C since there are plenty of code snippets lying around.
There is excellent mir library but its documentation is subpar, no tutorials or any examples too. There is Netflix Vectorflow small deep learning library but only for CPU and only feed-forward networks, so it works for some specific narrow case. There is fastest on earth csv parsing library TSV-utilities from one of the ebay engineers but I have only learnt about it when I started looking through D website resources, also no tutorials. There are tools but using them needs more time investment than alternatives.
Last time I tried to install a Rust-based cli network tool it took literally 4 min to compile it! Seriously, 4 minutes for something that monitors your network load. If this is what it takes to make a cli tool, I'd rather do it in plain BASH :)
Applicability is not the main issue. D can be used for anything where speed matters, gamedev, data processing, machine learning, kernel programming. It is not a niche language. But as it is always with low profile languages that grow out of a sheer hobbyist talent and not backed or picked up by big companies it remains in its own humble world for years. On top of that D was unfortunate to have some pretty rough early period with transition from D1 to D2, two standard libs, several compilers, etc. etc. All this would not be an issue given there were hired teams working on it and big enough community. It all worked well against D. However, lurking around D forums and available libs left me with a good impression. Yeah, some tooling is missing and might be rough around the edges but there is plenty of work if you want to get your hands dirty. In addition D has a very helpful community of very skilled engineers imho (something I sometimes miss in other languages...).
I feel like the primal joy of programming in Python is somehow lost between those type hints. Type hints even though being very useful do look alien in Python. I myself like type hinting but cannot get rid of the feeling.
Funny, but in reality, most people fail to find that sweet middle ground of "optionality". We have a middle-sized project in Python where every single object is type hinted, even if it is a simple one-liner function. And at some point you start having a feeling that if that is what Python development looks like, there must be something we are missing.
But what are the actual reasons of overdoing it? Could it be your prior long-term exposure to the typed languages, magic IDE plugin or is it just an opinionated attempt to push the language into unnatural domain? I can't help but keep asking myself these whenever I see such heavily verbose Python code.
Just do a template
void zeros(T)(ref T arr) { arr.each!"a = 0"; }
someArr.zeros;