Clearly this project failed for either

  1. scaling for a very specific use case, or because
  2. it hasn't even found product-market fit 

Blaming the failure or designing for scale seem misplaced, you can scale while remaining agile and open to change

I think, that complexity cannot be eliminated, but it can be hidden and distributed, using the right abstraction

that being said C++ being a big language adds complexity (stemming from the language itself, i.e. stemming from the tool)

So you can use a complex tool, to make a complex task simple, or a simple tool and keep the task more complex, requiring more steps etc..

But with C++ its a complex tools, that while it takes some complexity from the task, I think it adds enough complexity, that could outweigh the complexity it reduces

We need better languages, C++ is not it

> that being said C++ being a big language

Rust has become fairly big now, no? Is there some objective metric that can show Rust is a "smaller" language (I bet it is, but I don't think it's by a lot)?

There’s not really any metric of a language being objectively “big” or “small” but I could point at several features where the Rust feature is significantly less complex than the C++ one. Additionally, C++ has more features that Rust doesn’t than the reverse.

Raku is now a completely separate language from Perl and I think that while Perl still seem to be used, Raku usage is even smaller

I am really impressed of how Raku developers keep their motivation to work on it

And I am a bit curious to know if Proxmox is interested in Raku at all, or are they only using Perl

Why are you reposting these sentences with additional errrors inserted into them?

i was rephrasing , saying what i understood (thinking i was making it clearer)

you are suggesting, i misunderstood the original text , if that is true i blame the original of being obfuscated

It definitely is no paragon of clarity or careful editing.

why zed for elixir/phoenix?

i thought the mainly maintained editor plugin was the one on vs code

i love emacs, but nowadays i would argue most languages are far better supported outside emacs, with few exception like lisps

so being strictly emacs, will really limit your choices, and honestly waste your time

Perhaps its better to say there is very little "out of the box" wrt language support, but otherwise I am not quite sure what you mean for >90% of situations. Eglot + the right lsp server gets you really far these days.

I currently rock a setup, as a Java dev, where I do as much as I can in emacs but have a binding to jump to the current line in Intellij. I find myself switching between the 2 without too much friction. It's mostly just committing in Intellij and having pre-commit checks analyze my changes.

What do you love about emacs, if I may ask? Bit hard to guess what you could mean, given your subsequent claims there.

Not original poster, but I will say that I specifically love Doom emacs.

It is really easy to navigate only from the keyboard. It uses vim-style keybindings for everything, so you don't have to do all the weird hand contortions that happen a more traditional emacs-style interface. When you do access functions, they are handled with multi-keystroke gestures while you're in command mode. The keystrokes are effectively navigating through a menu tree. There's a minibuffer at the bottom of the screen to help you navigate, so you don't have to rote memorize everything, but anything you do use often enough to memorize can be accessed in 2-4 keystrokes.

Some of the plugins are just amazing. Projectile - a project management and navigation sidebar - has really good ergonomics compared to what I'm used to with graphical IDEs. Magit is a fantastic and powerful git interface, and the only in-editor git interface I'll actually use; in any other IDE I'll just use git from the command line.

I've got to mention orgmode, of course. I'm not sure I can articulate why I like it so much; it's kind of like a vi-style editor interface where it's hard to grok without putting in some time, but those who do put in the time tend to fall in love.

I will agree that emacs's language support is spotty compared to vscode, but in this day and age that's true of any editor that isn't vscode. And it also lacks that really deep melding with the language that you get with IDEs that are all-in on one platform like IntelliJ IDEA and Visual Studio. But in general it's kind of an outlier in terms of popularity-to-polish ratio.

well, functional languages with recursive types, are very good at representing binary trees

https://cs3110.github.io/textbook/chapters/data/trees.html

The problem with F#, Clojure and Elixir (hosted languages)

For F# , you need some basic C# knowledge For Clojure, you need some basic Java knowledge For Elixir, you need some basic Erlang knowledge

I like all 3 languages but usually each vm have a primary language, and each hosted language eventually become hosted on that primary language not the vm

I understand that for many task simple, to medium complexity, you might not need that, but it seem as you try to be more advanced you hit the wall of having to learn you host vm primary language

> For Elixir, you need some basic Erlang knowledge

As an Elixir programmer, this does not resonate. Basically the only thing I've ever felt I needed to understand Erlang for was ets, but let's be honest, that's not really proper Erlang but just the terrible ets query syntax. And all this requires is "ability to read enough erlang term syntax to be able to understand the ets manual". I don't think I could write a single line of correct Erlang by heart.

I feel like that's different in F#, where you still need to know lots of .NET internals which are all documented in C#y terms with C# examples etc. Elixir wraps pretty much all good Erlang/OTP internals in nice Elixiry modules, which solves that quite nicely.

Elixir has its warts but this really isn't one of them.

Thanks. I know a bit of Erlang (put some effort into learning, but never used it in real life, probably forgotten what I learned) and want to learn Elixir which seems better suited to what I want to do in the short to medium term.

Erlang is not a difficult language. Unusual, but actually quite sane syntax. If you are already familiar with Elixir it would probably be pretty easy to learn the basics of Erlang.

I've written a lot of Clojure now, and I've managed to avoided learning any Java really.

That’s a reassuring thing to hear as a new clojure learner who has little interest in java.

What bits of java have you ended up needing? Like do you often use java libraries that don’t have clojure wrappers?

I feel like I’m often running up against little things. I’ll google “how to do xyz in clojure” and the top SO answer is to use a java library that apparently everybody already knows about, cause so many clojurists came from java first!

> What bits of java have you ended up needing?

The same with Clojurescript and JS (and probably with Clojure-Dart) - you have nice interop with the hosting platform. The need for learning anything about Java (while writing Clojure) basically boils down to finding API documentation for a specific class and simply using it. That's all. That's all you'd ever need.

> For F# , you need some basic C# knowledge For Clojure, you need some basic Java knowledge For Elixir, you need some basic Erlang

Honestly, none of this really rings a bell. Having used all three options, I never felt that. Well, I already knew C# before getting into F#, but honestly, it felt like my C# knowledge at the time was more of a distraction. Been using Clojure for nine years, never done any serious Java and have not felt any need for it. Not knowing Erlang wasn't a problem with Elixir, like at all.

I worked with Elixir for over five years without knowing anything about Erlang. I know Erlang now, but only because I was interested in learning it, not because I needed to do so to write Elixir code.

Well I do agree that this statement sounded bad, for me it sounded

"how can they treat her this way (inhumane) she is not a poor mexican"

its not ok to treat anyone inhumanely, no one ever, not just people in specific situation or from specific background

Julia is not a scripting language, or in other word, Julia scoping rule are not scripting friendly

currently if in a file i have

    local s = 0

    for i = 1:10
        t = s + i
        s = t
        println("$s")
    end

    println("$s")

and I execute this file, I will get an error

    ERROR: LoadError: UndefVarError: s not defined

Note if you're doing this in the global scope, the local declaration on `s` will cause it to functionally not exist.

You can write this as either

    s = 0

    for i ∈ 1:10
        t = s + i
        global s = t
        println("$s")
    end

    println("$s")

or

    let s = 0

        for i ∈ 1:10
            t = s + i
            s = t
            println("$s")
        end

        println("$s")
    end

Another alternative is putting the code in a function and calling that function.

    function test()
        s = 0

        for i = 1:10
           t = s + i
           s = t
           println("$s")
        end

        println("$s")
    end

    test()

For anyone curious, the rationale for this scoping is explained in the docs. Essentially it's to prevent the so-called spooky action at distance.

while of course you're correct on a technical level, I do tend to agree with the statement that Julia is not particularly friendly to bash-scripting-heavy workflows

Meh. For my purposes, Julia strikes a quite nice balance of fussiness versus permissiveness.

Sure, there's things where I find it too fussy and I wish it'd go "yeah yeah I get what you mean" and there's also things where I find myself thinking "man, I really wish you had complained to me about that, it was clearly a bug / bad style!"

But all-in-all, I find it's a language that mostly gets out of my way and lets me code, which I find very useful and nice for scripting.

I think if one finds things like scoping rules annoying for scripting, that might just come down to just knowing and being more familiar with another language that has different rules.

See, I find it the opposite - superficially fussy, but it lets the silliest things slide. I don’t want my function to struggle with type instability in some contexts (perhaps only showing up deep in a physics simulation or motion planning algorithm) and allocate a bunch of memory, I don’t want it to compile in the first place if that’s possible.

As we've been discussing in another thread, it's possible! One can "opt out" of Julia's dynamic behaviors on a function-by-function basis using the JET.jl tool for static analysis: https://aviatesk.github.io/JET.jl/dev/optanalysis/

Why not make this the default everywhere? Well, there are a lot of scientific use cases where it's convenient to have Python-style dynamic typing and interactivity. A cool thing about Julia is that it allows that, while _also_ allowing to achieve high-performance, all within a single language.

For the record, I do also love the static type system and overall design of Rust. But for my day job (research in numerical methods and computational physics), I find Julia to be the most efficient way to get the job done -- rapid algorithm prototyping, data analysis, plot generation, etc.

It may be worthwhile to understand where dynamic typing is helpful since this gets mentioned a lot. Python and other dynamic languages are increasingly reliant on static type checkers.

sorry - why would you expect a local declaration to be in scope for other code?

s is defined in the statement and then is undefined out of that statement because there is no other scope for it - it's at top level. just write s =0 and all is well as s exist in the global scope where your code lives as well...

OP should've written just `s=0`, yes. Because showcases their complaint better since, although works in REPL, also fails when in file. (It's also the example given in docs[1].) Now, it looks like they tried to make it fail.

[1]: https://docs.julialang.org/en/v1/manual/variables-and-scopin...

Shouldn't the language flag that using local in that scope is an error then?

Yes - the error reporting has always been one of my complaints about Julia (although it's hugely improved). I think that the Julia dev community are really really interested in cool language features and optimisations but much less empathic with numpties like me that can't understand why their code crashes. More work on this would be much better.

Although it's a bit of an challenge to get the interpreter to understand which thing that's out of scope should be in scope for the code to work (because it's all out of scope..)

https://github.com/JuliaLang/julia/issues/57483 yes, yes it should.

well done that man

Right, but did anyone say the Julia was a scripting language?