Live data from Hacker News

Mojo: The usability of Python with the performance of C

stackoverflow.blog

51–59 of 59 posts

Re: Mojo: The usability of Python with the performance of C

#51
post #20

Earlier quoted context omitted.

C isn't open source. To make a conforming C compiler, someone has to buy the ISO C standard (208 CHF), which other folks will then spend development resources in creating C compilers that obey said standard. The biggest open source compilers, clang and GCC, only keep being up to date with ISO C, because of the money from IBM, Red-Hat, Apple, ARM, Intel, Green-Hills,... place in assigning company resources to work on…

The C standard really isn't all that relevant in practice though, for instance the Microsoft C compiler had been trailing the standard by about 2 decades until quite recently but this didn't stop people from using it. Also most C code that's written to compile across gcc, clang and msvc most likely doesn't even build with -pedantic on gcc or clang. (eg in practice C is more like a language family, with an attempt to…

It is relevant to anyone writing portable code, or requiring certification.

Re: Mojo: The usability of Python with the performance of C

#52

Python is a lot of things, but "usable" I would list on the bottom of the list. (Somehow packaging Python scripts is a nightmare that gets worse with each passing year.)

This must explain its soaring popularity.

For one, Python's popularity isn't "soaring", it peaked years ago.

For two, Python was originally designed as a teaching language to replace BASIC for entry-level programming courses, so it would be surprising if it wasn't popular.

It has lost track of the original vision in a big way, and I would bet that a decade from now something else will replace it as BASIC 3.0.

t. programming in Python since it was version 1.3.

Re: Mojo: The usability of Python with the performance of C

#53
post #50

Earlier quoted context omitted.

What development resources is green hills contributing to GCC or clang? As far as I know, they don't actively develop either, aside from selling a completely unrelated compiler that used to be called "gcc" long before the Gnu compiler ever used that name. They also haven't meaningfully participated in the mailing lists under their company name. In any case, it's my understanding that the C standards have largely been…

Their new compiler is a clang fork, they contribute at least to LLVM.

Interesting, how did you find that out and which product was it for (if you can say)? They recently (as in this year) assured me that the safety certified compiler was home-grown. I'm inclined to believe them given how broken the parser is and how many features it lacks.

Re: Mojo: The usability of Python with the performance of C

#54
post #12

Earlier quoted context omitted.

> That's probably true in a select case, but this is why you use libraries in Python - to make use of all the hard work that already exists in C/C++ in those libraries, with Python serving as a high level and far easier to write functional wrapper. Yes, but that's also the issue they address. That you cant just write plain Python for something not covered by libraries and have it be fast. You need to then mess with e…

Why is cython (python-like fast language) worse than mojo (python-like fast language)?

There's not a strong reason to use Mojo over cython right now, but if Mojo can deliver on their claims, I think there will be. A borrow checker, better IDE support, function overloading support, and better SIMD support are things that stick out to me in Mojos favor.

Re: Mojo: The usability of Python with the performance of C

#55
I wish this had [podcast] or [audio] tag, since it's not a "blog" like the domain would imply. Clicking on the Transcript link just shows the same blurb as does the blog page, so I guess it's waiting for someone to transcribe it. Anyway, for sure "reading" a podcast is not the same as reading a blog post

Re: Mojo: The usability of Python with the performance of C

#56
post #12

Earlier quoted context omitted.

> That's probably true in a select case, but this is why you use libraries in Python - to make use of all the hard work that already exists in C/C++ in those libraries, with Python serving as a high level and far easier to write functional wrapper. Yes, but that's also the issue they address. That you cant just write plain Python for something not covered by libraries and have it be fast. You need to then mess with e…

Why is cython (python-like fast language) worse than mojo (python-like fast language)?

Aside from the rest of stuff they offer (and higher speed, if they're telling the truth) Mojo is also a standalone language you can use, whereas Cython is meant for dual-mode use alongside Python.

Re: Mojo: The usability of Python with the performance of C

#57
post #50

Earlier quoted context omitted.

Their new compiler is a clang fork, they contribute at least to LLVM.

Interesting, how did you find that out and which product was it for (if you can say)? They recently (as in this year) assured me that the safety certified compiler was home-grown. I'm inclined to believe them given how broken the parser is and how many features it lacks.

Sorry about that, I typed from head without cross-checking.

I thought having read it somewhere on one of those embedded forums like embedded.com.

Upon further investigation they are still using their own stuff.

https://www.ghs.com/products/compiler.html

Re: Mojo: The usability of Python with the performance of C

#59
post #9

Earlier quoted context omitted.

Indeed. It feels like it’s a nice language and, building on LLVM makes it stand on a solid foundation, but, still, it feels like a series of PEPs, some of which I can easily get behind. If they make mojo modules callable from Python code, it all becomes a whole lot more palatable.

Yes. It seems everybody is just creating this tiny small secret sauce and giving it a different name to lure venture capital. I love the LLVM ecosystem, will touch Mojo only when they evolve it and build more bridges with the regular Python ecosystem.

This seems like a huge effort and a pretty well rounded language. Could even succeed Python in some spaces. I like the syntax being unobtrusive as well.

I’d love to see it being used to write modules usable from Python code. This could provide a smooth migration path to apps that benefit less from Python’s dynamic nature and more from C-like speeds.

Post reply on HN