5 ms·
Mojo: The usability of Python with the performance of C
- Incipient 3y ago"We believe a tight-knit group of engineers with a common vision can move faster than a community effort. " But can't they just open source it and not accept PRs?
- crakenzak 3y agoVery excited to see how this comes along! Hopefully we have a JS->TS style jump here! Some of the performance gains look absolutely ludicrous.
- andrewstuart 3y agoI watched a video talking about multi thousand times speedup in some cases. I think this relates to GPI programming however where of course the speedup for highly parallel operations will be prefers of magnitude. But that’s not about the language per se.
- transitivebs 3y agoThis looks absolutely amazing. The team building this is A+++ as well
- deleted 3y ago[deleted]
- ShadowBanThis01 3y agoNow that's a decent title for a post.
- heyitsguay 3y agoYou mention coming into this from the ML world, but any mention of timelines to leveraging Python's ML ecosystem seem absent. Any idea what's in the works in that regard?
- dqft 3y agoMaybe after the next round
- TheCowboy 3y agoRepost from 2 days ago: https://news.ycombinator.com/item?id=35790367 https://news.ycombinator.com/item?id=35790367
- bakugo 3y ago> The Mojo standard library, compiler, and runtime are not available for local development yet, so we created a hosted development environment where you can try it out. We call it the Mojo Playground! To provide the best experience possible, the Mojo Playground currently supports a limited number of people. > Sign up for access to the Mojo Playground. When you receive access, log in to the Mojo Playground using the email address you provided in the above form. A programming language as a service. Exactly what we all needed.
- OnlyMortal 3y agoManager: “Why are you all sat around drinking coffee?” Devs: “The server is down…”
- pjmlp 3y agoWelcome back to the days of timesharing development servers with thin clients. Nowadays easily replicatable with cloud development, Web IDEs and shells.
- FrankyZunim 3y agoThe fire emoji as file extension is odd, complicated, and unprofessional. That's my main take away. (I know .mojo is also supported but it seems you're pushing .[fire emoji] as default.) An FAQ entry on how it's faster than C would be appreciated.
- HexDecOctBin 3y agoWhat does the word "Mojo" has to do with fire to begin with? Is this some new output of meme culture? Do kids today consider the ability to create mojo using stones as the first step towards human civilisation?
- prepend 3y agoMojo is a word for magic. Meme magic is a thing. Fire emoji is a meme. That’s my attempt at making the connection. It also just seems like a fun thing kids do. I don’t even know how to enter an emoji as a file extension so it could be a way to filter out oldsters who don’t know the new ways.
- traverseda 3y agoI think the fire emoji is part of the name... Like it's meant to be represented as mojo[fire emoji]...
- latexr 3y agoIt might have accessibility implications too. An extension which is visually busy, hard to type, and confuses people on screen readers seems like the worst of all worlds.
- BiteCode_dev 3y agoLove the idea, but it seems right now very much tied to their platform. If I can't install it and run it on my machine, including in prod, it's a hard sell. But given the tone of their articles, they seem passionate about it, and genuine, so I want to believe Mojo will be released as a FOSS project in the future and they will make money with the service itself.
- frodowtf 3y agoClosed source. Not interested.
- yutijke 3y agoHow are they supposed to fund the development then? Open source would have been ideal, but when people ask for open source it's mostly them asking for free. We know that most developers don't truly care about open source beyond the surface level given how popular VSCode is. If you want to make money and pay rent, Open Source has shown to be disastrous for almost all business models.
- prepend 3y agoI suppose the same way other open source languages fund themselves. For a language, I think opennness and standards are so important because the usage is broad. The licensing aspects are also important, but I’m even hesitant to use open source languages that are largely run by a single org (eg, Go).
- Patrickmi 3y agoI don’t know if this is a naive statement or you’re saying it with action because basically every open source project with huge adoption have a single org
- deleted 3y ago[deleted]
- anaganisk 3y agoI generally have the same sentiment, but languages I believe are one place where you can actually make money on consultations and support unlike other types of opensource projects.
- TradingPlaces 3y agoI will predict they OSS this within 18 months. They will make money on the execution engine, which people are ignoring, but was a bigger announcement imo.
- bullen 3y agoPython is hardly usable for big projects. The closest I get to this is hot-deploying a C dynamic lib compiled with debug on a core C++ engine compiled with release. That way I get stacktraces from "the moving code" I can read remotely without losing performance (move the heavy parts into the core engine). The engine needs to be extremely stable for this to work though.
- dbrueck 3y agoI've used Python on many large projects over the past 20 years. IME it's been extremely usable for big projects. Additionally I've consulted on a couple of large Python that were a mess, but on closer inspection, the team was doomed to fail no matter what tool they used, and honestly I think Python just helped them get further than they otherwise would have. :)
- ynik 3y ago"Superset of Python with added features for systems-level code" sounds exactly like Cython. Strange that Cython isn't ever mentioned in any of the comparisons.
- dbrueck 3y agoThere are a few key properties of Python that make it a really great language to develop in, especially at the start of a project: no need to figure out type annotations up front, high signal-to-noise syntax, and Python's absurdly dynamic nature. These all work together to speed development, especially the early stages where you're modelling the program's design. As the program gels, then it becomes a much better time to nail down precise data types and then 99% of Python programs no longer need an extreme level of dynamicity (dynamicness?). So far, Mojo seems to be getting this right: stay out of my way when I'm roughing things in and rapidly iterating, and then if and when it's needed, I'll happily lock in data types in exchange for more speed, AOT compilation, getting onto a GPU or microcontroller, etc.
- flashgordon 3y agoSo I mostly agree. Python makes it great to start with and iterate. Unlike say golang. What I've found is while python gets you started quickly it also lets you "sprawl" on your bad habits. A team that got into python with little experience in good habits ends up writing a lot of python code, fast that is hard to read and maintain and continue improving without fear. Having moved to golang (for services only) the idioms are more in your face. Frustrating at first but once you pay the tax it is smoothish sailing. Now I could be biased given experience in "general" software design.