blindseer

> 2) you can find out what methods you need to implement just by running the code that uses the implementation and see what fails.

For large codebases this is SO painful to do. I just don't understand how anyone gets anything done when this is how they have to develop code.

Correctness in Julia feels like it'll never happen, because interfaces seem like they'll never happen.

Correctness guarantees / interfaces and slow startup are both my biggest pain points in Julia.

I often think what would happen if every Julia dev just dropped the language and used Rust instead. A scientific ecosystem in Rust would be amazing.

I genuinely think the Julia community should have guidelines on how to act on a public forum when advocating for Julia.

I've had so many instances of being rubbed the wrong way from Julia folk. In some ways, it is as annoying as the RIIR folk, but it just happens to be a smaller number of people.

I for one am excited to see the GIL-ectomy work come to the stage that it is today. I followed Larry Hasting's work back in 2016/2017, and I'm glad to see Sam has taken the mantle with Larry's blessing.

The ads are genuinely one of my most frustrating experiences when using the Chromecast with Google TV. And seeing this kind of pattern makes it more likely that I’ll never sign up for premium YouTube (whatever it is called) and just use YouTube less.

Also, I swear they do this - If you click on the try YouTube premium for 14 days, once the 14 days end you are bombarded with extra ads. And ads that are usually not skippable. I also remember getting multiple 60 min ads. I don’t remember any of these ads but I do remember how frustrating my experience with YouTube was and still is. But I’m also the kind of person that is still surprised that advertising works.

If only I could use my raspberry pi to block all YouTube ads at home. My life would be immensely better.

You can tell the website is using sveltekit by the favicon but also by how seamless the navbar navigation is. Congrats on launching.

pog

And `unsafe` with `yolo`.

I partly agree with you, in that the author is mainly complaining about Flux and other packages they've used.

But on the other hand, all the reasons the author has listed as annoyances I've experienced the exact same things and more. And I'm definitely not blaming the package maintainers for this. There's either 1) something wrong with the Julia language that results in code that is harder to maintain at scale, or 2) missing tooling to help package maintainers solve some of these problems.

In my personal opinion (and also almost universally the opinion of 20-25 of my colleagues some of whom are way smarter and more experienced than me), it is a little bit of both. Tooling like JET for linting is just taking off, and for years people have been writing and maintaining packages without linters. The ONLY way to ensure the Julia code you write is to write LOTS and LOTS of tests. In Python, if I use type hints and run mypy a whole class of errors is avoided. That's not the case in Julia. At work, we maintain a close to 10,000 line Julia code base and honestly if we'd known the tooling was going to be the way it is, we'd not have chosen Julia.

The fact that startup time is so painful + coupled with the fact that tests are basically the only way to guarantee that you are writing correct code, makes it EXTREMELY painful to work in a large team. Our internal CI takes hours to run for even the smallest changes. Even a small scale refactoring takes weeks of review from everyone involved and it is a time consuming frustrating and expensive process for the organization.

I've worked with similar size codebases in Python and C++ and have had no where near this kind of difficulty.

I can't find the link to the talk right now, but Bryan Cantrill talks about "values" of a programming language / ecosystem. And based on the way Julia is designed and implemented, I'd say the "values" are "run time performance", "scientific applications", "research suitability" (ease of creating environments, DataFrames.jl for data science etc). I think "correctness" as a value is FAR from the priority in this language, which incentivizes researchers to write code that gets the job done quick but fails to be long term maintainable or viable.

The worst part is I don't know how Julia will ever solve these issues. Leveraging LLVM to generate fast machine code at runtime is the very basis of the language, so you'll almost always (unless static compilation happens) pay a penalty at start up and first run. Using the type system for dispatch means that static analysis is just going to suck. How JET works is a mystery to me, so I'm not sure what the extent of the improvements there can be, but based on talking with others in the Julia community, I don't think it'll ever rival Python's or CPP's static linting capabilities.

The Julia devs are constantly working on improvements, so I expect things will get marginally better and maybe in 5 years or so it'll be a tolerable experience. But all in all, I'm not holding my breath.

Another massive frustration for me is that Julia has no formal way to say "here are public functions and these are private" but does have a completely orthogonal way of saying "these are functions that will populate your global namespace if you use `using`", i.e. `export variable_name`, and people absolutely confuse the hell out of these. I don't think there's even agreement in the Julia community if you should use `export` for your public API or not.

And if you misspell the exports or change the variable in question, Julia won't even warn you about it. That is straight crazy behavior to me, and I still don't understand how that hasn't been changed.

The `using` + `import` packages in Julia combined with how `export`s work make it SUCH a confusing and frustrating experience for beginners in Julia.

I personally like mathematical symbols when I'm writing and reading code in my domain, but I do feel very lost when I'm reading Julia code outside of my area of expertise. All my colleagues hate it too (hard to grep, hard to type if you don't know the math and are just a software engineer) and I'm coming around to the idea of not using it or documenting it explicitly.

The fact that mutable structs are easier to use but immutable structs are more performant, the lack of composition of fields the way Go handles it, the lack of traits or interfaces, the sorry state of compilation time, the non existent tooling all lead a beginner / intermediate Julia developer in the wrong direction in my opinion. It's very easy to write code that is straight up broken or just not efficient in Julia, and that's probably why I won't pick it for a big project going forward.

But I'm still keeping my eye on it. Maybe in 5 years it'll be the language for a lot of the jobs?

I’ve been using Julia since 2017 and still do on a day to day basis, and I agree with the author in a lot of cases, even his subjective naming conventions gripes.

The author’s biggest criticism is that Julia doesn’t have tooling to make the developer experience better. There’s Revise, JuliFormatter, LanguageServer and Jet, but the development experience in Python is enviable. There’s like 3 different REPLs, at least two competing linters and auto formatters. It’s okay to admit that these are places Julia is lacking.

I think your kind of response to criticism about Julia is what gives the Julia community a bad name, in my opinion. What is wrong with saying these things suck and need improvements? Would you rather Julia not improve and stay the way it is right now forever? Surely I hope not.

That was a great article and put into words a lot of the feelings I have had about my experiences with Go better than I could have. I also learnt a few new ways to shoot myself in the foot :)

The MIT vs New Jersey style of thinking was eye opening. And I also feel like my "values" lie closer to a language that prioritizes correctness over simplicity. I understand that means more work for the maintainers of the language though.

I wish I had that framework of thinking a few years ago. Rust's emphasis on correctness and requirement that the user deal with correctness too (with sum types + exhaustive matches etc) is I think the main reason I enjoy the language so much.

I've used Go and Rust professionally and in side projects, and I had used Go first before Rust. When I first used Go, I was like "oh wow, this is so simple and easy", and I didn't realize that I was putting up with the language. Learning Rust was relatively harder, but once I did and wrote some non trivial programs in Rust, it was like a pathway in my brain opened up and was previously blocked, and then when I went back to Go, I was painfully aware of issues that I the programmer had to keep in mind (or write a LOT of boilerplate code to keep track of). Issues that Rust's type system just solves.

The way `nil` can seep into your codebase in Go and how bad the FFI is in Go will prevent me from ever choosing it for a project going forward. And I personally would not feel confident modifying Go code written by someone else, and would not feel confident accepting PRs into my Go codebase unless I understood every line inside and out.

Rust is a breath of fresh air in that regard.

All that said, I think the author here is idealistic in a certain sense. In the scale of "solving a problem by hand (or using Excel/a proprietary tool etc)" to "writing a computer program to automate it", both Go and Rust are very close to each other. And once someone learns Go and knows it well enough, the incremental cost of learning Rust or even thinking about the problems Rust solves for you becomes not worth it. I think that it's sad that this is the way it works, but that's just how it is. It's easy for settle for a local optima like Go when taking into consideration family, pets, salary, time, effort etc.

I do think on a long enough timescale, programmers will eventually move to a "better" language. But in my opinion, that time scale exceeds the lifespan of a human :)

I’m not sure if CoC.nvim is necessarily superior. CoC.nvim, VSCode, and all the other nvim lsp plugins use the same LSP servers. The clients are all different obviously, and I don’t think there’s any major features in CoC.nvim that aren’t in neovim’s built in LSP. I’d be curious if someone has a more comprehensive answer for this. I use the built in LSP and have been perfectly happy.

I appreciate your honestly and clarity about your intentions.

Maybe this my biggest gripe when someone claims Julia is objectively better than Python or R. The answer to this question is highly subjective, heavily depends on whether you use VSCode or not, and people that usually answer this question are heavily invested in getting other people to use Julia.

But the answer is usually presented as an objective answer, and I guess that just kind of rubs me the wrong way.

Chris, your work is phenomenal and I super appreciate everything you do.

I think my comment was mainly that if I were viewing it objectively (for example, knowing nothing about Julia), I think a lot of Julia's evangelizing comes off too strong. This is definitely not directed at you btw, but just that the community as a whole is just overly positive and ONLY positive.

For example, if you search for Rust on hacker news or even browse /r/rust, you'll need 80-90% pro rust, but you will also definitely see another 10-20% of posts being very critical about Rust. And these critical posts are even from prominent members of the Rust community. Additionally, there's a roadmap for Rust posted very often.

In Julia however, I can count the number of "negative" Julia posts I've seen on one hand. Don't get me wrong, I really like Julia, but there are A LOT of things that need to be improved that I know about and probably more that I don't even realize. It would be nice to have experts post and comment on that, and the core Julia members describe how they are going to tackle that. IMO, that discussion does happen, but it is largely on Slack and forever lost to Slack's history.

For a scientific / academic focused language, I can’t help but feel like blog posts about Julia always seem to evangelize performance in the language in a biased or subjective manner. Anyone else get the same sense?

I agree, I love Penn and Teller and their style of magic. It _feels_ very science-y to me. Like they explain a trick but still blow your mind at the end of it. They show you they are masters of their craft, and most of the time (not always) they aren't trying to deceive you.

Mentalism on the other hand is the exact opposite. The only point is to impress you with pseudoscience, as far as I can tell.

Surely, Derren Brown's team talked to the lady, asked her a few questions like her name, her age, her dogs names etc, and fed that information to Derren. It's very easy with a few pieces of information like that to completely narrow it down to one person. You can see in the video, he asks for all the Fs to stand up, and he selects one person.

I'm sure there's more to mentalism, like reading body language but it feels like 90% magic (lots of prep work + hard work + presenting / misleading) and 10% improvisation.

I think you may not appreciate how intertwined your verbal cognitive skills are with your ability to think / type / communicate.

Thanks for sharing the information about EARLYBIND and GenieAuthentication.

I will say that when I used EARLYBIND it still took too long for Heroku. That's not to mention that didn't solve any of the live development workflow issues.

I looked into GenieAuthetication but it doesn't support SSO and a bunch of other features that other modern authetications libraries support.

This is just not true. Even with PackageCompiler I was getting 30 seconds or more startup time for a medium size codebase with Genie.

I would caution someone interested in this to consider some of the ramifications of using Julia / Genie. When I last used it, it was a extremely painful development experience because of the time it took to for Julia to reload when "live reload" was enabled. Further more, many features like authetication were nowhere to be found. Also, startup time for the server was SO large that it just does not work on heroku, even with PackageCompiler. And forget about using AWS Lambdas or Cloudflare pages or something like that. IMO, Rust, Go, Javascript or even Python is a waaayyy better option for this.

Kudos to the devs for continuing this work though. I'm sure it'll get there some day.

If you absolutely want to use Julia because you have an existing Julia code, you can use HTTP.jl instead. It's more lightweight and you can build routes using that into your application.

I wish Cython was a more popular option than choosing Julia or Go. Cython is great and you can get some real performance out of it.

The only drawback is that a Cython module still loads the CPython interpreter, so I personally prefer writing performance critical code in Rust instead. Writing in Julia has the same drawbacks of not being embeddable that writing in Cython does.

Julia has multiple dispatch and may seem more appealing but at scale it is a very slow language to develop in. And for scripts it takes FOREVER (try loading Plots, CSV, DataFrames, Makie etc every time you restart. It’s genuinely insane that that’s the norm.)

If the whole Python ecosystem was in Cython (i.e. numpy, scipy, etc) I’d never use another backend language again.

Have people here used Chewy? I’m kind of amazed at their customer service. It’s SO good. You can reach a person via phone or chat, they are all technically savvy and extremely helpful. And fast. I’ve never spent more than a few minutes on the phone with them and have always been thoroughly satisfied.

I'm not a systems level programmer but I personally super appreciate this kind of dialog and communication about the flaws in the programming language from prominent members in the community. I've seen it a lot more in Rust (and C++) than in most other languages. I wonder if there is a correlation between how much a language grows and changes to how many blog posts there are from prominent members in the language community outlining flaws? (Tangentially, I would love for a search engine where I could track metadata like this)

I personally think that way too often the discourse from the core team / stewards / BDFLs etc is wholly positive about their own community + the technical merits of the programming language they are representing. A healthy dose of "here are some flaws" is very refreshing and humbling, and makes me appreciate the community more.

If you are interested in using fzf in neovim, check out this project: https://github.com/ibhagwan/fzf-lua.

On a unrelated note, I can't believe someone using Chrome is surprised by something like this. If I were using Chrome and signed into my google account from there, I'd assume all bets were off.

lol no thanks. Congrats to all the engineers that have worked on this and getting this out the door, but I don't think anyone should use or recommend these Google services, especially when they have been SO inconsistent about the life, longevity and future of their products.

I'm curious to be proven otherwise (and open to criticism of my claims), especially when other services have existed for a while that provide the same functionality, or offer better tie in with alternative products (hosting, pages, workers, lambdas, compute etc).

I'm not well versed in React so only clicked into this article out of mild curiosity. If anyone is interested in discussing the non-technical aspects of this submission, please continue reading this comment :)

What do people think of the foray of these blog posts with embedded javascript components? It appears that this a nice way to provide interactive explanation on subjects. I think this post does a nice job. That said, the website experience is always a little off when someone uses components like this. For example, if you open the page and quickly scroll down, you get lots of flashes of the page layout changing. Also, the back history button seems to be broken after visiting this page. I think the website pushes itself to the browser history or something?

I love the idea of using underscore to represent partial currying.

Somewhat related, here's a similar PR for native support of this feature in Julia: https://github.com/JuliaLang/julia/pull/24990.

In my opinion, I'd love to see this baked in as part of the language. Getting buy in from my team to use this in production is just not going to happen. But cool package though!