The big difference is that if a competent plumber looks at a sink, it will take them 30 seconds to figure out. If a competent programmer looks at a new codebase with 30000 lines of code, it will take them 6 months to understand it, and then still be missing 80% of the details.
The other difference is that for most modern ice, you get plenty of torque, but only a quarter second after you asked for it due to turbo lag. With an EV, the torque is instant.
one interesting thing is that you will fairly frequently see professional orchestras be out of phase with the conductor, but everything still works out.
Is it? The fundamental reason the war on drugs failed is that drugs have relatively inelastic demand. Someone addicted to meth will find a way to get meth if it costs $10 or $500. Software exploits aren't like that at all. They are a tool used by gangs and governments that are only useful if they cost less than they're worth.
Imo, the solution is to stop using C/C++ for high performance applications. Today's computers are diverse enough that distributing compiled binaries leaves a ton of performance on the table.
The short answer is that changing the type system to allow multiple inheritance (traits) involves solving some really hard and open-ended problems (eg method specificity). Solving this is probably breaking, and requires a ton of work on a problem that might not even be solvable. If I had to guess it will be solved by the language that replaces Julia in 20 years.
Short list of current priorities (in no particular order)
Making it easier to interface with the compiler (this is step 1 on better ability to static compile/debug)
Better garbage collection
More performance
Reducing the memory footprint of small strings
Lowering the overhead of multithreading
It's worth noting that Julia doesn't really have a core team. A lot of the development is done by a pretty large community of developers without any central management.
This is doable in Julia too. DifferentialEquations.jl has python and R bindings. I expect more to follow as Julia starts getting more best in class packages.
Is there anything you think that prevents Julia from being general purpose? The main one I run into is that the garbage collector needs work, but fundamentally I don't think there's much that keeps Julia from being good as a general purpose language.
I think Julia has a pretty good path forward since it is often faster than C++ (especially once you consider language interop overhead), and it is much more pleasant to write than c++. Since Julia and most of the packages are written in Julia (for the most part), Julia makes it really easy for users to become developers. Python and R have much bigger barriers to entry since users will usually hit a binary blob, which makes it much harder to interact with library implimentations.
The hard part is making it produce the correct results even if the user does something like change the definition of +. It's not un-solvable, but it needs a couple hundred hours of work by people who are very busy.
It totally can make sense in third world improved regions, just not in homes (and/or possibly not on all the time). You could pretty easily run a small business off of 100 mb down, 50 up, and in that setting, you can probably power it with a small solar panel and just turn it off at night.
I haven't used lisp a ton, so I might be missing something here, but as I understand it, multiple dispatch in lisp is opt in. The downside of this is that since it has a performance penalty, people didn't use multimethids for core functions like +, so you lose the benefits multiple dispatch offers.
One other really good example is BLAS. Since it is a C/Fortran library you have 26 different functions for matrix multiply depending on the type of matrix (and at least that many for matrix vector multiply). In Julia, you just have * which will do the right thing no matter what. In languages without multiple dispatch, any code that wants to do a matrix multiply will either have to be copied and pasted 25 times for each input type, or will have 50 lines of code to branch on the input type. Multiple dispatch makes all of that pain go away. You just use * and you get the most specific method available.
The key to make multiple dispatch work well is that you shouldn't have to think about what method gets called. For this to work out, you need to make sure that you only add a method to a function if it does the "same thing" (so don't use >> for printing for example). To Dr the benefit of this in action, consider that in Julia 1im+2//3 (the syntax for sqrt(-1)+2 thirds) works and gives you a complex rational number (2//3+1//1 im). To get this behavior in most other languages, you would have to write special code for complex numbers with rational coefficients, but in Julia this just works since complex and rational numbers can be constructed using anything that has arithmetic defined. This goes all the way up the stack in Julia. You can put these numbers in a matrix, and matrix multiplication will just work, you can plot functions using these numbers, you can do gpu computation with them etc. All of this works (and is fast) because multiple dispatch can pick the right method based on all the argument types.
I think a lot of it is that this is a series A for a 6 year old company that is already making money. Most other startups would be on series B, so comparing this number to a 10 person startup for a company that doesn't have a product yet doesn't make a lot of sense.