Go is known by the speed of it's compiler, doing extra work during the compilation would slow it down. I would not mind either to have a "release" flag that would take minutes and produce a more optimized binary.
As proven by D, OCaml, F#, Delphi, Ada, C++23 (with modules, VC++/clang 18), it is a matter of toolchain.
What we need is a Rust interpreter, or having something like Cranelift properly integrated, to only depend on LLVM when doing release builds on the CI/CD.
Having used Scala for some years with it's abysmal compile speed, I fear it has to do with complexity of the language and features, it was "implicit" in Scala, it might be the borrow checker in Rust (IANACG)
Note that I left out Scala, while I included other languages of similar complexity, exactly because improving compile times has never been a major focus in Scala land, versus features.
Example, development effort wasted on Scala 3 Python like syntax.
There are several performance reports that show that the major culprit is the pile of LLVM IR sent to the backend.
I'm using Nix and Fish and have been for a year or two now. I remember some issues initially but NixOS and home-manager have boolean options to enable Fish and it Just Works nowadays.
This means that the threads can't be blocked forever. The way Go scheduler work is to check during function calls if the current goroutine has executed for some period of time, after that the scheduler will remove the goroutine from the thread and open space for other goroutines to execute.
But if you're doing a loop without function calls, imagine a for {}, in this case, the thread will be locked forever.
Now with 1.14, this don't happen anymore. In my opinion the expected result will be better tail latencies.
Really can't understant why Lua isn't more used. It play the same role as Ruby, Python and JS and is very fast, at least, much more then Ruby and Python.
Not just that, but Lua is very conservative about adding new language features so a lot of quality of life things are missing - no ternary operator, verbose lambda syntax, the incoherent mixing of arrays and dictionaries, bad default scoping, stuff like that.
If you are willing to fork Lua (and it's been done---one example is Ravi, which brings static typing) you can fix the verbose lambda syntax (http://lua-users.org/lists/lua-l/2017-04/msg00387.html) and add ternary operators (which I haven't missed). I haven't found the mixing of arrays and dictionaries that bad in practice (and I do a lot of Lua programming at work) and the default scoping ... yeah, I can see that (I've learned to deal).
Incoherent? 10 years of Lua development, never had a problem with it. In fact, the ability to use a table as either an array or a dictionary is one of the great features of the language. Most newbie Lua coders get over the differences pretty fast. For everyone else, there is lua-enumerable.lua ...
Well, 10 years isn't the problem, it's picking it up in the first place. For example, the whole pairs/ipairs thing falls out of that original weird decision.
I love Lua. It's embeddable, it's written with newbie-friendliness in mind... but I still think it has flaws that I wish we'd see fixed. To me, the biggest one missing is just some simple convenience stuff for higher-order-functions - like I said before, the lack of a ternary "inline if" which is super-handy for writing one-line lambdas, and the verbosity of its lambda syntax.
I dunno, I think that the distinction between pairs/ipairs is quite handy - there are times when you want to use an array, a list, a dictionary, a sparse array, a sorted array, and so on. Lua's tables are so flexible that it can be used in all of these cases quite handily - of course, the programmer has to pay attention to how he's using those tables, though. I think thats kind of a strength, but ymmmv ..
It's not that libraries are not available, it's that they are not _standard_. Python has much healthier and more coherent community partially because everybody started out with same carefully chosen building blocks. With Lua you either build your own or bring in dependencies from libs and frameworks.
Regardless, I'm enjoying Lua more and more and it's becoming my go-to language for prototyping and exploring concepts. The code just flows more naturally than in other languages.
I think there is something else to this. Most highly productive Lua applications I've seen, been involved in, &etc., are bound to system-level libs/api's, etc. So the thing about Lua as a scripting language like Python, is that you can use it like that. But the major power of the language is when you apply it by glom'ing it into some bundle of C/C++ libraries that are, indeed, BYO-batteries...
Like, Lua is bring-your-own battery, true. For everything else, there's Penlight/luarocks, though.
Isn't it the same in many other languages? For a Ruby project, you usually have to use a dozen gems to get started. For a javascript project, it's at least two dozens of npm packages
It's much smaller community than Ruby or Rust... People are very friendly and most of learning content is freely accessible. Most of us use LuaJIT (at least on desktops) but many are worried about its future, as lead genius has stepped off and few other people can understand the internals of LuaJIT.
There's a very nice "package manager" for downloading and installing modules, called LuaRocks. On the other hand, lack of tooling is a big issue. ZeroBrane seems to be only decent IDE with debugging support.
There's ton of stuff in libraries and Lua extensions, you just have to be careful about what you are integrating. You might for example end up with two incompatible implementations of class system from two different libs.
I've written a few programs in both Lua and Python, and the Lua is generally almost twice as long. Lua tends more forgiving of mistakes which I'd rather be errors, like a missing table key. So though it's great in some ways, it's not my first choice to get something done with.
You are mainly talking about web development.
Golang is young and we dealt with the same problems at earlier versions of ruby and rails.
But, outside web development, in most of my needs, golang was a better choise than ruby.
Saved some servers running golang instead of ruby and had cut significantly the month cost of my startup.
