blindseer

Nim is garbage collected / reference counted by default (but there's a way to turn it off, there's lots of GC options). It also ships with a much more batteries included standard library. Nim has operating overloading, dynamic dispatch (although I think this feature is being deprecated), various types of macros, generics, and a whole lot of other features. Nim has everything but the kitchen sink, which can be both good or bad, depending on your perspective. Nim compiles down to C code and that lets you interface with C and C++ libraries in a very native way. If someone likes programming in C but likes the syntax of Python, they'll love Nim (imo). Nim also lets you write Nim code but transpile Nim to Javascript, so it's an alternative to Typescript in some ways. Like I said, everything but the kitchen sink.

Nim's LSP is great and editor tooling is good. The testing framework is only so and so. The package manager in Nim leaves a lot to be desired. The Nim community is well established and big, but without hard data, I wouldn't say it is growing all that much. It's pretty much the same community members from 2-3 years ago that are all doing amazing work, with the addition of a few folk.

Zig is more barebones. It uses LLVM to generate machine code but a couple of backends are in the works as I understand it. It has compile time execution instead of macros, and generics are just compile time features. Zig is a lot like C in that it is simple in its feature set. For example there's no operator overloading. Which means when you read Zig, you kind of know exactly what the program is going to do. It also means code can be very verbose (especially math-y stuff). Try doing complex number arthimetic or 2-D vector calculations and the code is as verbose and ugly as C (imo). Some people will say that this code shows exactly what is going on but (again imo) it is unnecessarily verbose. If people could opt-in to operator overloading somehow it would make Zig really neat for math. I can see Zig being used for web servers, although if it segfaults because of the manual memory management it could be bad. But really the usecase for Zig is bare metal work, maybe software that needs to perform a bunch of work on data. Zig has a unique way of transforming array of structs to struct of arrays, so you get lots of speed improvements while still writing your code in an ergonomic fashion. Zig in a rather unique twist is a better C / C++ compiler than GCC or LLVM. So if you are interested in compiling a C program, you can use Zig to do that. I think Zig is a better alternative to CMake than anything else out there.

I can't speak to using testing in Zig, and I don't believe there's even a package manager at this point. There's very few libraries for doing stuff in Zig but it is growing.

I think a good way to get a sense of the community is to look for conference talks on YouTube or on HackerNews for a language. Nim has about 10 talks a year. Rust will have 30 talks roughly. Zig usually is like 5 talks, and one of them is almost always the creator of the language. Take that for what you like.

Both are great languages and I've had fun trying them out! They unfortunately don't fit my work requirements and are not personally interesting to me.

> A better catchphrase for Julia might be "The best expressiveness / performance tradeoff you have ever seen".

Man, Jakob just has a way of writing that gets right to the point. Nice post.

My only complaint about the post is that in Python you have many different REPL options. For example, both ipython and bpython are miles ahead of the Julia REPL. I agree though that the Julia default REPL is better than the Python default REPL. I particularly like the shell mode in Julia. You can also make your own modes, like a sql mode or any custom DSL mode.

I have been very critical about Julia in the past, so I'll say some positive things before I complain more :)

- The package management in Julia is god-like. Specifically, there's a whole subset of packages that are just binaries and libraries cross compiled on VMs for Windows / Mac / Linux + x86 / x64 / ARM, and it just works. There's no more trying to compile code on a users computer when trying to install a package, it's beautiful. It is truly a phenomenal piece of engineering, and I cannot praise it enough. Hats off to the core team responsible for this.

- Multithreading is such a joy to use. Compared to any other dynamic GC language, Julia and Go are pretty much up there in terms of usability + features. So much better than Python or R. But while I prefer Julia over Go, I do prefer Rust over Julia.

Now for some of my grievances. I'm a nobody in the Julia community so take my word for what it is worth.

- Optimizing Julia code is a joy. However, learning how to optimize Julia code not straightforward. If you are coming from Python and/or don't have experience thinking about memory, cache lines, references, mutability etc, you have your work cut out for you in terms of learning how to optimize Julia code. In addition to that, there are Julia specific things you need to learn to know how to optimize your code. Do you know what the function barrier paradigm is? No? Too bad, now your codebase is 10x slower and refactoring could take weeks. And that's just the theory of everything you need to learn. There's SO many subtle ways your Julia code can be slow because the compiler wasn't able to "see through your code". And the tooling here is getting better but still has a LOONNNGGG way to go. Statically being able to check and assert for problematic inferences will improve this for me a la JET.jl but right now JET.jl is too slow to run on a large codebase.

- Thinking with Multiple Dispatch (MD) is much like Thinking with Portals. Once you get it, you have this ah-ha moment. But the type system is overloaded in my opinion. You HAVE to use the type system for MD but people also use it for interfaces (AbstractArray for example). I think adding inheritance in the abstract type system was a mistake, and a trait or interface like approach would be way better for this. Maybe something like concrete types for dispatch and abstract types for interfaces? I don't think this will EVER change though, not in Julia 2.0 or 3.0 or later, because it is SO ingrained into the Julia community. I'm not explaining this well here but I've complained about it before in previous comments on HN and am too lazy to go find it and copy paste :)

- There's a number of minor syntax / usability gripes I have that I don't think will ever be fixed as well. I generally think a programming language should incentivize you to "do the right thing", often my making it easier to type. In Julia this framework of thinking exists but isn't applied consistently. It is easier to create a immutable struct than a mutable struct

  struct Immutable 
    x::Int
    y::Int
  end
  # vs
  mutable struct Mutable
    x::Int
    y::Int
  end

However, if you want to use it to store user data, if you choose immutable structs, your interface for users is EXTREMELY annoying. For example, if they want to update `x` from `1` to be `2`.

  im = Immutable(1, 3)
  im = Immutable(2, im.y)

With mutable structs:

  m = Mutable(1, 3)
  m.x = 2

There's third party packages that make this easier but this should ABSOLUTELY be in Base.

There's similar complaints I have about type names in Julia. I'm incentivized to write `::String` instead of `::AbstractString`, `::Int` instead of `::Integer`. In Julia using `AbstractString` is almost always preferred. The naming is also quite annoying. Why does `AbstractString` have `Abstract` in the name but `Integer` not, when both of them are abstract types?

I've said this before and I'll say it again. I think Julia core devs should have a usability expert come in and review their whole codebase and workflows and make suggestions. I have no idea how Rust has nailed this so well. In Rust, so many things are just consistent. You can guess what the names or behavior of what you want so often, it's awesome.

TLDR:

If you are thinking of using Julia for a large production codebase, wait 5 more years. I've learnt that the hard way. For personal projects it is amazing though.

If you could put even a single button on the "card" itself, then it'll open up a whole layer of game design.

This isn't an actual game, but I'm thinking it would be great to pick a card face up that's "red" and be able to make a decision to turn it into "cyan". Others could pick "green" and "blue" face up, but can click a button to turn it to something else, and then the game resolves itself when everyone reveals it. Like if everyone can discuss and if everyone reveals the primary colors everyone wins.

I'm sure there's interesting game mechanics you can come up with when you give a decision to the player.

Additionally, I think this could make an interesting programmable suite of games. You don't have to sell just one game.

I’m not saying you are wrong, I’ve done the same thing, although I’ve started to think more deeply about how and when to reveal content.

Edward Tufte on the other hand suggests never “revealing” content since he claims that’s treating the audience not intelligently.

The first thing I thought when reading this blogpost was "Can I send this to a Julia core dev? Would they understand how much nicer error messages are in other ecosystems?"

I think even basic things like the order of error messages is all backwards to me. Take this very silly example:

    julia> foo() = println(123 * "hello")
    foo (generic function with 1 method)

    julia> bar() = foo()
    bar (generic function with 1 method)

    julia> baz() = bar()
    baz (generic function with 1 method)

    julia> baz()
    ERROR: MethodError: no method matching *(::Int64, ::String)
    Closest candidates are:
      *(::Any, ::Any, ::Any, ::Any...) at operators.jl:591
      *(::T, ::T) where T<:Union{Int128, Int16, Int32, Int64, Int8, UInt128, UInt16, UInt32, UInt64, UInt8} at int.jl:88
      *(::Union{AbstractChar, AbstractString}, ::Union{AbstractChar, AbstractString}...) at strings/basic.jl:260
      ...
    Stacktrace:
    [1] foo()
      @ Main ./REPL[3]:1
    [2] bar()
      @ Main ./REPL[4]:1
    [3] baz()
      @ Main ./REPL[5]:1
    [4] top-level scope
      @ REPL[6]:1

In Julia the type of the error is printed out immediately at the point where the error occurs, then a bunch of hints about closest candidates, then the function and filename where the error occurred, then the function that called it, then the function that called that. It's all backwards. In order, it's

1. important information 2. arbitrary hint which could be useless 3. most important (where the error occurred) 4. less important 5. less less important

When the stacktrace is long, this is so painful to deal with in a REPL environment. You almost always have to scroll to find out information about the error, and you have to scroll just the right amount, or else ...

And even the stacktrace arguably doesn't contain all the information it should, demonstrated well by this blog post how nice it could be.

VSCode is preferred way of using Julia (for me and for better or for worse for everyone). For long stacktraces I have to first scroll all the way back up to see what is going on. So often I have a very tiny terminal open at the bottom of my screen, and it is EXTREMELY annoying to do that. I often scroll too much and I overshoot, and just finding the error is a challenge. There's so many times where I'm just struggling to find the error, and it's just an exercise in frustration to be honest.

Here's the same example in Python.

    In [1]: def foo():
      ...:     print("1" + 1)
      ...:

    In [2]: def bar():
      ...:     foo()
      ...:

    In [3]: def baz():
      ...:     bar()
      ...:

    In [4]: baz()
    ---------------------------------------------------------------------------
    TypeError                                 Traceback (most recent call last)
    Input In [4], in <cell line: 1>()
    ----> 1 baz()

    Input In [3], in baz()
          1 def baz():
    ----> 2     bar()

    Input In [2], in bar()
          1 def bar():
    ----> 2     foo()

    Input In [1], in foo()
          1 def foo():
    ----> 2     print("1" + 1)

    TypeError: can only concatenate str (not "int") to str

The last line tells me the error. The line before that tells me where. I can scroll up to find more information if I want to.

Why doesn't Julia work like this? Who knows. I've made suggestions on slack and to people in person but I've been met with disdain for the most part.

Not to mention that almost ALL my errors are MethodError types.

And worst of all, Julia doesn't show you the string of your code in the error, so you have to click on the line that has the file and hope VSCode opens that file at that line. It's SO backwards. If you are using neovim / vim / tmux, you have manually copy paste the line that contains the file name and line number into a new terminal. Or just navigate to the file and line number manually. Ugh. In Python, I can see the error and know what caused the error. In Julia, I see the error, kind of sort of know what might be the problem, try to find the exact file and line, check if my assumptions are correct, if not traverse up the method dispatch call stack and try to predict what might be going on.

And I consider myself an experienced Julia developer. For my team members coming from Rust or Python when they get a error running code, it's just brutal during the learning process. I've had people come up to me and say to my face, Julia sucks and I shouldn't write or advocate it anymore.

This is barely touching the surface. Error reporting with macros is even worse. My team has managed to segfault our program multiple times and we are left completely in the dust then.

There's SOOOOO many examples like this where I think usability in Julia needs to be improved. Sigh. Maybe some day.

Yes exactly! I don't want my handwriting to be converted to text and displayed to me, just converted to text and stored in the background for searching.

I just want an eink tablet that lets me search my handwriting using grep. It's almost 2023, why doesn't something like this exist!?!

If you asked Elon (atleast before he stepped into Twitter HQ) I'm sure he'd disagree with you, and he'd claim good ideas can come from anywhere and it shouldn't matter who they are or if they are important.

It remains to be seen if learning has occurred.

You are giving Musk too much credit. He’s a classic control freak and micromanager, and right now he’s trying to run twitter like 6 person start-up that running low on funds.

I hadn’t seen this emails before. I’m surprised by how outward looking and myopic at the same time Zuck’s emails are, this one particularly so (the one about chat bots also comes to mind).

Ask yourself where you were in 2015 and see if you can get their take on VR or AR. For me it felt like magic. Like using an iPhone for the first time. Yes, VR and AR is absolutely the future. But social communication and media communication is just a myopic view on what the possibilities are! Interactive consumption is / was where it is at. A hybrid of games + educational experience was for me the quintessential experience a la Assassin’s Creed meets walking simulator.

I would love to just learn about places where I go passively with AR. I’d love to meet people and have fun stories shared via AR (as I proof read this, I’m not so sure about this but there’s potential).

Facebook absolutely should have built the platform first and if they did that developers would have come to build the apps. I’m surprised with 40k to 80k on staff they weren’t able make much headway into this until the past year.

Somewhat relatedly, did Zuck really write these emails in 2015? The color of the text for the date is highlighted weird. I’m surprised that the chat bot effort happened after this email. Perhaps, he figured chat bots would be a gateway to AR?

I think Zuck was focused too much on the control Apple and Google have on the average person’s eyeballs / pocket and on Facebook itself. The Facebook phone was an obvious attempt at trying to pry loose but they should have just kept at it. They could have built a Google Daydream like experience around their own Facebook phone.

All for the best I guess. I’m glad Facebook is failing. They have harmed more relationships with their algorithms imo than helped keep them together. The world might have been a better place if Facebook’s feed wasn’t trying to be so “engaging”.

These features were free to begin with! Then they got greedy (imo a marketing / sales background product manager thought they should price more aggressively) and started charging for basic features! Honestly the device was completely unusable at that point. And now they are reverting ONLY because Kindle Scribe is going to be out soon, and they need to look like they are a similar product. I can guarantee that unless they have a major shake up in their organization or put it in writing that they will not change their service offerings, this will absolutely happen again.

I'd like to see a way to specify interfaces / traits, in the base package itself.

I would also like to see a better test suite, with the ability to run a single test if I want to. Test Driven Development on a large project is a nightmare (although it's gotten a little better recently). I still can't believe how people contribute to Base Julia, because running the tests takes forever.

Lastly, better support for debugging in Neovim, Vim, Emacs etc. Better linting tools too. There's a push in other languages to write core language tooling in Rust or Zig, I think Julia would benefit from that approach (there's `juliaup` but I'd like to see more official tools similar to this).

Personally I'd like to see SetField.jl or Accessors.jl in Base. I'd also like to see improvements in the ergonomics of using immutable structs. In Julia, users should want to use immutable structs all the time, and ONLY if they need reference semantics they should want to reach for mutable structs. I think the naming and the sematics here is REALLLYY confusing when trying to get a team to write performant code. I can't tell you how many times I've had this kind of conversation with various members in my team.

Me: Create a struct for holding all that related data together

F: Okay, let me create a struct. - Refactors code base for a day - Realizes the data is being updated - Uses mutable structs

Me: Don't use mutable structs unless you want reference semantics

F: What even is reference semantics? - Tries to refactor by removing the `mutable` keyword, code breaks when doing `a.b += 1`, writes messy code like `a = A(B(a.b + 1, a.b.c, a.b.d, ...), a.c, a.d, ...)`.

Me: Ugh, why didn't you use `SetField` instead?

F: No unnecessary extra dependencies to reduce complexity.

Project Manager: Where are we with this task? Just use mutable struct and move on.

Me: Sigh. Fine.

On a non-language side of things,

1) it would be nice to have a bigger focus on teaching how to write performant Julia code. Currently, most if not all the material is geared toward someone who already knows how to write performance code (in C++ for example) and showing them the "Julian" way to do it.

2) I'd like to see a usability survey done from Julia users to see what features should be tackled next.

I wish Julia moved away from using abstract types and concrete types and moved away from "inheritance", and instead decided to tackle traits full on. Traits in Julia are SO powerful but currently are hacky or third party enabled with weird odd syntax. The built in abstract type system should really just be deprecated in favor of a generic trait system, because otherwise people will learn that way of programming which is (imho) a less expressive way to represent the same problem.

What are the chances of that happening for Julia 2.0? It feels unlikely. Julia is SO close to being an objectively perfect programming language. With more and more things being compiled ahead of time, it'll replace all my needs for Go. I still might use Rust though :)

I did something like this a long time ago, and installing clang, gcc or ghc took FOREVER. I think I spent a whole day trying to install qmk just because various things required compiling. Granted my computer is old (MBP 2012).

I'm not sure it is worth the trouble. Can someone explain to me why I shouldn't just "trust" that the homebrew developers and maintainers know what they are doing and just have it installed in the default location? I get the theoretically I'm more susceptible to accidentally running a script that requires sudo, but are they any other downsides?

Great improvements! Congrats on the release.

I don't like the ergonomics of `mutable struct` vs (immutable) `struct`. Adding `const` seems like another step in the wrong direction. Right now, there's `struct` + `Ref{T}` fields for having a immutable struct with fields that can be mutated VS `mutable struct` + `const` fields for a mutable struct with fields that can't be mutated. And defining mutability at the `struct` level is kind of painful.

Sometimes I want to accept user input in a type checked manner (i.e. not storing them in dictionaries and using typed struct fields) and then pass that struct into a core algorithm where execution needs to be fast (i.e. aligned memory, immutable structs etc). Rust does this by making the mutability declared at an individual function level or during access to the struct value. In Julia, I have to decide ahead of time and that changes how users would use a library of mine.

I also dislike that syntax `a.b += 1` is not allowed for fields in immutable structs. I would love it if `@immutable_mutate a.b += 1` de-sugared to `a = A(b = a.b + 1, a...)` or the equivalent. If this existed I think I would just use immutable structs ALL the time. If a macro for that existed in Base Julia that would be amazing. (I don't want to use third party libraries for this.)

I'm (cautiously?) optimistic that Julia will be absolutely awesome in like 5 years. Currently, 90% of my work in Julia is painful because of poor developer workflow / tools. But when I need to do the remaining 10% (performance / optimization of code), Julia is amazing. Right now, it is probably easier to write code in Python (with type hints) and drop down to Rust or Go whenever performance is needed, than to start with Julia in the first place.

I think the knowledge graph in this case is mostly derived from first principles, e.g. understand roasting, searing, broiling etc and you can apply that to any vegetable or meat.

Ideally one would be able to learn language with the same kind of etymological study, however I put it to you that is FAR more complex and boring and doesn't have more fact / science based rules than cooking does.

Also, cooking is a very personal / familial / cultural experience. Recipes can be passed down a single family, whereas language is much more broad.

I guess what I'm trying to say is that the knowledge graph for cooking is smaller and more personal, and is better served as a personalized note taking system as opposed to a gamified interface to a public database.

For example, if I would prefer recipes with eggs and potatoes as opposed to recipes with spinach and mushrooms, I should be able to cater my knowledge graph to learning more about recipes that use those ingredients (ideally with some balance in nutrients).

I tried the app too and experienced exactly the same thing. I’m surprised the app is getting as much positive reception on here as it is. Sure it is cute and “gamey”, but I don’t particularly think it’s even useful. I’d rather have the knowledge graph displayed to me in a way I can easily find information or navigate it. Why would I EVER want to use this to learn something new when I could just read the information and ingest it.

To be fair I feel the same way about duolingo but the knowledge graph is so deep and dense there that i wouldn’t be able to consume information in a couple of sittings. With recipes, I am pretty sure I could “learn” everything I wanted to learn about eggs or tomatoes or bread in just one evening. There’s probably real life experience that would add to that knowledge but that’s not something I would get from this app anyway.

Did you mean to reply to me? Or perhaps another comment of mine? If not, I don't follow.

Edit:

It looks like abhimanyuaryan is blindly spamming suggestions to write tests in this thread (???). This is a case where I agree in principle but their comments are completely beside the point and not relevant to the context of the comment or the post.

This is absolutely the right answer. You've mentioned you are an F1 student, and that unfortunately has a lot of limitations on your work. Getting your professor to fund your work as an Research Appointment could work.

My understanding is that you can't get paid in any manner unless it is through your university and even then there's only a limited number of options. If you decide to go ahead with it and charge people through other means (stripe / paypal / donations) you could get into serious trouble when you report your taxes. Even on a H1B (work visa) you are very restricted in how you can get paid.

I'm not a lawyer but my recommendation is to make it open source and free, and hope that it pads your resume. That may be more lucrative in the long run.

If I may Viral, I suspect one takeaway from Yuri's criticism (at least it was a takeaway for me) is that with multiple dispatch correctness bugs like the ones listed are hard to find (impossible even). How would you respond to that criticism?

In my opinion, better tooling to assist with such cases would help tremendously. Adding support for interfaces to `Base` would be a great start. What are your thoughts about this?

Also, it's been a while since we've seen a roadmap on what the core team is working on? What are the next big features we can expect from the language and what is the approximate timeline for that? Having answers to these questions would be extremely helpful.

My approach has been by default to never use types in functions, and if I use types, use the most abstract type possible, only in order to trigger dispatch.

1) It is just hard to explain this to people that work under me. 2) types in functions are no longer useful to understand the code or improve readability, since the purpose of types is only for dispatch.

I guess my dream request would be an alternative syntax for typing for concrete and abstract types. Abstract types would be used for dispatch and composibility. Concrete types should be used because the function is being specialized for that concrete type.

There's lots of nuance here though, and I've really struggled to communicate this to colleagues and peers.

Thanks for that explanation!

The example using Measurements.jl only works as a good example for composibility if you use `Number` as the type for the argument. If you happen to use Int then it doesn't work:

  using Measurements
  plus_one(x::Int) = x + 1

  plus_one(measurement(1))
  ERROR: MethodError: no method matching plus_one(::Measurement{Float64})
  Closest candidates are:
    plus_one(::Int64) at REPL[2]:1
  Stacktrace:
   [1] top-level scope
     @ REPL[3]:1

This is perhaps my biggest annoyance with Julia. Concrete types cannot be subtyped, and hence cannot be extended by other packages. And explaining to researchers and scientists that they need to use abstract types to make their code more composable is exercise in frustration. I think computer scientists with experience programming in C++ may have good intuition for when to use concrete or abstract types in the function signatures, but research scientists in ML and optimization (in my experience) just don't do a good job of that. And just end up having awful Julia code to work with, that isn't really extendable. In my opinion, readability suffers greatly when you have to understand the type hierarchy in order to find out if your code will MethodError or not. For example, if the author use `plus_one(x::Rational) = x + 1` instead of `plus_one(x::::Number) = x + 1`, would the code that uses Measurements.jl have worked? Who knows just by looking at the code. It turns out it doesn't work and there's a MethodError. The built in type hierarchy is great, but third party packages are hit and miss.

Honestly a simple solution to this would be to allow concrete types to be supertypes of other types. My understanding is that there's no compiler related reason for this, and this is just for "good practices" but for the life of me I don't understand why this limitation was made. I've seen Julia code that creates a supertype abstract type for every concrete type they create, and it is just awful to deal with. Fortunately, it is somewhat easy to write a macro to make this happen, but still very annoying that one has to do this at all.

Combine that with the lack of a file system package modules (like in Python or Rust), the lack of any kind of doctests, the built in testing being so lackluster, you end up with really poorly organized code.

TSCoding has a 1 min video on why he doesn't program in Haskell anymore [1] and I can't help but feel his reasons directly apply to Julia too.

For example, in order to run that example for this comment, I had to run `add Measurements` and it took 7 minutes to download the package. Why is the "registry" for packages in Julia a giant git repository? It takes SO long to update every time. This is an example of a poor software engineering decision in an otherwise elegant language.

[1] https://www.youtube.com/watch?v=SPwnfSmyAGI

Get in!

> It seems very normal and unsurprising that a community advocate would cheerlead survey results like this and let others discuss the topics you mentioned (and they do).

Maybe I find it a little tone deaf. As someone that has been using Julia for a long time and still seen very little growth in the language (compared to Rust for example), and sees users on a regular basis complain about basic issues in Julia (tooling being the biggest one for me), I find it off-putting and evangelizing when prominent community members blatantly disregard information counter to the narrative they want to establish. I hold Logan to a much higher standard, and the tone in the blog post rubbed me the wrong way. Even on Slack, there's a discussion of how "little" Julia is in this survey, and for the public messaging to be different from what a lot of users are voicing feels off. I do feel my comment was a stronger reaction, but it was perhaps stemming from my frustrations after seeing the survey, seeing it discussed on slack, seeing it discussed at work, and then reading this post.

> I am also surprised by your "scathing indictment" comment. Julia released its first stable version 3 years ago. MATLAB/R/Haskell have existed for decades. Julia has 30% of the user-share of MATLAB (and same order of magnitude comparisons to R and Haskell). This seems like a pretty big achievement already, especially when you see where these other languages are on the "love" scale.

Perhaps. Maybe I was too strong here. Julia has come a long way, and I absolutely love using it over MATLAB. But scientists and researchers are still picking MATLAB over Julia today, and that is extremely troubling for the future of the language. People are dreaming that Julia will eat Python's lunch when Julia seems like it is barely catching up to MATLAB.

I think Julia will get there eventually. But maybe I need to adjust my expectations. I previously was hopeful that after Julia 1.0, adoption would skyrocket. It did increase, but not to the extent that I would have liked. After Julia 1.6, I was hopeful again. But I think I just need to temper my expectations. Maybe after like 10 years it might be a popular language, but right now it feels like it is such an extremely niche language, and that personally hurts that I've sunk so much time and effort into it.

This is an example of cherry picking the facts for marketing at best and an extremely disingenuous blog post at worst.

Julia is no where on the map in almost every metric (no commonly used libraries, no web frameworks, etc), and even in the other metrics where Julia is listed it is WAAAAYYY down there. Below Lua. Below Haskell. It is even below MATLAB. If that's not a scathing indictment of Julia, I don't know what is.

Even in the "most loved" category, if you look at all the respondents who "want" to use Julia, it is no where near the top.

I know Logan is the community advocate for Julia, but picking just the one slice of data where Julia looks appealing and blogging about just that is very off-putting. If anything, this survey should be a call for introspection or reflection, on what and why Julia is not taking off despite people loving the language. Or a well-rounded blog post on the various metrics where Julia is listed would be much more appreciated. In fact, a blog post on what the plans are to solve static compilation, making first time to plot better, building better tooling, features planned for Julia 2.0 would be much more appreciated than this kind of shameless advertising.

I'm glad to see this, and I'm hoping to use it. Genie bundled waay too much and was too slow for development. If this cuts down on REPL load times / Revise times, it'll be win in my book.

I still think there's a LOOONGGG way to go for Julia web frameworks, and specifically here there's auth / cookie handling / supporting static assets etc and a number of features I'd like to see enabled as plugins or add ons (not unlike flask). But for now, it seems like a great start.

Ah, my bad. I read that section three times and still missed that, and feel quite dumb now.

I think a lot of tech companies / products at tech companies, (e.g. Netflix, YouTube, Messenger) fundamentally get one thing wrong. They don't "value" the user's time and drive for *maximum* engagement. Maybe the problem is that there's a new sucker born everyday, but I despise using Netflix and YouTube, and I use them only because I have to.

With Messenger specifically, I absolutely don't want to spend quality time with someone communicating over a digital device. I'd much rather just use it to make plans with the person I want to hang out with.

And when I am making plans to spend time with a significant other, if I made a request to a service for "buying two tickets for hunger games at 9pm" and it returned a message saying "I can get you two tickets for shoreline at 9:10pm", I'd want to throw my phone into the ocean. I'd feel differently if I said "buy two tickets to any movie at 9pm", that'd be a completely different story.

This is the same problem with YouTube. If you've recently subscribed to a user, or watched one of their videos for the first time, and then make a search for something completely different, one of a first few results will be a video of the user you initially interacted with. It is SUCH a bonkers user experience for me and I want to never give YouTube any information about myself for recommendations just because of that.

These platforms / products should be just services. Give the user enough information to make the decision themselves, and help them make the best decision with the most accurate and pertinent information. I hate that these products shove content into your face.

Anyone else feel like the golden age of internet services is behind us, and this shitty version is the only path ahead of us?

I think I agree with your claim that writing tests would be a super set in terms of covering the use cases of interfaces. But

1) Testing is such a PAIN in Julia. You HAVE to run all the tests every time. You HAVE to write tests in a separate folder. Multiple dispatch and composibility prevent having confidence that your tests cover all the cases.

2) In a lot of cases, interfaces improve readability of the code. Being able to just look at code in a large code base and know which interfaces are implemented + need to be implemented is such an advantage

3) Static analysis tooling can provide linting. This doesn't even have to be implemented by the core team at the moment. The lack of interface limits any kind of tooling to be developed.

All in all, when I write Julia code, I know I have to write EXTENSIVE tests. Even more tests than I have to write with Python (with mypy). Almost an order of magnitude more tests than I have to write with Rust.

Sometimes it feels like I spend more time writing / running tests than adding features to our packages. And that is honestly just not fun for me, let alone for other scientists and researchers on my team.