10 ms·

I feel like this language would really benefit from some sort of 1-pager overview. I just spent a fair bit of time on the official site, and I still don't thin

I feel like this language would really benefit from some sort of 1-pager overview. I just spent a fair bit of time on the official site, and I still don't think I have a very good grasp of what problem this language aims to solve, or why I would select it over other similar languages

giancarlostoro 1mo ago
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 1mo 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 1mo 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 1mo ago
      Example, Swift for Tensorflow did not end up great.
  - FrustratedMonky 1mo 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 1mo 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 1mo 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 1mo 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 1mo 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 1mo 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.
manojlds 1mo ago
Python, but good.
- swiftcoder 1mo ago
  I mean, it feels like "Python, but aiming at a completely different vertical that values native compilation and a borrow checker"? Which is not quite the same thing
- steve1977 1mo ago
  So, without significant indentation?
  - tyre 1mo ago
    Oh nooooo, they fucked it up too. Why would someone make a language that’s whitespace sensitive? It’s confounding.
    - mplewis 1mo ago
      It's really not that bad
    - syrrim 1mo ago
      Why would someone make a language where the programmer and the interpreter have two different ways of figuring out where blocks start and end?
      - ioasuncvinvaer 1mo ago
        at the closing curly?
        syrrim 1mo ago
        Programmers look at the indentation.
        1mo ago
totalperspectiv 1mo ago
Having written a lot of Mojo over the last two year, just for fun, it's a really cool language. Ownership model adjacent to Rust, comptime in the realm of Zig, rich type system, first class SIMD support, etc. Performance wise it's the first language in long time that isn't just an LLVM wrapper. LLVM is still involved, but they are using it differently than say, Rust or Zig. Very excited for Mojo once it's open sourced later this year.
- cpeterso 1mo ago
  > LLVM is still involved, but they are using it differently than say, Rust or Zig. Chris Lattner said in a Developer Voices podcast interview: "Swift in a way was syntactic sugar for LLVM, at the very bottom of the stack it could talk directly to LLVM primitives. Mojo does basically that same trick, but it supercharges it by moving to this MLIR world."
- nu11ptr 1mo ago
  How are compile times compared to Rust? Zig? Go?
  - melodyogonna 1mo ago
    Mojo is much faster than Rust, but slower than Go. I don't have much experience with Zig. Mojo is designed to be very fast to compile, so many decisions were made to keep the core language simple, one example is in `where` clause, the checking there happens entirely in the parser. It can be stupid in situations where other languages are smart, and make you explicitly do checks that could be inferred in other languages. But on the other hand, it can be very fast since it doesn't have to do all the complicated resolving. Another reason is how LLVM is used, Modular found ways to parralize LLVM code generation by introducing novel techniques that'll likely become a lot more popular with other languages.
    - osigurdson 1mo ago
      From experience, Zig compile times are at least as fast as Go for debug builds that don't need to do linking with C libraries, etc. It does have to use LLVM for release builds however which is a lot slower.
embedding-shape 1mo ago
I felt the same way, even after browsing around on the website, and somehow I got to https://mojolang.org/docs/manual/quickstart/ https://mojolang.org/docs/manual/quickstart/, which brings you to mojolang.org instead, which is the real website of the language it seems, instead of "Modular" which I guess is the business. https://mojolang.org https://mojolang.org is a lot better as a introduction to the language for a programmer, at least for me, compared to whatever I could find on the modular.com website.
efficax 1mo ago
i think the main idea is that by using MLIR[1] instead of the usual LLVM path it can target gpus directly 1. https://mlir.llvm.org/ https://mlir.llvm.org/
jibal 1mo ago
Do you mean the Modular site or the Mojo site? https://mojolang.org/ https://mojolang.org/ makes some clear statements.
- swiftcoder 1mo ago
  I was on both. I honestly don't think mojo.lang.org is much clearer - the front page says "GPU kernels + Python + metaprogramming", and the last of those is something Python already has out of the box. The QuickStart doesn't seem to introduce any novel features of the language either.
timmyd 1mo ago
You'd likely enjoy: https://mojolang.org/nightly/docs/vision/ https://mojolang.org/nightly/docs/vision/ for why we created it, and there's https://mojolang.org/nightly/docs/faq/ https://mojolang.org/nightly/docs/faq/ as well :) Feedback welcome as always and thanks for checking it out! Encourage you to watch ModCon next week for some exciting announcements :)
- swiftcoder 1mo ago
  > You'd likely enjoy: https://mojolang.org/nightly/docs/vision/ https://mojolang.org/nightly/docs/vision/ for why we created it, Ok, yes, this is a substantially better entry point to the language than anything I found by clicking around - maybe link it prominently from the main page?
  - timmyd 1mo ago
    Updated -> https://mojolang.org/ https://mojolang.org/. "Why Mojo?" is now smack bang on the homepage!
deleted 1mo ago
[deleted]
sakesun 1mo ago
Whoever behind the company communication have done an incredibly terrible job. They start with an extremely unnecessary polished Steve-Jobs-alike debut video when they have zero stuff to offer, while the founder name is already immensely trustworthy. Then follow with a very ugly AI-image-heavy website and blog posts, only to be reverted back to plain website later. I'd love the language and platform be succesful, nevertheless.
adsharma 1mo ago
https://github.com/py2many/static-python-skill https://github.com/py2many/static-python-skill You can stick to python and generate mojo or rust or lean. There is more than one solution to the two language problem.
jillesvangurp 1mo ago
Their communication definitely needs work. I listened to the interview with Chris on the Lex Friedman podcast a few years ago. Back when the pitch still was "minimal python superset that allows us to make it go voom". It wasn't a bad pitch. But it's gotten a lot murkier since then apparently. And obviously pitching a new language just before world plus dog was about to switch to delegating programming work to AI agents wasn't great timing. > "Qualcomm to Acquire Modular" That's linked from their news section. If I read between the lines here what happened is the VC money ran out and they arranged some kind of acquihire. That obviously raises a lot of questions about what will happen to Mojo and the intentions around it. The merger was completed a few weeks ago so apparently this is a done deal. Them wrapping a ribbon around the 1.0 a few weeks later is a bit suggestive. The modular front page reads like it was trying to pitch the whole thing as a competitor to other inference platforms like open router, replicate, bedrock, etc. I'm sure there's more to it and that the tech was amazing. But the acquisition raises a lot of questions about the future of the whole thing. An OSS move at least would allow people to continue working on Mojo independently from Qualcomm. I assume some people in the team might be moving on post acquisition.
- Certhas 1mo ago
  The Python tie in was always a sales pitch. The technical pitch was "a language built around MLIR taking all the lessons learned by Rust and Swift on board, with an eye towards Python interop". There were MLIR intrinsics and extensive discussions of the ownership model from the start, but never even an attempt to have classes. And the main use of the language (and justification for the VC money) was always the engine built with it, which I have absolutely no opinion on. Honestly, the promise of the language is immense. Ownership semantics that have much better ergonomics and are much more teachable than Rusts, and eventually a relatively smooth teaching path from Python to Mojo would make Mojo a default first modern low level language for many people coming in. Whether this will be relevant in the LLM world we live in now, where you can just take your Python prototype and have it be rewritten in Rust, who knows...
  - pjmlp 1mo ago
    I am already using agentic orchestration tools where the language is irrelevant, e.g. Opal, Workato, Boomi. The evolution of iPaaS low coding tools. Just like you can take some high level code in a dynamic language and expect the JIT compiler to do the best every time, under completly different execution patterns, so will LLM based development eventually become like that. COBOL is already laughing at the efforts to write so much English text to keep AI on track.
erdinc 1mo ago
I think they wrote an internal memo and by mistake they share with the public. I read because one person I know works there, now I don't know what my friend does there either. Sounds like another VC eating company.
blackhaz 1mo ago
This page really helped me to put it into perspective against Python: https://www.modular.com/blog/an-easy-introduction-to-mojo-for-python-programmers https://www.modular.com/blog/an-easy-introduction-to-mojo-fo...
samuell 1mo ago
For me as a follower, my interest is all about a compiled and fast language with little complexity (vs Rust), and a highly readable and fluent syntax (vs Go).
FrustratedMonky 1mo ago
To be fair, a good bit of the apps/programs/projects posted on hacker news could use a good '1-pager overview'. Like has nobody every explained the 'elevator pitch'. A little marketing doesn't mean you are selling out. Obfuscating your product doesn't make you hip.

giancarlostoro 1mo ago

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

manojlds 1mo ago

Python, but good.

swiftcoder 1mo ago
I mean, it feels like "Python, but aiming at a completely different vertical that values native compilation and a borrow checker"? Which is not quite the same thing
steve1977 1mo ago
So, without significant indentation?
- tyre 1mo ago
  Oh nooooo, they fucked it up too. Why would someone make a language that’s whitespace sensitive? It’s confounding.
  - mplewis 1mo ago
    It's really not that bad
  - syrrim 1mo ago
    Why would someone make a language where the programmer and the interpreter have two different ways of figuring out where blocks start and end?
    - ioasuncvinvaer 1mo ago
      at the closing curly?
      - syrrim 1mo ago
        Programmers look at the indentation.
        1mo ago

totalperspectiv 1mo ago

Having written a lot of Mojo over the last two year, just for fun, it's a really cool language. Ownership model adjacent to Rust, comptime in the realm of Zig, rich type system, first class SIMD support, etc. Performance wise it's the first language in long time that isn't just an LLVM wrapper. LLVM is still involved, but they are using it differently than say, Rust or Zig. Very excited for Mojo once it's open sourced later this year.

cpeterso 1mo ago
> LLVM is still involved, but they are using it differently than say, Rust or Zig. Chris Lattner said in a Developer Voices podcast interview: "Swift in a way was syntactic sugar for LLVM, at the very bottom of the stack it could talk directly to LLVM primitives. Mojo does basically that same trick, but it supercharges it by moving to this MLIR world."
nu11ptr 1mo ago
How are compile times compared to Rust? Zig? Go?
- melodyogonna 1mo ago
  Mojo is much faster than Rust, but slower than Go. I don't have much experience with Zig. Mojo is designed to be very fast to compile, so many decisions were made to keep the core language simple, one example is in `where` clause, the checking there happens entirely in the parser. It can be stupid in situations where other languages are smart, and make you explicitly do checks that could be inferred in other languages. But on the other hand, it can be very fast since it doesn't have to do all the complicated resolving. Another reason is how LLVM is used, Modular found ways to parralize LLVM code generation by introducing novel techniques that'll likely become a lot more popular with other languages.
  - osigurdson 1mo ago
    From experience, Zig compile times are at least as fast as Go for debug builds that don't need to do linking with C libraries, etc. It does have to use LLVM for release builds however which is a lot slower.

embedding-shape 1mo ago

I felt the same way, even after browsing around on the website, and somehow I got to https://mojolang.org/docs/manual/quickstart/ https://mojolang.org/docs/manual/quickstart/, which brings you to mojolang.org instead, which is the real website of the language it seems, instead of "Modular" which I guess is the business. https://mojolang.org https://mojolang.org is a lot better as a introduction to the language for a programmer, at least for me, compared to whatever I could find on the modular.com website.

efficax 1mo ago

i think the main idea is that by using MLIR[1] instead of the usual LLVM path it can target gpus directly 1. https://mlir.llvm.org/ https://mlir.llvm.org/

jibal 1mo ago

Do you mean the Modular site or the Mojo site? https://mojolang.org/ https://mojolang.org/ makes some clear statements.

swiftcoder 1mo ago
I was on both. I honestly don't think mojo.lang.org is much clearer - the front page says "GPU kernels + Python + metaprogramming", and the last of those is something Python already has out of the box. The QuickStart doesn't seem to introduce any novel features of the language either.

timmyd 1mo ago

You'd likely enjoy: https://mojolang.org/nightly/docs/vision/ https://mojolang.org/nightly/docs/vision/ for why we created it, and there's https://mojolang.org/nightly/docs/faq/ https://mojolang.org/nightly/docs/faq/ as well :) Feedback welcome as always and thanks for checking it out! Encourage you to watch ModCon next week for some exciting announcements :)

swiftcoder 1mo ago
> You'd likely enjoy: https://mojolang.org/nightly/docs/vision/ https://mojolang.org/nightly/docs/vision/ for why we created it, Ok, yes, this is a substantially better entry point to the language than anything I found by clicking around - maybe link it prominently from the main page?
- timmyd 1mo ago
  Updated -> https://mojolang.org/ https://mojolang.org/. "Why Mojo?" is now smack bang on the homepage!

deleted 1mo ago

[deleted]

sakesun 1mo ago

Whoever behind the company communication have done an incredibly terrible job. They start with an extremely unnecessary polished Steve-Jobs-alike debut video when they have zero stuff to offer, while the founder name is already immensely trustworthy. Then follow with a very ugly AI-image-heavy website and blog posts, only to be reverted back to plain website later. I'd love the language and platform be succesful, nevertheless.

adsharma 1mo ago

https://github.com/py2many/static-python-skill https://github.com/py2many/static-python-skill You can stick to python and generate mojo or rust or lean. There is more than one solution to the two language problem.

jillesvangurp 1mo ago

Their communication definitely needs work. I listened to the interview with Chris on the Lex Friedman podcast a few years ago. Back when the pitch still was "minimal python superset that allows us to make it go voom". It wasn't a bad pitch. But it's gotten a lot murkier since then apparently. And obviously pitching a new language just before world plus dog was about to switch to delegating programming work to AI agents wasn't great timing. > "Qualcomm to Acquire Modular" That's linked from their news section. If I read between the lines here what happened is the VC money ran out and they arranged some kind of acquihire. That obviously raises a lot of questions about what will happen to Mojo and the intentions around it. The merger was completed a few weeks ago so apparently this is a done deal. Them wrapping a ribbon around the 1.0 a few weeks later is a bit suggestive. The modular front page reads like it was trying to pitch the whole thing as a competitor to other inference platforms like open router, replicate, bedrock, etc. I'm sure there's more to it and that the tech was amazing. But the acquisition raises a lot of questions about the future of the whole thing. An OSS move at least would allow people to continue working on Mojo independently from Qualcomm. I assume some people in the team might be moving on post acquisition.

Certhas 1mo ago
The Python tie in was always a sales pitch. The technical pitch was "a language built around MLIR taking all the lessons learned by Rust and Swift on board, with an eye towards Python interop". There were MLIR intrinsics and extensive discussions of the ownership model from the start, but never even an attempt to have classes. And the main use of the language (and justification for the VC money) was always the engine built with it, which I have absolutely no opinion on. Honestly, the promise of the language is immense. Ownership semantics that have much better ergonomics and are much more teachable than Rusts, and eventually a relatively smooth teaching path from Python to Mojo would make Mojo a default first modern low level language for many people coming in. Whether this will be relevant in the LLM world we live in now, where you can just take your Python prototype and have it be rewritten in Rust, who knows...
- pjmlp 1mo ago
  I am already using agentic orchestration tools where the language is irrelevant, e.g. Opal, Workato, Boomi. The evolution of iPaaS low coding tools. Just like you can take some high level code in a dynamic language and expect the JIT compiler to do the best every time, under completly different execution patterns, so will LLM based development eventually become like that. COBOL is already laughing at the efforts to write so much English text to keep AI on track.

erdinc 1mo ago

I think they wrote an internal memo and by mistake they share with the public. I read because one person I know works there, now I don't know what my friend does there either. Sounds like another VC eating company.

blackhaz 1mo ago

This page really helped me to put it into perspective against Python: https://www.modular.com/blog/an-easy-introduction-to-mojo-for-python-programmers https://www.modular.com/blog/an-easy-introduction-to-mojo-fo...

samuell 1mo ago

For me as a follower, my interest is all about a compiled and fast language with little complexity (vs Rust), and a highly readable and fluent syntax (vs Go).

FrustratedMonky 1mo ago

To be fair, a good bit of the apps/programs/projects posted on hacker news could use a good '1-pager overview'. Like has nobody every explained the 'elevator pitch'. A little marketing doesn't mean you are selling out. Obfuscating your product doesn't make you hip.