Live data from Hacker News

Mojo is available for local download

modular.com

91–100 of 193 posts

Re: Mojo is available for local download

#91
post #67
post #63

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 fla…

The curly brace community already has tons of great choices. Let indent people have their mojo.

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

Re: Mojo is available for local download

#92
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!

Wrote a quick blog post on it here: https://www.polarsignals.com/blog/posts/2023/09/07/profiling...

Re: Mojo is available for local download

#93

Earlier quoted context omitted.

Yeah I believe the actual quoted figure was "35,000 times faster than Python". It's a silly metric either way.

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. [1] https://www.modular.com/blog/mojo-a-journey-to-68-000x-speed...

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.

Re: Mojo is available for local download

#94

Earlier quoted context omitted.

Well assuming that a usable thing exists seems to be where you went wrong according to the reports on Twitter and such haha.

RTFM.

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.

Re: Mojo is available for local download

#96
post #63

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 fla…

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

-Chris

Re: Mojo is available for local download

#97

Earlier quoted context omitted.

Yeah I believe the actual quoted figure was "35,000 times faster than Python". It's a silly metric either way.

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. [1] https://www.modular.com/blog/mojo-a-journey-to-68-000x-speed...

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.

Re: Mojo is available for local download

#98

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

Their FAQ says this:

  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"

Which makes this a non-starter for me as well

Re: Mojo is available for local download

#99
post #10

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.

AFAIK, it's a general purpose language. I don't see any reason you wouldn't be able to use it for applications outside of ML.

Re: Mojo is available for local download

#100

Earlier quoted context omitted.

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

> 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”) Py…

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
Post reply on HN