Julia biggest problem at the moment is growth. Julia has suffered from not having exponential growth, and has either maintained a small linear growth or has fallen in popularity. Search online on YouTube for tutorials, on Twitch for WatchPeopleCode, or on GitHub for benchmarks; and Julia is not even in the room where the conversation is happening - there just isn't any mindshare.

And for good reason. There are so many ergonomic challenges when using Julia in a large codebase and in a large team. Julia has no formal interfaces, LSP suggestions that are often just wrong, and no option types. This just makes writing Julia code a drag. And it makes it quite difficult to advocate to developers experienced with languages that offer these features.

Additionally, the core conceit pushed by Julia advocates is that the language is fast. This is true in controlled benchmarks but in real-world scenarios and in practice it is a real pain to write and maintain code that is fast for high velocity teams because it requires a lot of discipline and a strong understanding of memory allocation and assumptions the Julia can and cannot make. You can write code that is blazingly fast, and then you make a change somewhere else in your program and suddenly your code crawls to a halt. We've had test code that goes from taking 10 minutes to run to over 2 hours because of type instability in a single line of code. Finding this was non-trivial. For reference, if this were uncaught our production version would have gone from 8 hours to 4 days.

The lack of growth really hurts the language. Search for pretty much any topic under the sun and you'll find a Python package and possibly even a Rust crate. In Julia you are usually writing one from scratch. Packages are essential to data processing are contributor strained. If you have a somewhat unpopular open source code code you rely on that doesn't work quite work the way you want it to, you might think I'll just submit a PR but it can languish for months to a year.

The Julia community needs to look at what programming languages are offering that Julia developers want and will benefit from. The software world changing very quickly and Julia needs to change too to keep up.

For those who might not be familiar, tooling can sometimes help a lot here. The ProfileView.jl package (or just calling the @profview macro in VSCode) will show an interactive flamegraph. Type instabilities are highlighted in red and memory allocations are highlighted in yellow. This will help to identify the exact line where the type instability or allocation occurs. Also, to prevent regressions, I really like using the JET.jl static analysis package in my unit tests.

    https://github.com/nim-lang/RFCs/issues/547#issuecomment-1879179448

All this said, I would reinforce what others here have said - the property is not actually as onerous in practice as you might imagine. So, it is really worth suppressing knee-jerk reactions to this one feature and giving the language a try, just with `nim c/cpp/js --styleCheck:usages` or whatnot.

> <Tag a="b" x={y+z}>{valid JS expression}</Tag> > is > React.createElement(Tag, { a: "b", x: y + z }, [<valid JS expression>])

If you take the main reasons React is criticized and claim it is a feature, surely you have refute the criticism more thoroughly than "This seems so simple, yet do not underestimate it." or "That is powerful. Do not underestimate this."

Modern frameworks (Svelte / Vue / Astro) are about using the platform. They are performant, efficient, easier to read, easier to write, and easier to understand.

I don't see any reason I would pick React for a greenfield project anymore.

I get that if YOU don't want to use a modern framework and want to stick with what you know, sure, by all means, pick React. But writing even a semi complex application in both React and Svelte should make it immediately obvious that React is antiquated, if you give both frameworks a fair shake.

Proof? Source?

>I don't see any reason I would pick React for a greenfield project anymore.

I don't see why you wouldn't. It's stable, performs well, works in every browser, easy to find answers for problems you run into, and almost every knows it (or should, it's 2024, you don't have an excuse anymore).

>I get that if YOU don't want to use a modern framework

React is the modern framework. It's nimble, concise. The other frameworks are regressive -- they make mistakes that older frameworks already highlighted as being problematic over time.

https://joshcollinsworth.com/blog/self-fulfilling-prophecy-o...

It's been a few months since I read it, but I recall the main thing I took away from this was: React isn't necessarily the best choice, other frameworks provide better performance, development experience and tooling that should also be considered

Of course these are just opinions. Everyone should consider all the facts and come to their own conclusions about what they use and don't use.

Companies will continue to use React of course. But I'm not sure if I would use vanilla React for anything I have complete control of.

I understand them quite well. I would say I probably understand them better than OP.

But this is so table stakes nowadays it's like saying your restaurant has a bathroom.

Each person that I’ve come across who likes react is super smart and I can’t follow what they are trying to say is so great. So maybe don’t listen to me anyway.

It boggles my mind that engineers and managers that have kids and are working on the YouTube team think this is okay and this is what the future of the platform should look like.

It's the beginning of the end of an era, and I'm immensely sad to see what the internet has become and where it is heading.

Or they stop going to YouTube. In the past 12mo my use of these platforms has reduced a huge amount. I no longer visit Twitter or Reddit because they blocked 3rd party apps, forcing me to view adverts, I would rather not be a user on a user hostile platform.

Deep down, most of us know these are huge time sinks providing very little real value to ours lives so it doesn’t take much friction added by the platform to make people turn away from their bad habits.

It's either a very depressing thing, or maybe an opportunity, depending on how rose colored your glasses are.

Now, of course, we have community efforts like SponserBlock that could easily identify ad locations or some form of auto detection based on analyzing the video of they insert the ads at random locations in the video stream itself.

I'm certain this is coming. There's very little on YT I need to watch right now, and having a bunch of videos already downloaded and de-ad-ified would suffice. It would prevent the mindless watching anyway.

Seems like slightly less of greasy activity now than it was then.

"Count eight" about halfway down the page: https://cip2.gmu.edu/2015/09/22/lets-get-real-about-kim-dotc...

Is content from publishers you’ve subscribed to normally ad-free? I don’t understand the relationship between these things

The error handling in Go is SO verbose. When reading my code (or even reviewing other people's code) in order to understand at a high level what is going on, I feel like I'm squinting through a mesh wire window.

Compare this example in Go:

    city := c.Query("city")
    latlong, err := getLatLong(city)
    if err != nil {
     c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
     return
    }

    weather, err := getWeather(*latlong)
    if err != nil {
     c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
     return
    }

    weatherDisplay, err := extractWeatherData(city, weather)
    if err != nil {
     c.JSON(http.StatusInternalServerError, gin.H{"error": err.Error()})
     return
    }
    c.HTML(http.StatusOK, "weather.html", weatherDisplay)

    let lat_long = fetch_lat_long(&params.city).await?;
    let weather = fetch_weather(lat_long).await?;
    let display = WeatherDisplay::new(params.city, weather);

Prototyping even small applications in Go is verbose. And worse still, error prone. It's easy to be lazy and not check for errors and oops 3 months in your code fails catastrophically.

I know a lot of people like Go on here but in my mind Go only makes sense as a replacement for Python (static compilation, better error handling than Python, faster etc). If you don't know exactly what you want to build, maybe it is faster to prototype it in Go? I still would reach for Rust in those instances but that's just me. For large applications there's no question in my mind that Rust is a better choice.

Edit:

people have pointed out that I'm not comparing the same thing, which is true, I apologize for the confusing. But even code where Go propagates the errors, it is much more verbose (and my point still stands)

    err := db.Get(&latLong, "SELECT lat, long FROM cities WHERE name = $1", name)
    if err == nil {
     return latLong, nil
    }

    latLong, err = fetchLatLong(name)
    if err != nil {
     return nil, err
    }

    err = insertCity(db, name, *latLong)
    if err != nil {
     return nil, err
    }

I think Rust is a fantastic systems language that is misapplied to the web. I think Python was a fantastic scripting language that is misapplied to the web, too, so you can put that in context.

I counted the number of lines in my work projects, and I have $WORK projects that are 100k lines of code. Maintaining that in Go would seem like a nightmare to me, but in Rust that is so much nicer. My personal projects range from 10k - 35k and in all of those I much prefer the ones where I'm writing and maintaining Rust vs Go when it comes to similar complexity.

Even 100k LOC is pretty small for a software project, and likely doesn't need more than a few engineers. The advantage of the simplicity of Go shows up when you have to coordinate across >100 people, many of which are kind of mediocre, and you need all of them to ship features. If everyone in the world were a genius who is obsessed with writing clean code, Rust would be a fantastic language to work in at that scale, but they are not.

Handle(err)

which may take a line, but isn't the 3 lines everyone refers to, and often has a lot of extra logic.

Control flow wise, Go is much easier to understand than chains of ? and await.

`match result { Ok(v) => v, Err(e) => return e.into() }`

This means that the code related to error handling is all in one place, and your business logic can just focus on the happy path.

    err := db.Get(&latLong, "SELECT lat, long FROM cities WHERE name = $1", name)
    if err == nil {
     return latLong, nil
    }

    latLong, err = fetchLatLong(name)
    if err != nil {
     return nil, err
    }

    err = insertCity(db, name, *latLong)
    if err != nil {
     return nil, err
    }

I guess it comes down to what features the language provides that makes it easy to do "the right thing" (where "the right thing" may depend on where your values lie; for example, I value correctness, readability of domain logic, easy debugging etc). And in my opinion, it's easy to do what I consider bad software engineering in languages like Go.

    val, err := someOperation(arg)
    if err != nil {
        return nil, fmt.Errorf("some operation with arg %v: %v", arg, err)
    }

Go errors usually contain enough context that they're good enough to print to console in CLI applications. Docker does exactly that - you've seen one if you've ever tried executing it as a user that isn't in "docker" group:

    docker: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.35/containers/create: dial unix /var/run/docker.sock: connect: permission denied. See 'docker run --help'.

   some_operation(&arg)
      .with_context(|| format!("Some operation failed: {arg}"))?;

   some_operation(&arg)
      .context("Some operation failed")?;

   some_operation(&arg)?;

Whether that's better or worse than the Go snippet is something I'll let the reader decide.

Not to pick on any of these projects, but this pattern is way too common to not have a some sugar:

https://github.com/goodlang/good/blob/3780b8d17edf14988777d3...

https://github.com/kubernetes/kubernetes/blob/1020678366f741...

https://github.com/golang/go/blob/6cf6067d4eb20dfb3d31c0a8cc...

Yes, because each level is (hopefully) there for a reason, and provides a deeper context about where and why the error occurred.

If your contextual information is too repetitive and redundant, it may be the time to refactor your code and remove the unnecessary layers.

It reminds me of A Philosophy of Software Design:

The utility of a module (or any form of encapsulation such as a function) is greater, the smaller the interface relative to the implementation. Shallow ve deep modules.

Error handling might be a proxy to determine the semantic depth of a module.

Another perspective: (real) errors typically occur when a program interacts with the outside world AKA side effects etc.

Perhaps it’s more useful to lift effects up instead of burying them. That will automatically put errors up the stack, where you actually want to handle them.

This perspective also made me think of another advantage of Go error handling over traditional try/catch logging:

In other programming languages, when doing some asynchronous work in some background worker or whatever, exceptions become useless as error reporting mechanisms, because stack traces don't correspond to the logical flow of the program. I remember Java's Spring to be exceptionally painful in this regard.

In Go, since errors are values and you're expected to add context information whenever appropriate, you can shift and shuffle those errors between stacks, and still keep useful context information when you eventually read those errors.

The only issue there is if you want to return the error with code 200 (which you shouldn't, but it's been known to happen). In that case the Go code and the Rust code will look a bit closer to each other because then you can't use `?` this way (without writing some more boilerplate elsewhere).

(I like Rust, C, C++ etc. as well.)

Like take a look at this pattern:

    err := db.Get(&latLong, "SELECT lat, long FROM cities WHERE name = $1", name)
    if err == nil {
     return latLong, nil
    }

    latLong, err = fetchLatLong(name)
    if err != nil {
     return nil, err
    }

    err = insertCity(db, name, *latLong)
    if err != nil {
     return nil, err
    }

If you just append if err != nil blocks everywhere without reasoning about the context you're probably doing it wrong.

Handle(err)

Kubernetes is over 1.5M loc and I've not seen problem with error handling.

can you build some utility function check_r, which will panic if found error code, so your Go code will look like:

latlong := check_r(getLatLong(city))

This talk on YouTube seems to suggest that not everything is all hunky dory with Zig as a C/C++ compiler (with reference to libc) but I cannot remember any details since it has been almost a year since the talk was published.

I wonder if things have changed? Does anyone know?

Zig can link against libcs without major issues.

I also think Google's ranking is fair in this case, assuming you want to know most high quality information about "how to iterate through a dictionary". I certainly would prefer this kind of a RealPython article with a table of contents so that I can find exactly what I am looking for.

I do think Google (and the web in general) has started to suck because of SEO spam, and generally agree with the authors premise. Searching for recipes suck, searching for reviews suck, searching for places and events also suck.

I just think this particular instance is a bad example. RealPython values your time, and I wish there were a lot more websites that valued my time too.

I guess they wanted an answer to their specific question and absolutely nothing else? That might work for something as simple as “iterate through a dictionary” but in many other cases the full context is useful so you can figure out for yourself whether the immediate answer actually solves your problem.

Was the first 20 paragraphs on what a dictionary is really useful? No, it's unnecessary verbiage that anyone clicking on an article with the title knows.

If this proposal is accepted, I personally think Zig will drop to the popularity level of Hare or other extremely niche languages. Getting my colleagues to even try Zig out required me sending them articles about how Uber was using it in production. There is no way my colleagues would even have given it a second thought if it didn't have immediate value to their existing projects.

But I get where the proposal is coming from. LLVM compile times can seem awful, and there's lots of neat optimization tricks you could implement with your own byte code. And dealing with bugs in LLVM is basically a no-go, I've seen this happen in the Julia ecosystem as well.

If my recommendations are worth anything, I think Zig should

1. Use a custom bytecode for debug builds - fast build times, fast debug times etc 2. Use LLVM for release builds - fast runtime performance, slow release performance

If they can manage 1.) while still maintaining support for cross compiling C/C++ (just pass that part off to LLVM?) I think that might be the best of all worlds, with the tradeoff that there's additional backend code to maintain.

As one of the folks dealing with LLVM bugs in the Julia ecosystem.

Yes it requires a distinct skillet different from working on the higher-level Julia compiler and yes it can sometimes take ages to merge bugfixes upstream, but we actually have a rather good and productive relationship with upstream and the project would get a lot less done if we decided to get rid of LLVM.

In particular GPU support and HPC support (hello PPC) depends on it.

But this is also why we maintain the stance that people need to build Julia against our patchset/fork and will not invest time in bugs filled against Julia builds that didn't use those patches. This happens in particular with distro builds.

There are so many comments in that thread advising not to use Google Domains (including my comment).

No metaprogramming in the language meant we had some parts of the code that were written in pascal to generate pascal code before compilation of the main project.

The code was so verbose, and to get the same thing done in alternative languages would have easily been twice as shorter.

Refactoring always took twice as long as I thought it would. Just moving semicolons around was enough to break my concentration when I was in the flow.

I think the kicker was identifiers being case insensitive. That alone would have been enough to drive me crazy. People complain about Nim's case insensitive features a lot, but Nim's implementation is actually good and orders of magnitude better than Pascal's.

Also hiring a good pascal programmer was next to impossible for us at the time.

I don't know why anyone would pick Pascal today over Nim, Zig, Rust, Julia, Go etc.

Weird...if you are talking about Generics, FreePascal has them and work just fine, plus it compiles instantly!

Here's a demo:

    program UseGenerics;

    {$mode objfpc}{$H+}

    type
        generic TFakeClass<_GT> = class
            class function gmax(a,b: _GT): _GT;
        end;

        TFakeClassInt = specialize TFakeClass<integer>;
        TFakeClassDouble = specialize TFakeClass<double>;

        class function TFakeClass.gmax(a,b: _GT): _GT;
        begin
            if a > b then
                result := a
            else
                result := b;
        end;

    begin
        { show max of two integers }
        writeln('Integer GMax: ', TFakeClassInt.gmax(23, 56));
        { show max of two doubles }
        writeln('Double GMax: ', TFakeClassDouble.gmax(23.89, 56.5));
    end.

> Weird…if you are talking about Generics

But aren’t they very clearly talking about metaprogramming, which is a completely different thing than generics?

    {$MODE DELPHI}
    {$modeswitch advancedrecords}
    type
      TMatrix<T, R, C> = record
        fCoordinates: array[R, C] of Double;
      end;
    function mul<T, R, X, C>(A: TMatrix<T, R, X>; B: TMatrix<T, X, C>): TMatrix<T, R, C>;
    var
      i: R;
      j: X;
      k: C;
    begin
      Writeln('yep');
      Writeln(High(R)); // 3
      Writeln(High(X)); // 4
      Writeln(High(C)); // 3
      for i := Low(R) to High(R) do
        for k := Low(C) to High(C) do begin
          Result.fCoordinates[i, k] := 0;
          for j := Low(X) to High(X) do
            Result.fCoordinates[i, k] += A.fCoordinates[i, j] * B.fCoordinates[j, k]
        end
    end;
    type
      R1 = 1..3;
      R2 = 1..4;
    var
      A: TMatrix<Double, R1, R2>;
      B: TMatrix<Double, R1, R1>;
      C: TMatrix<Double, R2, R1>;
    begin
      mul<Double, R1, R2, R1>(A,B); // should fail because B would have to have as many rows as A has columns--and it doesn't.
      mul(A,C) // does not work even with a right-size C--even though it should
    end.

The first bit is an interesting case and i wonder why it happens. It seems the root cause is that it considers the two type specializations equivalent as even ignoring the generic functions something like "A:=B" is allowed. I trimmed the code down to this:

    {$MODE DELPHI}
    type
      TMatrix<R, C> = record
        X: array[R, C] of Double;
      end;
    type
      R1 = 1..3;
      R2 = 1..4;
    var
      A: TMatrix<R1, R2>;
      B: TMatrix<R1, R1>;
    begin
      A:=B;
    end.

I'll check against latest trunk later and if it happens i'll file a bug report.

I also tried

    {$R+}
    type
      R1 = 1..3;
      R2 = 1..4;
    var
      a: R1;
      b: R2;
    begin
      b := 4;
      a := b;
      Writeln(a)
    end.

However using the ranges for arrays is not compatible, if you have a A: array [R1] of Double and a B: array [R2] of Double you can't assign one to the other.

* The language has evolved. Delphi's pascal compiler has generics, lambda expressions for both proc and function, it has containers, map and filter functions.

* Design-time: You know how your code will behave without running it, as you are dragging and dropping components. It will draw data from your database and show it in dropdowns and grids. You have fine-tuned control ober widget alignment and anchoring .

* Data modules: Having your orm and data layer as composable components enforce separation of ui and db operations.

* Devexpress: They make the best grid components by far. I use their web products as well.

For the cases Delphi is a great choice, I'd steer clear as far as possible from julia, zig, go and nim. Maybe C# comes close.

When writing desktop apps probably the familiarity with well known IDEs such as Delphi or Lazarus makes the difference. Unfortunately decades passed, still nothing comes even close to them for rapid GUI development. Should one day Lazarus support different languages such as the ones you mentioned, we'll probably hear a rumble around the world. However things in certain fields progress much quicker, and I wouldn't be surprised at all if in some time we could use AI to analyze a drawing then create the corresponding desktop interface description to be linked with non GUI code.

1. https://pascalabc.net/en/ (PascalABC) 2. https://github.com/pascalabcnet/pascalabcnet (PascalABC GitHub)

For non-GUI apps, sure probably Nim, Rust or Go.

When were the last time I code in Swing/JavaFX? 4 or 5 years ago, perhaps. The 3rd party libs available for Delphi/FPC are more than enough for my needs.

Maybe Pascal isn't good for large code bases, but the same is true for Python, too. And nobody hates Python.

It's a language which had a reason to exist 25 years ago, but has since been surpassed in every way by other faster, more robust, more compatible languages that don't have such quirky syntax. So a lot like Pascal actually. (To be fair to Pascal, its syntax wasn't anything as inconsistent and frustrating as Python's.)

IMO JavaScript should be the default for any Python use case. It has the same deceptive veneer of beginner-friendly dynamic behavior, same kinds of footguns; but at least JS has a single package manager, much faster optimized engines, and you’d have to learn it for front-end work anyway so it has long-term dividends.

The language has way too many gotchas. I wish they could shed all the legacy aspects to it. My experience with Python, along with many other folks, is that if we don't know something (API, syntax, etc), we often just guess it and it turns out to be right. Fairly intuitive.

Agree with the other commenter: Using pip + venv tends to solve the majority of packaging problems. In my career I deal with a Python dependency headache once every few years.

> and you’d have to learn it for front-end work anyway so it has long-term dividends.

Except when you don't do front-end work ;-)

I patiently wait for the moment in which we can manipulate DOM from within Weabassembly. Meanwhile I shamelessly push for Blazor for front-end, wherever I can.

The same could be said about C++, but yet, here we are. Stroustrop's quip comes to mind: "There are languages people complain about, and languages no one uses". Just look at how much people complain about JS.

I don't know how old people here are, but from the early 2000's till probably the mid 2010's, Python really was the great language, with few alternatives - at least when you consider the libraries available for it.

It's not an accident that people began using it heavily for numerical computing. The only viable alternative at the time was MATLAB.

The most reviled languages are often previously loved languages that made writing code easier at the cost of reading and understanding it.

Team 1 secretes reams of instant legacy code, but get money and promotions for shipping it. Team 42 gets handed a steaming pile of manure that is beyond understanding. They then pick up the pitchforks because it is obviously the language's fault.

So, yeah, it isn't the language so much as the average incentives and behaviors around development.

You claim someone actually loved Objective C or Perl? Or even Scala?

I also like how Objective-C++ can mix in C++ code bases. It's an amazing chimera of a language.

$tongue in @cheek

The problem with Objective C is that it requires skill. The average developer really is better off using a more remedial language like Swift.

So here I am as the team Senior, looking at current and future team members and deciding on whether to be selfish and choose what's good for me, or trying to figure out what makes something good for the team. Is it better to pick something with a large hiring pool? Is it better to pick something with fewer footguns? Is it better to pick something with higher performance? Is C# really ok if we need Mac support? Is Swift ok for one-off glue apps that run on Linux? Is Zig too young? If a team of five has a Java geek, a Rust zealot, a C# fan, and somebody who only knows Python, can we just agree to all learn and use Go? If I know my replacement will undo whatever I choose, does it really matter?

I love Zig and Nim but constantly pick C# or Go.

If time, money, support and performance are not an issue, you can pick anything but I guess someone of the above will always be an issue.

That means x86, assembly, C, C++, C#, Python and half of Javascript. For Javascript I mean half because I enjoyed doing simple things in JS on front-end long time ago, but these days I kind of dislike JS frameworks and I've learned them because I had to after I signed some contracts. I could have stayed 100% with backend work, but now is too late to complain.

I managed to steer clear of Perl, Objective C, Cobol and other languages I don't enjoy. I managed to learn F# and some Ocaml which I would like to use but never got the chance (personal projects excluded).

I've hated the poor decisions my predecessors had to make, the corners that were cut. I've hated that it's not maintained or documented. I've hated that it doesn't have tests.

Never have I hated the language.

Pray tell, which ones are those?

Unfortunely most complaints about Pascal keep being reduced to that 1970 version of the language.

[0] https://people.inf.ethz.ch/wirth/ProjectOberon/PO.System.pdf

But yes, modern stuff should not be judged by the 1970 edition. I got soured on Pascal by having to use an ISO standard compiler on an embedded system; it was painful in several areas. But I shouldn't judge modern C by pre-ANSI C, or modern C++ by cfront. So, while I still say that ISO Pascal was deeply flawed, I shouldn't hold that against all Pascal versions.

https://dl.acm.org/doi/10.1145/1238844.1238847

I would take almost any other language, including Pascal, over Python for anything beyond a page of code.

Even then, how can installing those tools harm your system? You can always use pipx and have each tool be installed in its own virtual environment.

We use it because we don't have any alternative. I'd really love to have a faster tool though.

The more I use julia, the more I hate python. Which is a lot by now.

Can you elaborate on this? In what ways specifically is it better?

If you mean packages as modules, other languages predate Modula-2 in that matter.

Pascal evolved into Modula-2 and then Oberon which is both smaller and more powerful.

https://miasap.se/obnc/oberon-report.html

Free Pascal comes with pas2js which "transpiles" Free Pascal code to Java Script and is written using fcl-passrc so it should have enough functionality to parse most FPC code.