That uses keyword arguments though which is bad for performance, which is the main reason I'd like to use immutable structs.
1,164 karma · joined June 26, 2018
You cannot do `x.foo(y, z)` instead of `foo(x, y, z)`, a feature I sorely miss in Julia. Nim is awesome in this regard. There are some functions / paradigms that are just better represented by `x.foo(y, z)`. Chaining functions in particular in typescript / javascript / rust is SOOO nice. Specifically, in Julia a lot of times I want to create a immutable struct with multiple fields, many of which have defaults. In Julia none of ways seem clean to accomplish this. In rust, something like this is very common:
let m = App::new("My Program")
.author("Me, me@mail.com")
.version("1.0.2")
.about("Explains in brief what the program does")
.arg(
Arg::new("in_file").index(1)
)
m = App("My program")
m = author(m, "Me, me@mail.com")
m = version(m, "1.0.2")
m = about(m, "Explains in brief what the program does")
m = arg(m, index(Arg("in_file"), 1))
That said, I don't think their documentation at the moment conveys why script setup is so useful (at the time of writing this comment). For example a lot of their examples in their documentation used their old API.
In my opinion, script setup + composition API is really nice. I haven't used React in a few years, so I'm not sure how it compares, but using Vue 3 features decreases the number of lines of code you have to write and maintain (in comparison to Vue 2), and I'm generally always for that. I would go as far and say that they would officially come out and say that the old API is deprecated.
I guess my only quandary is whether to use Vue 3 or just bite the bullet and use Svelte instead. If Vue 2 => Vue 3 is a decrease in 60% of the code, Vue 2 => Svelte seems to be a decrease of 65% ish. Is that extra 5% worth it? I don't know.
I wish there were more meaningful comparisons posted in a more objective manner. I'd like to see comparison that takes into consideration "ability to refactor", "ease of readability", "performance", and a few other (perhaps subjective) metrics. I'm not sure Julia will win out all the time depending on the weights you place on all these metrics.
I'm firmly of the opinion that if anyone uses a sane programming language first, they'll absolutely do anything they can to avoid C++.
Corollary being, 1) if C++ is your first language, you'll end up learning all these rules and exceptions to the rules and assume that is just how it is (this is the way I think about Python), and 2) if you use C++ you are aiming for performance that alternative languages cannot provide. I'm glad the gap between alternatives and C++ is narrowing. If I could, I would never write another line of C++ again. Rust and Zig are FAAAARRRR better alternatives to me personally, purely because there's fewer gotchas I have to keep in my head when attempting to do anything with those languages.
When JET.jl works it is great. But for large projects it didn't even return when I tried it. I must have waited at least half an hour once.
VSCode seems like it is offically blessed and maybe I should just cave and use it for Julia. I use vim/neovim for EVERYTHING else though. Taking me out of my extremely custom tmux + terminal + vim workflow just for Julia development annoys me unnecessarily much. Do you know if there's work on getting this to work in vim/neovim?
ErrorTypes.jl, InlineTests.jl, ReTest.jl, SetField.jl all are awesome and I've used them in personal projects. I want to see them in the core language. Maybe ErrorTypes.jl is asking for too much, but tests sorely needs improvement. A SetField like feature literally had a PR open for years and then was just closed
https://github.com/JuliaLang/julia/pull/21912
Without these features in the base language, adoption is going to be so slow. Convincing my team to add a dependency is a lot of work, including updating internal documents, best practices, internal training for how and when to use a certain feature, etc.
* Better language level support for testing
* Better language level support for docstrings - currently doc strings are just normal strings stored in a global struct, and are missing crucial information about the type signature of structs or functions or methods that are being documented
* A way to type hint without using multiple dispatch / interfaces - I want to be able to say this argument has fields x, y, z but I don’t want to use multiple dispatch to enforce this interface. Multiple dispatch is useful with the implementation details of your code depend on the data structure. But I want better static type checking for a handful of fields or methods. Typescript is absolutely awesome at this.
* Support for using @copied s.x = 1 where s is an immutable struct. Users are literally incentivized to use mutable structs instead of immutable structs because that results in shorter cleaner syntax, even though performance drops through the roof in that case. With immutable structs you’ll have to recreate the struct by calling the constructor. In most cases, the compiler will compile as this away anyway but users are going to prefer shorter cleaner syntax when writing code.
* Better macro support. Currently macros have to be valid Julia code, meaning you end up with weird dsl that only kind of sort of matches the domain being modeled. In rust and nim I can literally copy almost any syntax and paste it in a macro block and it’ll just work. This is more work for macro developers and probably will make inference harder but will improve readability.
* Language level support for extending Array or letting users define arrays that are as efficient as the built in ones.
* Similar request for String buffers.
* Rewrite parser that is currently in scheme in Julia, I suspect better tooling will fall out of this
* Support for a subset of Julia that is fast to compile and run and produces small binaries.
I think more generally I want Julia to be a slightly different language than it is ( or possibly ever can be ). Currently a user of Julia needs to be cognizant of too many things that could accidentally introduce type instability. Almost none of these problems are going to be encountered by someone that understands how compilers work / how computers work, which in my experience is not a lot of domain scientists but is a lot of the core team working on Julia. Domain scientists have PhDs or Masters in highly niche subjects after years of writing Python, R, or Matlab but are more often than not terrible software engineers. I can’t tell how many times in almost a decade of being in this field have I seen 10,000 line scripts in a single file without any comments written by extremely smart scientists. Guiding these folk from the get go to make better software engineering decisions is important imo. Currently, if I’m leading a project, I can’t trust a fresh graduate or junior engineer to write idiomatic type stable fast and extensible Julia code, even if they are the experts of their domain. They have to be experts of their domain AND awesome software engineers which is so rare to find. Given additional constraints about funding, writing proposals, documentation etc, it’s honestly kind of amazing that Julia’s libraries are as good as they are.
In my opinion, Julia really shines when one or two people have to write code to tackle a specific problem. Code is super concise and clean and it all fits in your head and everything is fine and dandy. But when you have an engineering team that needs to work with databases, authentication, logging, deployment, scaling, machine learning, data analysis and plotting, and do most if not all of that in Julia … it’s so easy to write something that gets checked in that passes tests and code review that just destroys performance benchmarks.
I completely agree with Jakob's take in the piece you've shared btw. Personally, I don't think Jakob goes far enough.
I've used Julia professionally too, and worked with large code bases (a 10000 line Julia monorepo project that just keeps growing), and the lack of interfaces, the lack static type checking, the lack of error types, etc would all be show stoppers for me to consider Julia at the start of our project if I knew then what I know now. I've even tried to run static type checkers like JET.jl on our code base and it just keeps spinning or failing. Unfortunately it is a sunk cost for us at this point and we'll just have to use Julia, and deal with these pain points, and hope and pray the language gets better over time.
I can see some improvements such as minor latency improvements happening over time. But (in my opinion) I don't think language features like interfaces are likely to happen until Julia 2.0. In 2018, the core team had laid out priorities in a discourse post, and marked those as done last year (i.e. 2021).
https://discourse.julialang.org/t/compiler-work-priorities/1...
In my opinion, there's a LOT more language features required to help tooling in the ecosystem improve. The fact that they marked this as done (which I just found out while typing this comment) and that there's no follow up priorities outline post (as far as I can find) is a little troubling.
I think a lot of people that pick Julia as their first language really like it, but I believe it is mainly because they haven't experienced something better to compare it to. I'm not saying everyone is this way, and obviously everyone values different things in their programming language / development environment. I do think if you don't know what's out there you tend to just accept that something you are doing is the norm.
And I think a lot of people that come to Julia from languages like Python, R, C++ see value in Julia for solving package development issues (compared to python), better language design (compared to R), performance without verbosity (compared to C++). And I think they weight those issues more heavily than I do. I've dealt with Python packaging issues, and still do on a daily basis but I now know my way around whatever comes up. R's syntax might be kludgy but I'm damn productive if I'm using ggplot. I'd rather use Python for general purpose work and R for plotting, than having to deal with Julia. C++ though I'd never want to touch again, and would just use rust instead. If rust wasn't an option, I think I'd end up using Julia (even though I complain about it so much). This is just were my priorities / skill level lies, and I can completely see how it would be different for others.
I'm much more productive plotting in Python and R than I am in Julia, purely because of compile times, even though Julia has a much better designed plotting package than Python (R's plotting ecosystem is rather convenient even if it is counter intuitive some times).
When you've used Rust, Go, Nim etc, developing in Julia feels so ... antiquated. Just as one example, when using Rust, you can write a unit test function right next to the function you are testing. And you can run just that unit test function from a terminal (e.g. `cargo test -- test_just_this_one_function`). And because you can write a quick little test function pretty much anywhere in your code and run it in the terminal, you don't really feel the need for a REPL all that much. When I'm not writing tests, I would say I'm as productive in Rust as I am in Julia (mainly because of awesome language server features in Rust). But the moment I need to write tests in Julia ... it's a big oof y'all.
In Julia there's NO official way to run just one test. You HAVE to run all of them. And the tests can be scattered in various different tests files in the test folder. Try contributing to the core Julia language itself, and trying running their test suite. You'll have to go get coffee multiple times just to make one single patch.
For projects that I'm working on, I literally have a Julia REPL open with Revise, where I manually include a specific test file after commenting out unnecessarily global state, and then call a the function I want to test that way. It's madness, and I _think_ this is what everyone does (?). If people are saying they prefer this, I can't help but liken it to Stockholm syndrome or something to that effect.
I had a few issues though,
0) I could not use the free tier in heroku because Julia + Genie would take too long to start up, and Heroku's free tier will kill the VM if you don't serve a response in 30 seconds. I was able to get it to work with PackageCompiler but even that was close when the VM booted up for the first time on Heroku. At the end I decided to use AWS instead.
1) None of my friends who wanted to contribute wanted to use Julia (they said if they were learning something new they'd prefer Go, Ruby or even just using C++).
2) Library support for Genie was just okay. Implementing Auth + Database support + dealing with cookies, sessions etc took waaayyy too long, when I just wanted to implement features for the website. I wanted to parse HTML from a custom calendar page and tried to use Gumbo, and it was slow and painful to work with. In the past when I did the same thing with Python, things just worked. Beautiful Soup 4 was SOOO much more productive for me than trying to do the same thing in Gumbo.
3) Development was SLOW. Julia + Genie takes forever to reload, even with live reload. And if you change one line in the HTML that you are about to generate, and you'll have to wait 30 or more seconds to see the update in a local developent environment. This is PAINFUL. Once the size of the application grows or you add dependencies, it takes longer. The error messages aren't too good either and don't get me started on the usability of language server in vim/neovim. The one other friend who actually downloaded Julia and installed every thing in order to contribute to the project instantly gave up on making any contributions just because of the development experience.
And, when I deployed it to AWS, even after using PackageCompiler I wasn't getting instant server responses (I'm assuming I did something wrong here though). The final binaries that I was deploying to AWS were also huge (hundreds of megabytes).
On reflection, if I had implemented the same project in Python, I would have completed this maybe 10 times faster (based on past experience), and run time would be been as fast too (except for the image processing piece). Using Python + Flask and using a subprocess to call Julia would have been a better approach to solving this problem, instead of what I choose to do. I had stretch goals for this project (more mini games) that I wasn't able to even attempt making, primarily because I was dealing with all the pain points of developing in Julia (I guess it was also my fault for trying to get all this done in a couple of weeks of my spare time).
I really like Julia as a language, but using it for anything other than scientific computing (more specifically using it as a general purpose programming language) seems to me as a recipe for pain at the moment. I would not recommend deploying production applications in Julia right now unless you HAVE to use it (because of some library that's only available in Julia) or your development team is willing to put in work to write libraries from scratch + deal with slow start up.
Maybe in a few years when tree shaking is implemented and more latency issues are resolved and language server gets significantly better, it'll be a competitive choice. Until then I'll be curiously watching from a distance :)
There just happens to be some technical choices in vim that I don't agree with / don't find appealing, where neovim happens to have made an alternate technical choice that I do agree with / find appealing. vim9script is one of them, which is highly relevant to the submission. I apologize if I came across as hating someone else's hard work.
My point isn't about being concerned about a specific issue with vim9script per say, it's vim9script itself. If Bram and a bunch of core vim devs were spending time on their _extremely_ valuable time on anything, the last thing I'd want it to be would be a vimscript offspring. That is just my opinion, and that is truly the extent of my opinion. Again, I apologize to Bram and the core devs if that came across as anything else.
I have used vim for more than 10 years now (neovim for just 2 of those years), and I expect to be using vim / neovim for the rest of my life. And having written some useful but niche plugins for vim, I felt like expressing my opinion here about the direction of vim / vimscript / vim9script wasn't unreasonable.
Their twitch streams where they work on this are a lot of fun too.
But for the stuff that is available, you can either use the vim help to learn about it or search on vim's github issues / PRs, e.g. https://github.com/vim/vim/pull/7959. I'm curious if there are other ways to learn more about vim's lua interface, searching on google as you said does not give great results for vim, just neovim.
And golang initially started off as a replacement for C, and then pivoted because they couldn't achieve that purpose ... now, it's touted for simplicity. When Rust was a pet project of Graydon, it looked VERY different to what it is right now. My point is that vim9script as it stands right now doesn't solve any real world use case that lua wouldn't be better suited for. Maybe vim9script will be better for something else entirely in the future, and that will be, as you describe something people may like. But right now we don't even know what that is, and surely that can't be a reason to decide to go explore language design in such a large community such as the one vim has? It is definitely Bram's right to do so, but I fear that people will rather move to neovim or vscode or emacs than learn and write vim9script, and as a user of that community I think that would be bad.
Also, it's not like people were proclaiming vimscript was awesome you know. There's a talk from one of the core devs of vim-lsp on YouTube [1], on features of vimscript, and literally in every slide the presenter caveats the vimscript feature in one way or another. I find it hilarious, it's a perfect example of the frustration of when writing plugins with vimscript.
set number " This is a comment in vimscript
set number # This is a comment in vim9script
There's going to be a LOT of porting of existing plugins for this to all work.
Vim9script on the other hand seems like an exploration in PL, which I’m all for generally but not in a software like vim. Like, just imagine writing and maintaining something like magit or org mode in vim9script. It’s a large complicated piece of software, you'll have to write it using without any linter, formatter or language server (at least for the foreseeable future) and your skills are not transferable to any other tool. Just the sheer probability of better plugins existing and thriving in your ecosystem drop significantly once you choose to have vim9script as the scripting language. I’m curious to see how this all pans out but I’m not optimistic.
The worst part is that it doesn't appear that existing plugins will work in vim9script. Even the syntax for commenting is different:
set number " This is a comment in vimscript
set number # This is a comment in vim9script
And to get any performance improvement, plugin authors will have to do a LOT of work that is not compatible with their existing plugins.
I for one am glad neovim exists, and I encourage people to throw a few bucks their way :)
However, I think it is unfair to compare the inclusion of log10 to the work required to get solutions to these harder problems. I guess why not both? ;)
I think having a weekly what’s great about Python/Rust/Go/Zig and how can we port this to Julia would be awesome, instead of the weekly gripes about Python/MATLAB/R.
There’s some really really neat projects in the Julia community though, and some super smart and very hard working people. I’m wondering if some focused effort from the community guided by the stewards of the language may yield promising results? As opposed to letting people that are interested in a topic just naturally contribute?
It is particularly frustrating when Julia advocates don’t see how much friction this causes and when they claim multiple dispatch and performance make this friction worth it. Surely core devs have seen beginners struggle as part of tutorials. Maybe they are just hoping these people will learn and figure it out? I’ve seen way too many people give up and just use python instead because they are not thinking about performance and just want things to work. I agree that I’m not seeing how Julia will take more of the general programming pie, especially given the work on getting JIT to Python in the next couple of years + ease of writing rust/go/zig, unless there’s significant more work put into reducing latency or PackageCompiler.jl.
But I don’t find the ecosystem fragmented or documentation poor. In fact one of the examples I give for great documentation is the Julia Manual. Can you provide examples where you find documentation lacking? As for Unicode glyphs, I find it hard to read too but domain scientists find it really easy and since that is the target audience I think the encouragement is warranted.
Specifically w.r.t. to stacktraces, I think the Julia core team should just pay someone like Jonathan Turner to review their stacktraces and see how they can improve it. JT was involved in the rust stacktraces and when he was using Zig on stream he was immediately able to identify ways to improve Zig’s stacktraces. I think his kind of insight could go a long way in helping Julia be more friendly.
Another place is Pkg error messages. I’ve opened projects from a few years ago and things have just failed. I think it is because I’m not using the same Julia version that I did when I recorded the Manifest (weird that Julia doesn’t record the Julia version number in the Manifest). But I will never know I guess because I get almost cryptic error messages from Pkg. It is borderline infuriating.
I say all of this because I really like (or at least really want to like) Julia. And I know fellow coworkers who share this sentiment about some of these pain points. If these are fixed (and latency becomes better) I for one would pull fewer hairs out of my already balding head :)
I would ask that Julia advocates take all my criticism kindly. I know you are all passionate and have worked on a lot of these features yourselves. I’m expressing some opinionated frustrations.
Edit:
w.r.t. HCI in programming languages, here’s a comment shared by one of my grad school friends that is doing a thesis on HCI in programming language syntax:
“It (sic, It -> Julia syntax) is inconsistent in a lot of ways. There’s "primitive type", "abstract type", "struct" and "mutable struct" that are all keywords for defining "struct" like things. Why not use "struct" or "type" everywhere consistently? …”
My friend’s comment is long and winding, but I’ll check with them if I can post a link to their thesis here. It might be an interesting read for some folk.
I have a love/hate relationship with Julia. I’ve been using Julia professionally since 2018, and in my spare time since before that. And after writing a lot of code and reading and reviewing even more, my biggest complaint is that tooling suuuccckkssssss.
LanguageServer takes up to 10 minutes to start (5000-7000 line Julia project with lots of Julia dependencies). I usually open vim, go get coffee and then come back to start working on the project. And if the LanguageServer crashes or I have to restart vim for some reason, oh boy.
Even after 10 minutes, updates are SO slow. You can type something incorrectly and the LSP diagnostics won’t pick it up for at least 30-40 seconds. By then you may have moved to a different point in the codebase. Forget about switching branches when you are doing all this. I’ve tried PackageCompiler and weirdly it doesn’t really help here for some reason.
The worst part is there’s no way to run a subset of tests. You HAVE to run ALL the tests every time. This makes IDE driven development and test driven development absolutely non starters. REPL driven development is the ONLY way to go, and even the REPL has its readline quirks. And god bless Revise.jl. I shudder to think of life, it weren’t for Revise, the giant hack that it is.
There’s no officially blessed language formatter. LanguageServer.jl uses a formatter and JuliaFormatter.jl kind of exists on its own. And even these formatters don’t do enough, by the way (imo). Two examples that come to mind is converting explicit returns to implicit returns and changing using Foo -> import Foo: x,y. Not to mention the vim plugins for LSP and formatting are not great. Even the most popular Julia-vim plugin has some super odd opinionated un-vim like choices like high jacking TAB and the choice of commentstring syntax etc.
All this in daily development is painful as it is, and even more so when I have to review someone’s code. I’m a software engineer by training, and when I have to read domain specific code written by a scientist or a domain specific engineer, or worse when I have to refactor and clean it up, I cringe all the time. Try figuring out which method gets dispatched without using a repl, fun times. Maybe few people port a Pluto notebook script into a production application as much as I do but yikes is it painful. There is SO much down time. Wait for tests, wait for LSP, wait for formatter, wait for static analyzer with JET, make a change, rinse and repeat.
Contrast this to using Python, Rust, Zig, or Go and feedback is immediate! And unlike Julia, vscode isn’t the only golden editor. You can use pretty much any editor and you get first class support.
All in all, Julia as a language is super interesting. I would probably only use it for small personal projects though. Professionally, I would still stick with python / pypy, or even writing python and rust or go. Multiple dispatch alone isn’t worth the other pain points when working with a large team (>50 people).
1) nvim's built in lsp client is entirely in lua and afaik none of it is related to the nvim core. It is not inconceivable to just move it to a plugin but pretty much everyone will have to depend on it. I think for something as powerful as lsp, it might as well be bundled.
2) the built in lsp client in lua is EXTREMELY customizable and lightweight. In fact, a lot of useful features are enhanced or extended with plugins. Putting the onus on plugin writers to rewrite essentially the same functionality is not ideal.
3) The people that built the lsp client are extremely passionate about it and have contributed to neovim. tjdevries has some youtube clips and twitch stream clips where he talks about why this is a good idea. One thing that was mentioned during the stream today was that luajit and using libuv / LUV makes you feel like why not write an LSP client in nvim lua.
I personally think since it is so lightweight and since it is all in lua, it's awesome to have. And the next big thing can also be added to nvim base in lua without too much "cruft".