4 ms·

It's supposed to be (currently) a fully native, Python-like language, but for GPUs primarily. Though I am seeing it as having a future as a fully native Python

It's supposed to be (currently) a fully native, Python-like language, but for GPUs primarily. Though I am seeing it as having a future as a fully native Python alternative that might get interesting. I hope with 1.0 (havent fully read the article yet) they stop breaking language features / syntax because they did quite a few different changes over time, their overall goal is to be a fully native superset of Python. I do see this one overtaking Nim over time, which kind of saddens me, because I like Nim for what it is, but Mojo trying to be a superset of Python is a no-brainer for most Python developers. Reminds me of how a lot of Go devs were former Python devs not C++.

pansa2 2mo ago
> 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.
- saghm 2mo ago
  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.
  - pjmlp 2mo ago
    Example, Swift for Tensorflow did not end up great.
- FrustratedMonky 2mo ago
  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.
SJMG 2mo ago
Language-feature-wise it seems like Nim will be competitive. Ecosystem-wise… yeah it's kind of a nonstarter over in Nim land. There are not many go-to libraries and its culture is not very collaborative. People seem more enamored at what they can hack together than what they can contribute to.
- winding 2mo ago
  Part of that is because there isn’t yet a package format and a central repository. I have a few libraries I would like to contribute or merge with similar projects.
  - SJMG 2mo ago
    For sure, those things would go a distance towards making it a more competitive language. Why haven't they happened yet though...? Nim is not a young language. Leadership [Andreas] doesn't think they are more important than spending time adding another memory management option.
    - cb321 2mo ago
      I don't know what @winding means, exactly, but at best this seems highly misleading. Nim had babel packages by around 2010 (when it was called Nimrod and there was a Tower of Babel name scheme) and then nimble packages since 2014 or so. Also, literally 30 seconds on https://nim-lang.org https://nim-lang.org (click on Documentation) and you get to https://nimble.directory/ https://nimble.directory/ , search for index and get to adix which has all sorts of efficient Table variants. There has never been much prog.lang. benefit from being "in the stdlib/core" in Nim (unlike Python or Go, say). The benefit is more "software distribution" for the dependency allergic, but the Nim culture is much less micro-deps than seems in vogue lately. All that said, I think having a more batteries core distribution is valuable - just less than you might guess - and practically that needs delegation.
      - SJMG 2mo ago
        > Literally 30 seconds And knowing the magic keyword search `adix` to arrive at a prerelease library that you yourself wrote. That not's exactly an endorsement for discoverability. Unless I'm missing something, Nimble is essentially stateless. You have no sense of how many times or how recently a library has been downloaded. These are important proxies. > There has never been much prog.lang. benefit from being "in the stdlib/core" in Nim (unlike Python or Go, say) … more batteries core distribution is valuable - just less than you might guess You've been around the community a lot longer than I have. Don't you find this strange? What top 10 language has as weak of a std lib as Nim? [Status all but says](https://status-im.github.io/nim-style-guide/libraries.std.html https://status-im.github.io/nim-style-guide/libraries.std.ht...) don't use it. > practically that needs delegation. Yeah, I don't think this is the community's strong suit. It strikes me that Araq is tired of explaining himself (but doesn't care to consolidate discussion into ADRs), so when a well-meaning, would be contributor like the parent-poster comes along they get shot down and we lose them.

pansa2 2mo ago

> 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.

saghm 2mo ago
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.
- pjmlp 2mo ago
  Example, Swift for Tensorflow did not end up great.
FrustratedMonky 2mo ago
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.

SJMG 2mo ago

Language-feature-wise it seems like Nim will be competitive. Ecosystem-wise… yeah it's kind of a nonstarter over in Nim land. There are not many go-to libraries and its culture is not very collaborative. People seem more enamored at what they can hack together than what they can contribute to.

winding 2mo ago
Part of that is because there isn’t yet a package format and a central repository. I have a few libraries I would like to contribute or merge with similar projects.
- SJMG 2mo ago
  For sure, those things would go a distance towards making it a more competitive language. Why haven't they happened yet though...? Nim is not a young language. Leadership [Andreas] doesn't think they are more important than spending time adding another memory management option.
  - cb321 2mo ago
    I don't know what @winding means, exactly, but at best this seems highly misleading. Nim had babel packages by around 2010 (when it was called Nimrod and there was a Tower of Babel name scheme) and then nimble packages since 2014 or so. Also, literally 30 seconds on https://nim-lang.org https://nim-lang.org (click on Documentation) and you get to https://nimble.directory/ https://nimble.directory/ , search for index and get to adix which has all sorts of efficient Table variants. There has never been much prog.lang. benefit from being "in the stdlib/core" in Nim (unlike Python or Go, say). The benefit is more "software distribution" for the dependency allergic, but the Nim culture is much less micro-deps than seems in vogue lately. All that said, I think having a more batteries core distribution is valuable - just less than you might guess - and practically that needs delegation.
    - SJMG 2mo ago
      > Literally 30 seconds And knowing the magic keyword search `adix` to arrive at a prerelease library that you yourself wrote. That not's exactly an endorsement for discoverability. Unless I'm missing something, Nimble is essentially stateless. You have no sense of how many times or how recently a library has been downloaded. These are important proxies. > There has never been much prog.lang. benefit from being "in the stdlib/core" in Nim (unlike Python or Go, say) … more batteries core distribution is valuable - just less than you might guess You've been around the community a lot longer than I have. Don't you find this strange? What top 10 language has as weak of a std lib as Nim? [Status all but says](https://status-im.github.io/nim-style-guide/libraries.std.html https://status-im.github.io/nim-style-guide/libraries.std.ht...) don't use it. > practically that needs delegation. Yeah, I don't think this is the community's strong suit. It strikes me that Araq is tired of explaining himself (but doesn't care to consolidate discussion into ADRs), so when a well-meaning, would be contributor like the parent-poster comes along they get shot down and we lose them.