I've had high hopes for this project since its announcement, but until it's open-source, I'm not investing any time in it. That's the only announcement I care about
Over time we expect to open-source core parts of Mojo, such as the standard library. However, Mojo is still young, so we will continue to incubate it within Modular until more of its internal architecture is fleshed out. We don’t have an established plan for open-sourcing yet.
I read this as:
"There are parts of Mojo that we are not planning to open source"
I believe that Chris Lattner (Mojo lead) has said that its going to be open-source eventually. He's followed the same process as with Swift, where they did't open it up until major design decisions had been worked out with the core team.
I can see why they might wait to open-source things, but I guess part of what gives me pause is the "parts of Mojo" statement, as in "we expect to open-source core parts of Mojo." Not "we expect to open-source Mojo", but "parts of Mojo".
Yeah – I'll wait to see how that spins out. I'm under the impression that they're making their $$$ from AI tooling, so I'm sure there will be some "secret sauce" optimisation tools that'll be held back from public release.
In my understand the sauce they want to sell is the multiprocessing/cluster management software that builds on top of Mojo. If they do it like that it would be fair game imo
Maybe you don't want the peanut gallery commenting/complaining/whatever about your architecture until you are ready (otherwise architect astronauts could inundate your comm channels with suggestions, comments, PRs, etc)
LLM inference takes up some scarce GPU time and many people are trying to use free entrypoints to build services instead of the intended paid APIs, so I understand why those services want to put limits on usage.
Programming playgrounds however are freely available for pretty much every mildly popular language, and these days many toolchains can even be compiled and run with JS or WASM so one could just serve some static files to host it. This is definitely more suspicious than what OpenAI and other ML companies are doing.
There is no parallel. If meta required you to be logged in to run local inference with llama, that might be similar. Your using openai's cloud so you're logged in.
I can understand why openai requires phone number.
With how much resources they spend on each prompt, they want to limit abuse of their systems. Also ChatGpt is not available in many countries and a phone number is reliable enough test of location.
I am myself in one of these countries, but I also care about my privacy, so I use services that use chatGPT indirectly instead: https://you.com with disposable email and https://phind.com
I dunno, remains to be proven, but if you managed a commercial python code base and could get a 2x performance improvement across the board by switching interpreters, wouldn't you at least give it a shot?
I had a few lines of python code, to count the fraction of A:s and C:s in a DNA (fasta) file adapted from [1]:
with open("chry_multiplied.fa") as infile:
a: int = 0
t: int = 0
g: int = 0
c: int = 0
for line in infile:
if line[0] != '>' and len(line) != line.count("N") + 1:
g += line.count("G")
c += line.count("C")
a += line.count("A")
t += line.count("T")
total_base_count = a + t + c + g
gc_count = g + c
gc_fraction = float(gc_count) / total_base_count
print( gc_fraction * 100 )
Result:
$ mojo run gc.mojo
gc.mojo:1:6: error: use of unknown declaration 'open'
with open("chry_multiplied.fa") as infile:
...
"open" must be one of the most used Python functions ... :/
man two days ago when i said their promise of compatibility with python was startup hype i got no traction. like duh they'll over-promise and underdeliver - it's chapter 1 of every single SV playbook.
i am friends/former co-workers with several people on the "team". doesn't mean i can't/won't/shouldn't call out startup hype when i see it. and again: the criticism has been borne out because this comment chain is off an example of an epic fail.
> This is pretty early in the development
you don't applaud someone that says they're going to do something just because they're fancy. like is this even up for debate? at such later date and time where they deliver i will be first in line to congratulate them (maybe even as a user) but not until then.
I don't see hype they outlined a roadmap and are working on it.
Not sure what fancy means in this context.
Swift Objective-C story is pretty much inline with this work.
Come to think of it I don't really remember Chris not delivering on a project.
If fancy means people who created and delivered on multiple very challenging projects I guess they are fancy.
> I don't see hype they outlined a roadmap and are working on it.
they have been touting superset compatibility very loudly and then quietly writing conservative docs and roadmaps. you really don't see that or are you just bending over backwards to give them the benefit of the doubt?
> Not sure what fancy means in this context
you don't? then what exactly are you implying/suggesting here:
> Have you looked at the team?
moving on;
> Come to think of it I don't really remember Chris not delivering on a project.
already in my memory/experience (which is only a couple of years in this area): swift4TF and chisel (or FIRRTL or whatever). you can deflect and blame org charts or whatever but if you're gonna make the rounds on the talkshow/podcast circuit and take credit on the upside you gotta eat the blame on the downside.
i'm sure chris lattner is a great, smart, genius person. i'm sure everyone at modular is. i'm sure 100MM is a whole lot of runway to deliver. but they haven't delivered yet so their claims about being a superset and/or 35,000,000xxxxx perf gains are all (at least by me) taken with a grain of salt.
I def give them benefit of the doubt. Swift4TF totally outside of what I do so no clue to what extent it was delivered. Maybe I am just too fond of the idea of having Rust features with Python like syntax and not paying enough attention to the fully compatible part as it's not something I personally care about.
I'm just saying why try to convince me I'm wrong if you haven't been paying attention to the thing you're trying to convince me about? Like how does that make any sense?
You were literally bullying this person and being very condescending and then turn around and accuse him of bullying you. Why is it ao hard for you to accept that some people might different opnions?
That was not an opinion it was an honest question.
People use past performance as an indicator for future performance thats not a very unusual concept and not really "hero worship at best and fanaticism at worst."
I gave you two examples of past poor performance and you either blithely ignored them or dismissed them as unimportant because it's "totally outside what you do". Then at the end you admitted you don't pay attention to the details. So we're either back to why are debating things you don't understand or why are you fawning.
The thing that always gets me in these pissing contests is some random decides to wade in based purely on ____ and then when I point out ____ I'm the asshole. Like isn't it clear you just shouldn't have started making claims? Why am I in the wrong for knowing/understanding and demonstrating that understanding but you're not in the wrong for just guessing?
To be fair mathisfun123 was originally responding to someone who tried it out and was somewhat disappointed by the state of things given the hype. It's a valid point.
Responding with only "have you looked at the team?" with nothing to say about the current state of things, which was what the sidethread was about, is what probably set them off since it is actually a pretty patronizing thing to say.
You want to give more leeway to the team because you think they earned the cred. mathisfun123, not impressed by the details of certain past projects, is not going to hold their breath until the current state justifies the current hype.
this is literally 2nd question I have asked
1) Have you looked at the team
2) Based on your postulate that I should not be making claims wanted to see an example of claim I should not make. As I don't think I actually made any claims.
I am not sure why this is tedious
1) is pretty much yes or no
2) is just copy paste of a "claim"
It seems quite exciting and all but I cannot figure out why they choose to impress people with marketing posts like "it is a billion times faster, oh no it is actually a zillion times faster" while their actual potential user base is waiting for license issues to be clarified.
Mojo team is avoiding this topic like a plague. I recently listened to whole Lex Fridman episode with Mojo's founder Chris Lattner [1] and I don't think they said a word about licensing. I still don't get it tbh.
I don't even understand how can Mojo be compared to Python without reflecting on Python Software Foundation which is arguably the main reason Python is such a wild success. We should do more PSF not less.
How license will evolve is unclear. I personally don't mind it starting closed to figure out a contribution model or whatever they want to sort out as long as they have clear commitment. However, the current statement for open source is so vague that I don't want to invest time on it.
I think not investing time in Mojo is the currently the correct decision. If Modular decides they have a good product and would like broad community adoption, they will make the open source and licensing decisions that would support that. They're smart and I presume aware of that dynamic, so honestly I suspect they don't want a broad community just yet.
Community management and language feature haggling is not worth the expense at an early for-profit company with an alpha language that needs to solve internal problems.
Good. It's an early alpha product. You shouldn't invest time into it. If their current licensing model prevents people from using it from anything serious, that sounds like a win.
It's a programming language. Just playing around to see what it is capable of means serious time investment. I wasn't planning on using it on production. Anyway, that was a feedback for the creators. I'll check back if they change the license.
I have never taken them seriously precisely because of this statement. They are a machine learning specific language and everyone who works in machine learning knows the speedup is cherry picked bullshit. If they're basing their marketing around an obviously false claim, why would I take a closer look?
They have recently published a blog series which started with 35,000x and ended with 68,000x [1]. The thing is anyone familiar with performance sensitive code is not looking at Python vs the other thing. They are looking for whether or not it is in the ballpark of C, Julia, Cython, Numba, etc. Those are the contenders, not Python.
I think the reason that they focus on pure Python is because a big use case would be pure Python code bases that can be incrementally ported over to Mojo for better performance, without needing to totally abandon the Python language and ecosystem.
If you read the description, they started with 35,000x, then tripled the number of cores to get 68,000x. If your triple the cores and wind up with less than twice the performance, your scaling isn't very good.
Keyword is imagine, because with Mojo you do have to write your code in a new language. You cannot use the Python parts if you want speed. That's writing code in a new language.
Didn't try downloading the SDK yet, but in the playground, seems like the "Python superset" advertisement does not hold (trying to define a class gives "error: classes not implemented yet"). Great to see progress in this space but I think the real killer feature of Mojo would be to run any existing Python program and allow programmers to incrementally adopt Mojo's syntax for targeted optimizations, and seems like we're not there yet.
Something feels so... off about this. It's a closed source product (I think? I see no where to contribute) so I can imagine the need for walling off local dev tools until they're ready for prime time, but it doesn't even seem like they are ready. They'll have you sign up before downloading some blackbox SDK that half-implements a language that they pinky-promise they won't abandon and you have no recourse to recover if they do.
If their intent is to flesh out a basic product then open things up, then I take that back, but as of right now, they seem to be pitching it as "ready to go" based on the copy here. That's a lot of trust to put with them.
Yeah, when they first announced Mojo I thought it would take a lot of wind out of Julia's sails, but I'm starting to think that's not going to be the case. Title should probably be changed to "Mojo: It's kind'a, partly here"
I don't think it really is a Python superset. They say "one language" but as far as I can tell it's actually Python + a language that integrates well with Python. Kind of like Cython.
Last time this came up I found out they're actually using CPython to execute Python code, so I have no idea how you get a 22kB static binary out of it, unless that example is just pure Mojo and no Python.
Either way it definitely feels like they keep hammering the amazing "Python but good!" line without actually explaining how it works, which makes me a little suss. Like they're scared of explaining it because then they'll have to say the thing they aren't saying.
They seem to have a very large task at hand and with a relative small team I cannot see them implementing all the missing Python functionality in a 1-2 year timeframe. Not only language features like classes, but also the standard library is a huge task.
And this is next to the superset features they want to implement which currently seem to take all the manpower.
100mn is a lot of money, but a problem is that developers that can contribute in this space are rare and expensive. Not something any developer can do.
But hopefully I’m wrong and it is more than yet another “colony on Mars” story to attract interest and invested tots.
Still not open-source it looks like [2]. I'm not willing to create an account right now. Can someone who has an account post what the pricing looks like if any? I'd also be curious what other agreements you have to make other than the terms of service[1] you agree to when making an account.
I really do wonder who they're targeting as a paying customer. What dev/team is all of these things
1. Getting paid to work on ML to such an extent that perf is important (enough)
2. Comfortable leaving the warm confines of python and a huge ecosystem
3. Willing to learn a brand new, closed source, beta maturity language
4. Does inference on CPU
5. Willing to run their inference pipeline behind some FaaS layer because that's how I'm assuming modular plans to make money? The alternative is an honest to goodness licensed compiler and that seems even more farfetched (though I guess not beyond the realm of possibility).
What I wouldn't give to be in the room when they're pitching VCs because they've managed to raise a lot of money for what looks like a TAM of like 5 people.
Yeah, and I assume in the future Python will get its own JIT or AOT compiler, if people really demand it. Most Python for scientific programming is just a higher level glue code for the C++ underneath.
I'm not willing to make an account either, I'm too scared what Modular will do with my data for privacy reasons, especially seeing that giant Google sign in button.
Hopefully, someone will and sign up so that we know Modular intends to do with our data once they collect it.
With all due respect - scared of what? I'm genuinely curious what you're worried about. Can you give me some real world examples of a possible negative repercussion from signing up? I haven't signed up. I don't have an account, just been a curious lurker for the Mojo thing over the past couple of months.
0:16 from https://www.youtube.com/watch?v=mQh9es5gfpo, says "we'll be open sourcing documentation"... by the end of the year. Documentation? It will have taken a full year to open source documentation. Congrats.
I bit the bullet. After singing in via google, its just a page with instructions on installing the Mojo SDK. Nothing about pricing but on their FAQ section they do talk about the telemetry data they collect and how to disable it
A rant. I apologize. I try to avoid on HN and in general.
Faster, yes, but at what cost?
I'm so impressed by the Python community, but I'll never quite understand why they gravitated to... Python itself. It's unbelievable to me that in Mojo's case some of the brightest, most famous engineers have gathered to do incredible computer science work to improve the compute performance of a language that is fundamentally flawed in its performance characteristics for those very applications. It just seems like such a waste.
How on earth did we arrive at this moment?
Chris Lattner is right in his Lex interview: he had to accept that the community was already committed to Python and given that reality, that in turn pre-filtered his available paths. But my god, what if the community had gravitated to a better language [for these purposes] in the first place? How much further along would we be in our tooling and capabilities to deliver value?
Chris, who I admire, loves to talk about language design decisions; loves to talk about how thoughtful they were in the decision-making around Swift; and then in the next breath says, hey whitespace-based scoping doesn't matter, don't worry about these things. Chris all you do is worry about these things, and worry about them for Mojo. He clearly has opinions that he masks about design choices Python has made; otherwise, after all, why the need to make Mojo?
It just seems like at the end of the day, Mojo may be the most technologically advanced lipstick ever to be placed on a pig.
(Edit for grammar, but clearly not for brevity or conciseness. XD)
Hey, thanks for your interest. I think it's interesting that you think I don't care about things like whitespace vs braces? In the Lex interview I was kidding around, but I assure you, I do care.
Braces are strictly worse than whitespace indentation for several reasons. Brace-based languages:
1) Generally have the "dangling else" set of ambiguities.
2) Some (e.g. C) allow but do not require braces which leads to style debates. The ones that require braces are more verbose.
3) Require more punctuation clutter, and consume more vertical whitespace in practice.
4) ... use braces that are completely redundant with indentation in practice!
It's super funny to see people defend curly based languages. Using curlies but not indenting properly is almost always a sign of a bug (e.g. clang has warnings for this sort of thing due to the "goto fail" and other debacles.
That said, as you also know, Python compat is not optional for us, so Mojo doesn't actually a choice at all here. I find it amusing though that your post acknowledges thoughtfulness in language design and thinks this is an example of a lapse of judgement. :P
> It's super funny to see people defend curly based languages.
Well, that's because they're not really "strictly worse" in every way. I find curly braces helpful for readability and cursor navigation. The latter is only possible with Python by completely parsing the code. Also I don't like reading vertically dense code, so having (almost) empty lines inbetween is fine. All subjective of course, but that's the case for every aspect of language syntax.
> Using curlies but not indenting properly is almost always a sign of a bug
I don't think anyone criticising Python's syntax cares about the freedom to have inconsistent indentation, that's not the point.
I know you care about language design. As I said more or less, that's self-evident, and I'm sorry for taking your whitespace comments too literally. You're the source, after all, not me, so accept my apologies there. It's misinterpretation, but not meant to be a misrepresentation. :-)
My comment wasn't meant to be critical of you. Honestly, as a pretty famous engineer, it never even crossed my mind you might read my message. As I said, I know you have to deal with reality to accomplish your goal, and that reality existed before you showed up to take on the challenge.
Thank you for all your contributions and good luck on Mojo.
Curly braces are very helpful during development, because you can scope code without having to reindent it. It's quite similar to being able to comment out a block of code, which Python happens to also make somewhat frustrating.
> But my god, what if the community had gravitated to a better language [for these purposes] in the first place? How much further along would we be in our tooling and capabilities to deliver value?
Better in what regard? Performance? Maybe there are more important things than performance, like ease of use and barriers to entry.
People in this space already tackle essentially complex problems, don't throw more accidental complexity in the form of "better" or more performant languages/APIs.
if the better languages were actually good, they wouldn't have allowed python to whip their asses. Python won because it was nice and easy. meet your users where they are, not where you want them to be.
That would be simplifying too much. There are a lot of external factors for something being popular, like timing, luck, support from big enterprises and leading colleges, inertia and sunk costs. You could argue that does make python better regardless of the language itself but that poster was talking about a hypothetical scenario in which those factors were won by a language better designed for those tasks. Would you use python if most libraries, docs and support were elsewhere just for the language design as is today?
Richard Feldman states in a video aiming to explain the popularity of OOP that Python initially had a small community for decades, and that Python's increase in popularity followed a slow and steady increase, which is not true of many other languages like Ruby. That's corroborated by the graph in this article. [0]
Based on Python's slow and steady incresae, timing and luck don't seem like good factors for explaining its popularity. The others are debatable though.
I fail to see how timing and luck isn't a factor. It's more than how popular it was when it launched, many of those languages that are allegedly better had a strong timing disadvantage by either not existing or not being mature once the data science boom occurred (including equivalents to libraries like numpy, scipy, matplotlib and theano), allowing python to be the right option then. Any language that missed the timing must now play catch up with a fraction of the resources and completely unproven in the market.
Luck is harder to quantify, but at the very least competitors like common lisp didn't have much of it.
Also, Python is where the "Rust Evangelism Strike Force" type stuff really started being a massive phenomenon.
Language wars have been forever, of course. But for a few years around 2010-ish, practically every single thread would have someone bringing up Python. If the post was about a tool, how the thing should have really been written in Python. If it was a how-to tutorial about a feature in another language, there would be a subthread about how Python undeniably does it better. Not occasionally, in a thread here and there - it was to the extent you couldn't miss it even if you wanted to. That's a kind of marketing that's proven effective in a forum like this, which is why it's being replicated by other languages now.
Python won in the data science/ML/AI crowds, and most of the hard work is being done by C code. In other industries, Python ranges from " successful with multiple contenders" (web) to "niche/unusable" (mobile and gaming).
I should have deleted that whole section. I know, I know. Sure, in some world, a whitespace character should dictate placement and lifetime in memory. That's my not preferred world, but also different spokes for different folks. :-)
Totally agree. It’s not even the stuff that most people complain about (e.g. whitespace) it’s the poor decisions that in hindsight which limit performance or make correct code harder to write… and we’re totally avoidable in hindsight.
> Mojo is now available for local download – beginning with Linux systems, and adding Mac and Windows in coming releases.
sure would be nice if this was front and center on the actual website; the download page requires the user create an account in order to even find out that linux is the only supported platform at present.
I wonder whether this will end up being a viable language for people who just want to write fast general purpose code with Python's syntax, and not write any AI/ML-related stuff.
Well there are countless obscure general-purpose languages and language implementations. What I meant by viable is that the user won't feel like a masochist because of weak tooling and library availability.
The goal is to have Mojo be fully compatible with Python, so that you should eventually have access to all of the libraries offered in Python. How many libraries will be written in Mojo remains to be seen, depending on whether it catches on or not.
Who would risk using a closed-source language? I know some academic groups using Matlab, and I know some engineering companies use tools like Simulink, but these are very established products. I don't think I could even get sign-off for using a new closed language for a work project...
It's just a liability and risk. Imagine you have some mission-critical system written in such language, the vendor goes bankrupt or creates absolutely unacceptable terms. Then you have a problem.
Sure if something similar happened to an open-source project, you would still have to either hire engineers to work on the compiler/tooling/language or to rewrite it in a more supported language, but I would consider it a little less riskier as you aren't dependent on one vendor
> I don't think I could even get sign-off for using a new closed language for a work project...
Not with that kind of honesty, but call it a product/framework/partner for automatically optimizing in-house python code or something like that, and it sails right through.
Yeah, a lot of folks don't seem to be aware of the people behind this, and their history. Swift was originally closed source too. He's explained that this sort of "incubation period" is helpful for working out the kinks with a small core team.
Okay I looked up the team and agree they are brilliant, but I still don't know if I trust them to make this open in the longterm. Why can't they open it on Github but just not accept PRs?
Probably, but again K is a language from 1993. I think closed-source languages are relics from a time it was more normal and some are so established they're still accepted, but new closed-source languages feel out of touch. Can you think of any new ones that caught on? I really can't to be honest!
Yeah I agree, I wouldn't launch a new closed source proprietary language these days. The few that found their niche 20-25 years ago seem to do a decent job of sticking around though.
Really excited about Mojo, but not very excited about being fully closed source. I understand not going OSS right now if there's still a lot of churn expected, but I think that can be worked around:
1. Just because something is OSS doesn't mean the public is entitled to defining the roadmap or design decisions. If you set working norms up front and make it clear who has decision-making power and why, people will decide for themselves if they want to engage or not. A lot of frustration in OSS comes from lack of clear boundaries around how and why something evolves the way it does.
2. You can meet in the middle and be source-open. Don't use an OSI license, don't guarantee that you'll look at a community contribution, and don't guarantee that you'll engage on a particular issue. People can still benefit from seeing the source and deciding on if it's the right tool for them.
I know a lot of folks rag on "corporate controlled OSS", but there's a lot of examples of that motion working really well for products. I hope Mojo does this eventually.
which is why we created Hidet, open-source deep learning compiler, written in Python and which can be easily extended to create all kinds of ML projects (wink, wink) with support for Nvidia GPUs. I am still looking for information on Mojo support of Nvidia GPUs, de-facto compute standard for modern AI/ML.
Pretty neat! Tried profiling it since it aims for high performance use cases. Love how far we can get with standards in software engineering that we can just take this new language/runtime and just profile it!
i find myself thinking that numerous times a day (not on HN only), and it occurs to me that this acronym might itself not be known, since you'd have to RTFM to figure it itself out.
Is what they have achieved really that ... magical, that it needs to be a closed source project? I don't know much about python, but I suspect if someone watches the demo the methodology behind what they're doing is probably clear no? I don't understand the purpose of close sourcing it unless there really is some kind of moat.
You can't have Python run that much faster without loosing lots of features. I guess if they open sourced it, people wouldn't be that impressed with what they implemented. This video [0] from the creator of Flask explains it quite well.
Here [1] is Guido talking about Mojo being in early days and sharing some technical details.
I probably in the minority but for me D language is already the near perfect language to replace Python and becoming very productive and useful for data science and machine learning programming purposes.
For data science and machine learning, they are two type of programmers namely A and B type, for analysis and building respectively [1]. The former are mostly analysts, scientists or mathematicians that are mainly non-programmer and the B are hardcore programmer that build engine, library, systems and sometime for real-time processing for example embedded signal processing.
For the former, their programming bias are closer to pseudo code and naturally they inclined more towards intuitive programming languages for examples Python and Matlab. For the latter, however, they are mainly library and system builders with real-time bias and their favorite tool are C, C++ and perhaps Rust.
Essentially, Type A prefer easy, low barrier and intuitive languages where real-time is not necessary, while on the other hand Type B required real-time functionality and efficiency regardless of language programming complexity.
From the beginning of programming time, none of the programming languages can really satisfy both types, and that's the main reason Fortran, C and C++ based library are still being widely used by Python, Matlab and Julia, case in point namely LAPACK/BLAS, Eigen and FTTW. D, however, is more than capable of matching and replacing these traditional powerhouse libraries since seven years ago with its Mir equivalent and D should easily satisfy the Type B crowd [3]. Heck you can even write bare metal system without OS with it [4]. Meanwhile, writing bare metal in Julia probably not a very good idea [5].
The harder is to satisfy is the type B crowd and unlike Type B they're fast becoming majority users of the programming languages and this is manifest by the increasing popularity of Python language. For further reading, I'd highly recommend this Ask HN threads on Why did Python win [6].
This is where D language come into the picture, and apparently with D you can have your cake and eat it too [7]. D creators have cleverly make the language has default GC despite extreme disagreement from Type A crowd and they will let you know every time D is mentioned anywhere in the public forum. However, they're kind of missing the big picture since they are fast becoming the vocal minority and most if not all of their requirements can be met with D as proven by Mir [3]. Not only this, D creators also banned macro from the language so D does not have the same fate as Ruby where some Rubyists considered RoR as a ghetto although it's extremely popular and probably the main reason why people is using Ruby in the first place [8].
D seems to hits the sweet spot in becoming the Goldilocks of programming language and it's already an open and mature language that's included in GCC eco-system. Ultimately D need to appeal to the Type A data scientists and this where D creators has gone out of their way to make D as intuitive and Pythonic as possible. In their paper on "Seven Deadly Sins of Introductory Programming Language Design", where these Monash university professors analyzed these popular programming languages back in the day (1996) for their suitability in introductory programming language design namely ABC, Ada, C, C++, Eiffel, Haskell, LISP, Modula 3, Pascal, Prolog, Scheme and Turing [9]. It's a shame that Python is not included because back in 1996 when the paper was written it's still in infancy and not popular as today. Personally, I'd add that not adding a GC as the 8th major or deadly sins of the introductory programming language but it's probably just me. I'm pretty sure that D language authors and designers did not read this seminal paper when they're designing D (I know I asked), but it seems to follow this natural and universal guiding principles that I hope Mojo authors and designers, and other programming languages, will heed as well.
[1] There are two types of data scientists - and two types of problems to solve:
I’m really excited about Mojo, but can’t help but feel like Modular’s insistence to register for the download is a red flag for how they will handle Mojo development. It leaves a bit of a bad impression.
Yeah, I highly dislike working with python, everything is special syntax or different for no reason. In addition to what you mentioned:
* try catch is different keywords from virtually all other languages.
* walrus tusks, the general order in list comprehensions generally where bindings come after expression
* typing is awful, unsound in a lot of cases, there’s a ton of special non straightforward plugins in mypy. This is partially better in pyright but not considerably.
* package management is silly. Poetry is like a poor imitation of npm. Venvs are a pain in the butt.
> try catch is different keywords from virtually all other languages
Python : try/except/finally/else
C# : try/catch/finally (no equivalent of “else”)
VB.net : try/catch/finally (no equivalent of “else”)
JavaScript : try/catch/finally (no equivalent of “else”)
Java : try/catch/finally (no equivalent of “else”)
Ruby: begin/rescue/ensure (no equivalent of “else”)
C++: try/catch (no equivalent of “finally” or “else”)
Python’s try/except/finally/else seem to use nearly the same keywords as many other popular languages (Ruby is an oddball here, using similar semantics with different keywords), except that it uses “except” in place of “catch”, and “else” is a unique feature, and C++ lacks “finally”.
EDIT: The above has been edited throughout to correct an initial thinko that had Python using the common “catch” instead of “except”, which I really can’t explain because I've been wading throw Python exception handling code a lot recently.
Ruby does have a good reason to be oddball IMO. begin isn't always required. When inside a method, module, class, or do...end block definition (read: most of the time), you're able to use the rescue keyword solo. Anything raising an exception in the method above the rescue keyword will be caught.
It can also be used postfixed to a statement that might raise an exception.
Ruby is oddball here because it's subtly different.
def a_method
@value = dangerous_method_call rescue "default value in case of exception"
do_something_else @value
rescue
puts "an error, oh no"
end
2. Are there any tolerable solutions you've found?
3. Are there any non-Python languages you'd recommend?
The root of Python's typing issues seems to be ad-hoc syntax recycling as a stand-in for a thoroughly planned type system. Understandably, Guido and others advise using Protocol types to make up for earlier design decisions. It sort of works, but:
1. It's effectively an unspoken deprecation for parts of the standard library
2. Current design choices create new problems
3. It still doesn't reliably prevent runtime errors
Things break down further as you move beyond the built-ins:
1. Pydantic and other tools come with their own problems
2. Ugly things happen at boundary lines in APIs (ctypes vs OOP)
3. All of these get even worse as Sphinx gets involved
The last two items came up in a recent PR discussion. The other commenter's point seemed correct: simple, specific, and rigid types prevent problems. But then why should we have Generic and Union at all?
I'm still going to use Python when necessary, but it makes the grass look very green near languages like OCaml and Elm. If Rider can make .NET's packaging tolerable, maybe F# would be good too. Are there any others you'd suggest?
I concede about multi line lambdas but far too many languages take a “syntax is bikeshedding and unimportant” approach to language design. New languages are still using “&&” and “||” as if it’s 1975 and syntax highlighting doesn’t exist. Looking at C++, Rust and even Zig code is unnecessarily complicated for someone who isn’t intimately familiar with the syntax meanwhile for the most part anyone can understand Python syntax (well, at least Python syntax that doesn’t abuse decorators and obscure dunder overloads)
I personally find && and || easier to read than "and" and "or" because instead of using words to separate words, it's symbols separating words. Sure syntax highlighting helps, but I don't think there's an objective choice here
> New languages are still using “&&” and “||” as if it’s 1975
Because it's consistent and people don't want to relearn minor details each time they switch. And Python has a lot of those little differences. Though the "and" and "or" keywords are among the few things I actually like.
> meanwhile for the most part anyone can understand Python syntax
What matters more to me is how the syntax works in the long term. I have no trouble reading and writing a lot of Rust code, but even after years with Python I still can't remember the difference between "[-1:]", "[1:]", "[:1]" etc for slicing lists/strings. Recursive list comprehensions with their lack of parentheses are unreadable to me to this day (e.g.: `[item for sublist in list_of_lists for item in sublist]`).
Python is very easy and quick to pick up, really productive for prototyping, but I don't consider its syntax to be its big advantage.
> Recursive list comprehensions with their lack of parentheses are unreadable to me to this day (e.g.: `[item for sublist in list_of_lists for item in sublist]`)
1. there's no recursion here
2. it's literally just a double nested loop flattened (i.e. exactly matching the semantics) to be on the same line instead of indented and on two lines:
[item for sublist in list_of_lists for item in sublist]
is the same as
for sublist in list_of_lists:
for item in sublist:
item
like why would you need parens when you know the for starts the next nested loop.
> why would you need parens when you know the for starts the next nested loop
Well that's the thing, I don't know the "for" starts the next nested loop because there's no indicator for that, and aside from that it's harder to see it at a glance. Nested loops have a colon, line break and deeper indentation inbetween, here you get nothing.
To me it feels like it breaks Python's own rules: the language omits curly braces for scopes but ensures readability with colon & indentation. But here the chained list comprehension nests two loops without any visible scope boundaries.
Perhaps it's just me and others can read it just fine, but that's my two cents on it.
> Well that's the thing, I don't know the "for" starts the next nested loop because there's no indicator for that
`for` is a keyword in the language - you know that the `for` starts the next loop by the same reason you know `for` starts any loop.
The remainder of your complaint makes zero sense. You expect us to sympathize with an archetype (you) that is familiar enough with the language to know what a `for` loop is (basically week 1) but not familiar enough to spot the keyword. This is an archetype with zero instantiations (ie I'm calling bs on even you personally experiencing this problem).
> I don't know the "for" starts the next nested loop because there's no indicator for that
my point: there is no other role that the sequence of characters `for` can play in python (because it's a keyword) so you have all indication that you need.
- I get that people miss them, but you can define nested functions if you want. Nameless functions are nifty, but I’ve never lost sleep over putting `def foo` in front of what would’ve been a lambda in other languages.
- I kinda like the Python ternaries.
Preferences are A-OK, and I’m not saying you’re wrong. Just chiming in that the things you mention aren’t universally disliked.
I'd like to add that forced whitespace is infuriating. It's annoying to navigate (in vim I can't easily go to the beginning/end of a code block like I can in languages where scopes are defined by braces), and it's annoying to read because it's not always intuitive how deep I am within nested scopes
> ... it's not intuitive how deep I am within nested scopes
The ONLY piece of information that is available to you regardless of how deep you are into a function is INDENTATION. Your curly braces won't help you.
Besides that, you should seriously reconsider your coding style if this is an actual problem for you.
>The ONLY piece of information that is available to you regardless of how deep you are into a function is INDENTATION.
...No? It sounds like you write very long, messy code blocks. Consider the following example, I will write a nested loop in 2 languages:
In Python:
for _ in range(10):
for _ in range(10):
print("Inner")
print("Outer")
Here's something similar in JS:
for (const _ of foo) {
for (const _ of foo) {
console.log("Inner");
}
console.log("Outer");
}
In isolation, while I'm writing this comment, I would say these code blocks are equally easy to parse. In the context of frantically debugging, scurrying around a file, I may (and have!) missed the indentation difference in the Python example.
Curly braces allow me to have 3 visual indicators that a block is finished: a visual text object (the brace itself), an extra line separator (the closing brace lives on its own line), and indentation. In Python, I only have one of those things (just indentation). I can have 2 (indentation + line sparation) if I always insert a newline before `print("Outer")`, but empty lines can get deleted and I may forget to include them as I write code. You'd need to configure a linter to guarantee the line separation indicator in a language that delimits scopes by whitespace.
> witter pulled the same trick earlier this year where they made For You the only option, then they would show For You each time you open the app, then they finally gave the Following feed back.
Obviously. You're using 2 spaces indentation for Python and 4 for JS. Don't be surprised that it is harder to see the indentation.
I think I might have indentation related bug early on, when I was new to Python, but I don't remember any recently. It could be that Python 2 allowed to mix tabs and spaces for indentation, while this is no longer allowed in 3.
Also this is how I would format the code:
for _ in range(10):
for _ in range(10):
print("Inner")
print("Outer")
Yeah it was pretty good in the Python 2 era but definitely not something to copy now.
Another big issue is that it's not expression based. For example you can't do `foo = (yield a).b` you have to do `x = yield a; foo = x.b`.
Having a special syntax for the expression version of if else is another example as you said.
I was disappointed to discover Dart made the same mistake there. There's a totally different syntax for match statements and match expressions. Why?? Ok maybe backwards compatibility.. but still. They fixed nullability properly and it wasn't too bad.
Ah I misremembered. I was actually trying to do this
x = [yield a for a in b]
Which yields (heh) an `Invalid Syntax` error. Thanks for the link to that PEP though - turns out the answer is that you almost always have to parenthesise it.
The fact python is statement-heavy to me shows that it was originally conceived in another age. It is really annoying after you use expression oriented languages
I agree (and would add explicit self argument, the fact that all your imports are exported and more) I think the point here is to reuse the Python ecosystem especially in ML.
Most AI/ML work is done in Python. It’s very compute intensive and there’s value in making it faster. There’s also a lot money sloshing around for doing AI stuff. Therefore there might be money for Modular in making a Python-compatible thing to make AI stuff faster.
In other words, I don’t think this is about the syntax at all
I need a programming language that is integrated with
blockchains and crypto coins, with quantum computing
integrated as well as it being for AI and it has to
be for writing running on the Edge serverless and databaseless
with frameworks to fully support a decentralized solutions
with and built in features switches to show which codeblocks
are open source and which ones are proprietary.
It must be strictly functional, not use too many (())
with dynamic stating typing and it must support
google scale from the start and make it impossible to
create anything that doesn't require K8,
and most of all it must be even more AI
