This plugin has been worked on and the issue could have been fixed by now. I rarely used VSCode for D because the language doesn're really need an IDE support like Java or Scala. But I do agree that for beginners and IDE support is important. I use vim with DCD: https://github.com/dlang-community/DCD
It is or was used by some companies in Munich (funkwerk) and a few others. Companies like ebay and netflix have some projects in D. The users are mostly C++ veterans so the forums are full of experienced ppl who can help. I used it heavily in my work for local scripting tasks and even write a small GUI app for our API. Used it mainly instead of Python. It’s basically a safe C with a rich stdlib. There is almost zero syntax overhead and hence if you know C, you should be fluent with D in short time. It is a pragmatic language with some nice functional syntax sugar that makes Scala cry. But the language and the ecosystem struggles with the lack of ppl and overall direction. Contributors tend to complain about long times and endless PR discussions. Some D contribs moved eventually to Rust or Go, which is sad but here we are. I think D deserves more attention than it got and continues to get.
I write D fulltime for my small company, published a framework that 4 other small companies use (or have used). D is really nice for the small ISV, but is also prepared to handle massive codebases (deprecated, packages, gradual typechecks, clear deprecation policies).
The D language has almost become a German preserve, what with the only major adopters being from there. Deutsche Bahn are supposedly using it too for their platform signage.
No doubt Sociomantic Labs, which was acquired in 2014, was a major driving force there. The company was very succesful and hired a lot of the best developers interested in D at that time.
>It is or was used by some companies in Munich (funkwerk) and a few others. There is almost zero syntax overhead and hence if you know C, you should be fluent with D in short time.
Every time some survey pops up, TF somehow looks still relevant while I know noone who uses it or even considers using it unless they are new to DL field. How much of TF here is v2.0?:)
We use exclusively PyTorch at work both for CV and NLP tasks and this is the standard nowadays. Keras was cool 5 years ago (last time I checked it) but it somewhat quickly faded due to TF.
It's not the fact that the bugs were fixed. It would be really strange to revisit this article and find out that they weren't, right? It's the fact that the author has spent years working with the language and published several libraries on the way. His article contains other links to similar experiences other ppl had with the language. There is another informative JAX vs Julia article there (by Patrick Kidger) as well. It's just enough material for all kinds of doubt and this really sucks for the language. I simply cannot image a situation where Julia will be seriously considered in a commercial company after this, not in prod. And what's worse, anyone who will fancy the idea of investing into a new language will have a hard time justifying its worth. After all, when you read about several months of hunting for bugs, you definitely don't want to be that person.
>And what's worse, anyone who will fancy the idea of investing into a new language will have a hard time justifying its worth. After all, when you read about several months of hunting for bugs, you definitely don't want to be that person.
Yea, that would be me. Julia seemed like a good fit but I don't want to spend months bug hunting someone else's language
I like to explore alternatives to Python and Julia has been one of the tools I am waiting to become mature enough to actually invest some time in. But every time I start reading threads, I see the comments from actual users reporting about half an hour minutes and “coffee time” project compilation. Then the dreaded ecosystem problem. Then I think to myself, well, it’s not the time yet.
Also, I wish Julia was as popular in Europe as it is overseas.
Could you elaborate on the ecosystem problem? For my corner of the world, Julia probably has one of the highest quality ecosystem (differential equations, physics modeling, autodiff through very complicated code, probabilistic programming, SIMD/multithreading, and wonderful plotting libraries (the Makie.jl ecosystem) and good data wrangling capabilities (the Dataframes.jl ecosystem)).
I am curious what are the fields where it is less well developed?
working with databases, streaming data around with stuff like kafka or snowflake, integration with orchestrators like prefect or dagster, robust interfaces for spark, being able to read a directory of parquet files without the GC going insane, this kind of thing
I know there are some existing packages that nominally do some of these things, but generally they are understaffed and not fully mature. I love Julia as a language, so I hope this will improve over time. I think it's one of those problems that just requires more adoption before it can be fixed, and things like precompile TTFX improvements in 1.9 are a good way to get that!
Honestly, I'd stick with python or learn a statically compiled language to broaden your world. I spent years in the Julia situation and it's more of a cult than anything else. If you ever end up with a job asking for Julia(not likely), you can pick it up in a week or so of free time after some muscle memory kicks in.
> I spent years in the Julia situation and it's more of a cult than anything else
What is a "Julia situation" and how is a programming language a cult? It's used by companies, programmers, scientists, etc. to do stuff. This is a strange take.
Get involved in the community. You'll see. This isn't FUD. It's observations of someone who has been very active in the community since well before the 1.0 release.
Cult? That's a very bad take. It's a tool, great for some stuff, rough edges here and there.
People invest huge amount of effort fixing Python's shortcomings (pyspark, tf, jax, mojo) requiring a completely different way of thinking modulo the syntax. And nobody is talking about the "cult of the snake"
It's not culty to make packages for a language. It is culty to work 12 hrs a day to appease Julia computing for free to have your work taken renamed and offered to the community with different names on the authors list.
Sure graphs.jl used to be lightgraphs.jl. rumor has it the author was bullied out of the community for their personal beliefs which had nothing to do with graphs or programming. Then the Julia crew took the project and sunset the lightgraphs guys work. There are other cases of stuff like this happening but I'm too lazy. Just go ahead spend a few years in the community contributing, good times ahead. Keep in mind, if you aren't paying for the product you are the product.
So, you mean that loading a bigger project in Julia was more or less equal to compiling it with some language like C++? And you had to do it every single time in order to work with the project? This doesn’t sound too good tbo.
That used to be the case before this version, indeed. It was due to how incredibly difficult it is to cache code efficiently in a language that (1) dynamically compiles things and (2) supports multimethods. Point 1 is crucial for the high performance, and point 2 is crucial for the incredible composability of libraries and reuse of code. To my knowledge julia is the first language to solve both with UX that is getting better and better. JAX/PyTorch/Tensorflow have some similarities (with long compile times for models), but lack the composability.
Come on. Julia is >10 years old. This was a language design decision many years ago, the shortcomings of which have been addressed much later when it started to be clear that it is a problem. Native code caching is available only since 1.9. This is great that the team worked hard on them, but if this was not an issue right from the start, Julia could have been in a different place today.
I think the dynamical recompilation that made code caching difficult is from 0.6, the last release before 0.7 (the first stable release). From 0.1 (2012 or 2013) to 0.7 julia evolved drastically. They stabilized only in 2018ish. This seems like a pretty reasonable timeline for something no other language has done before (although, as I mentioned, pytorch/jax/tensorflow have some limited similarities, and similar problems).
I see. Right, 2017 was the first time I tried Julia and never came really back. Then the Torch, TF, Keras, PyTorch era started and kept ML engineers busy while I think Julia couldn’t keep up. Well, there is Flux. Not sure how it compares.
It can't compare, not even close. There is just too little devpower behind Flux. Also, the AD landscape in Julia have been changing so fast that the ground has been shifting under Flux, so to speak.
It's a shame, because Julia is so obviously a good language for DL.
In practice, it's not a huge issue. Static imports are already precompiled and any code paths within your project are cached. Typically people will use a single session and use hot code reloading, so any changes in the codepath will need a recompile (on the order of milliseconds).
Nim is a strange choice to come to mind while there is Lua. Much more approachable and lightweight glue language for numerous C libs and tools existing on any os. If you go in that direction than D seems like a better choice that could also come to mind. Basically C but with gc. All these are good choices for system scripting any day.
I am not saying this as an expert but I needed to set an environment variable with lua and it's not supported. You can read but not write them.(There's getenv but no setenv - i just looked it up and it's due to Ansi C not having the latter) I believe it has something to do with cross platform compatibility. This is pretty basic stuff. Maybe it's just the standard library and people just import something for it.
