This looks like a really thorough examination of async-await i.e. stackless coroutines, but it doesn’t seem to cover Lua-like stackful coroutines.
Apologies if it does and I’ve glanced over it - but if it doesn’t, is there another resource that compares stackful coroutines to stackless in a similar way?
Stackful coroutines are cooperatively scheduled, unlike traditional threads, and context switch much more inexpensively. It is the reason people write stackful coroutine libraries instead of just using threads.
> one should not use LLM services for confidential or proprietary information
That’s obvious, isn’t it? Just like you wouldn’t upload your confidential documents to an online spellchecker, or your proprietary code to an online compiler?
I worked in a EU company that was developing a product competing with one of Microsoft offerings. All the code was hosted on GitHub, we used Azure for hosting and all the internal communications were in Microsoft Teams.
To me it looked absurd. But I was almost the smallest cog in the corporate structure, so I never asked what were the reasons for all these decisions.
> did you feel that whitespace for lexical scoping made the job of writing the lexer significantly more complex?
Significant indentation requires a more complex lexer because it means the lexical grammar is no longer regular. The lexer can't just be a finite state machine, instead it has to maintain a stack of previous indentation levels.
But I don't think many modern languages have a regular lexical grammar anyway. Without significant indentation, some other features still require the lexer to maintain a stack - e.g. string interpolation (Python's f-strings).
> almost seems like Go is trying to become some sort of C# or Java Frankenstein
The original Go team was trying to avoid this:
"Java, JavaScript (ECMAScript), Typescript, C#, C++, Hack (PHP), and more [...] actively borrow features from one another. They are converging into a single huge language." [0]
That team has since moved on, and now Go has begun to join that convergence.
The problem is that most programmers seem to want to write Java, more-or-less. New, simpler languages come along, but once they get popular, the pressure is on to turn them into Java-likes. It happened to Python and now it’s happening to Go. It takes a strong will for language maintainers to say “no”, and their language will suffer in popularity as a result - see, for example, Ruby.
I would argue that languages like Java (C#, Kotlin, etc.) strike a very good compromise between modeling ability and comprehension, which is why they are popular and people gravitate toward them.
You can have more complex languages like Scala that provide stronger modeling ability, but at the cost of complexity. Golang started off as extremely naive/simplistic, and is now converging in some ways. But it still has a ways to go: no generics on interfaces, no unions/ADTs, no pattern matching, no proper enums, error handling leaves much to be desired, and much more.
> I feel like that "full superset of Python" part was part of the appeal of Mojo.
It absolutely was, but IMO was never going to happen. Python has a reputation as a simple language, but it really isn’t. It’s a very complex language hiding behind friendly syntax.
I think once the Mojo team realised that, they had to adjust their expectations.
I know Python since version 1.6, the reputation I guess is mostly because a large majority doesn't read the well written documentation, and mostly use beginner level constructs.
Python is C++ level complexity, when one fully understands the runtime, its dynamic capabilities, the C API, the standard library, the OOP model reboot on 2.0 with new style classes, all breaking changes that happen between releases, and naturally one doesn't know before hand what are the exact requirements to execute any random Python script.
That’s insane, for a language that seems to be Temu-Python.
OTOH Python itself is the world’s most popular programming language, yet has only recently had the money to support more than a single full-time developer.
Julia is actually quite nice for this. If you prefer a python-like approach consider Triton from openai, numba (https://numba.pydata.org/) or CuTe DSL from Nvidia.
As someone who writes GPU kernels in Julia, yes it is. But Mojo is one of the few alternatives based on technical merit alone. Each language is better in different metrics, and it could be argued either way.
License-wise, Mojo reminds me of paid Borland compilers that were in vogue before I was born. Even if it's open-sourced, what incentive does Qualcomm have to maintain a happy path for Metal deployment? Mojo might actually be the best way to program Apple GPUs (on a technical level) and it would still lose due to politics.
If it's open sourced, Qualcomm won't need to worry about Metal support. If Mojo is popular enough, Apple might get involved. If not, no doubt there'll still be Apple users that want Mojo support, and are willing to work to get it.
It almost feels like they were paying more in the hopes of owning the next LLVM or Swift based on the name on the tin rather than basing the price on the product itself.
I like significant invitation, but I still wouldn’t choose it if I was designing a language today.
Functional-style programming has become much more popular since Python was designed in the 1990s, and there doesn’t seem to be a good way to have Python-like significant indentation and also support true anonymous functions.
Haskell's significant indentation is, in my experience, much worse than Python's at fading into the background by matching what you would have done anyway.
As I understand it, Mojo’s goal is to be able to match state of the art performance for parallel algorithms and be able to use the exotic GPU hardware. A functional style is not necessarily productive in that context.
> their overall goal is to be a fully native superset of Python
Not any more. That was the initial announcement, but I think then somebody actually looked at Python and realised what a complex language it is - so they refocused on being a Python-like language. Python has a reputation for being a simple language, but in reality it isn’t at all.
Honestly that doesn't really feel like a glowing endorsement of the language. "They announced a crazy goal, then rolled it back because they grossly underestimated how hard it was" doesn't give me confidence in either the long-term design or the people making it, and I feel like "a Python-like language" is both a lot less interesting and a lot more subjective. If the discussions in this thread around significant whitespace aren't already an indication, which parts of Python people think are good and which aren't will vary by person, so without saying more it's hard to tell whether it's a a language someone will love or hate.
To preempt all of the inevitable responses: yes, I'm aware that this was started by the same guy who started LLVM and Swift. That doesn't automatically mean anything he comes up with will be great, especially when it's specifically trying to be "like" a language that doesn't really have much on common with either of those; there are plenty of instances of very smart people having an overabundance of confidence when jumping into something they assume they'll excel at and getting humbled. I'd also argue both Swift and LLVM have some common criticisms that very much are in line with the same concern I've expressed here (i.e. long term design suffering due to expanded or pivoted scope; even the name LLVM alludes to some of that history of having a somewhat different goal originally). His name is enough that I'll probably always click to take a first look at anything he comes up with, but I'm not going to ignore things that seem like issues because of that either. Smart people don't need to held to a lower standard because their work should be able to speak for itself.
That is a mistake. Being fully compatible with Python was a big selling point. Now they are just another knock off that wont get enough traction to make a dent. Unless this GPU programming thing is so amazing it takes over the industry with one small niche feature, guess that is the hope.
Has the conversation that originally led to the counterexample been released? Surely it was similar to this one, also driven by a highly knowledgeable mathematician.
No AI would have been able to find it if asked to "Find a counterexample to the Jacobian conjecture. Make no mistakes".
Apologies if it does and I’ve glanced over it - but if it doesn’t, is there another resource that compares stackful coroutines to stackless in a similar way?
reply