davidatbu

Last I checked , all of pytorch, tensorflow, and Jax sit at a layer of abstraction that is above GPU kernels. They avail GPU kernels (as basically nodes in the computational graph you mention), but they don't let you write GPU kernels.

Triton, CUDA, etc, let one write GPU kernels.

Being a Python superset is literally a goal of Mojo mentioned in the podcast.

Edit: from other posts on this page, I've realized that being a superset of Python is now regarded a nice-to-have by Modular, not a must-have. They realized it's harder than they thought initially, basically.

Fwiw, Chris has detailed in many podcasts that Mojo will definitely be entirely open source in the future, and that the only reason it isn't now is that he learnt from his experience running Swift as an open source project that the open contribution and planning model is a bad fit, and basically counter productive, at this stage of a language's lifetime.

That is why they opted to open source in stages (ie, the stdlib is open source right now, and they expect to open source the compiler soon).

Just to make sure I understand you correctly, you're claiming that the person who started (and lead onto maturity) LLVM, Swift, and MLIR, writing millions of lines of c++ and leading dozens of engineers in the process, is primarily good at self promotion (as opposed to, say, language design, or compilers, or tackling really hard and long term software projects)?

I wouldn't describe Python type checking as a shit-show. pyright is pretty much perfect. One nit against it perhaps is that it doesn't support non-standard typing constructs like mypy does (for Django etc). That's an intentional decision on the maintainer's part. And I'm glad he made that decision because that spurned efforts to make the standard typing constructs more expressive.

I'm also looking forward to the maturity of Rust-based type checkers, but solely because one can almost always benefit from an order of magnitude improvement in speed of type checking, not because Python type-checking is a "shit show".

I do grant you that for outsiders, the fact that the type checker from the Python organization itself is actually a second rate type checker (except for when one uses Django, etc, and then it becomes first-rate) is confusing.

100%. Python typing is nowhere near as powerful as TS, and the example you gave demonstrates that.

I mentioned pyright because (some of) the specific concerns by OP are addressed by it.

You really should check out pyright/pylance/basedpyright. Just an all around better type checker. Even has the "unknown" from typescript (kinda).

The reason I engaged in the thread is I didn't want OP to feel like their posting/their work was unappreciated. Putting myself in their shoes, I especially guessed that the "go to Reddit" comment would have felt dismissive.

I do agree that I (and most HNers) find explanations of inner workings interesting in Show HN (or anything on HN).

Gotcha. It sounds like you and I agree that tech products whose underlying workings might not be elaborated are still ok to be on Show HN!

Sure, HNers are interested in explanations of how things work (I am too!).

But you specifically said that without such an explanation, products should "go to Reddit" (which presumably means, they don't belong on HN). I'll leave whether that's a "dismissal of someone's work" or not up to you, but all I'm saying is: it's evident via voting that many HNers find BlenderGPT, a tech product, interesting, even with the lack of that explanation. And so BlenderGPT does not need to "go to Reddit".

I'm curious: don't you think the aggregate interest of the HN crowd is adequately measured via the voting mechanism? You seem not to find BlenderGPT as presented in its current form uninteresting, but if you accept that (voting up)=interest, many other people did. Why dismiss("go to Reddit" comment) someone else's work, that, evidently, many other HNers find interesting?

It turns out this wasn't my issue (more on this on other threads here), but I genuinely appreciate your time and help.

I so deeply appreciate your time, thank you!

I figured out the issue: I transplanted the bit about setting optimization levels from the blogpost into my setup (which sets opt-level = 3 for all dependencies), and when I removed that, my compile times went down by a factor of 5-10!

Thanks for that very helpful tip! According to the output of that, no unnecessary recompilation is taking place.

I actually figured out the issue! It turns out, I had unquestioningly transplanted the following from the blog post in discussion, and that is the cause of all my issues:

    [profile.dev]
    opt-level = 1

    [profile.dev.package."*"]
    opt-level = 3

Removing that seems to give me an order (or two) of magnitude reduction in compile times.

(Worth noting: it was passing RUSTFLAGS=-Ztime-passes that made me look here because, apparently, `llvm_passes` was taking the majority of the time).

As a leptos user, I just wanted to say that I appreciate everything you have outlined here (and more) that you have done for the Rust/wasm ecosystem (especially since other people here seem to be less appreciative of your contributions because you've raised VC funds, and I feel like as an open source maintainer, you probably hear much more from 'dissatisfied customers' than the satisfied ones).

I'm particularly excited about your research on actually hot-reloading Rust binary code. I hope it leads to reduced incremental compilation times (IIUC).

I've tried following that same guide, and I believe I've tried every thing on that blog post except the mold linker, because I'm on MacOS, and the MacOS version of the mold repo says "use the default linker if you have XCode 15 or higher."

And I do think I have a pretty granular crate system (would be _very_ happy to hear otherwise, because that would mean there's low hanging compile time fruit!): https://github.com/dnaaun/heimisch

My current _incremental_ compilation time swings anywhere between 15 seconds and 3 minutes (no, I'm not kidding). And I work on an M3 max macbook pro.

---

Things that I suspect are making my compile times worse:

  1. The fact that I am doing SSR, which means my frontend code is included in the backend code as well.
  2. I _think_ Rust is unnecessarily recompiling dependencies on incremental builds?  (I don't understand how incremental compilation times can be so bad otherwise). But I'm clueless about how to go about debugging that.

Another shoutout for leptos, which I'm also currently using, and loving (except for compile times (a Rust problem, not a leptos problem), and other smaller annoyances).

A more charitable take is that OP tried to make his blogpost more accessible to newbies at a very small verbosity cost for non-newbies.

Fwiw: i'm totally fine with that.

> This makes me wonder if it has design choices to ...

I personally felt that the relevant design choices were explicitly enumerated, and so one needs not to deduce them from the rest of the text.

I am really happy to see some more exploration in the typesafe-db-access-in-Rust space.

> The existing libraries don't provide the compile time guarantees that I want and are verbose or awkward like SQL.

Worth noting: diesel definitely fulfills the "providing compile time guarantees" criteria.

Here's where I stand on the inevitable ORM-vs-no-ORM debate that's about to erupt: I like typesafe query builders that don't abstract over sql ( I'd put diesel in this category, and i would not put activerecord or djangos orm or sealORM in this category).

It looks like rust-query will lean towards the full-ORM side of that spectrum. Not my cup of tea, but the tea industry can accommodate many flavors :)

In `wrapped_sleep` function body, where does the `sleep()` come from? It's still tokio::time::sleep, right? If so, the start time is recorded before the first `.await`.

Regardless, the program you provided _does_ actually run the futures concurrently, because of the `join_all()`. My point above was that in the original blog post, the appendix has a version without `join_all()`, which has no concurrency.

Someone linked the code in another comment, and the start time is most definitely recorded when the future is created: https://docs.rs/tokio/1.41.1/src/tokio/time/sleep.rs.html#12...

I think the points people made in other replies make sense, but "Tokio::sleep is async" by itself is not enough of an explanation. If it were the case that `Tokio::sleep()` tracked the moment `.await` was called as it's start time, I believe it would indeed take 10x1,000,000 seconds, _even if it's async_.

This makes total sense!

This makes total sense!

I write (async) Rust regularly, and I don't understand how the version in the appendix doesn't take 10x1,000,000 seconds to complete. In other words, I'd have expected no concurrency to take place.

Am I wrong?

UPDATE: From the replies below, it looks like I was right about "no concurrency takes place", but I was wrong about how long it takes, because `tokio::time::sleep()` keeps track of when the future was created, (ie when `sleep()` was called) instead of when the future is first `.await`ed (which was my unsaid assumption).

I read through this, and thought to myself: "wow, what a response that elucidates the PL design tradeoff space while giving real world examples of languages that occupy various points on that space; all as concisely and economically as possible."

And then I read the user name. Of course it's boats!!

Thank you for all your work! I want to say that especially since I've noticed a lot of shallow dismissal of your work recently (shallow because the dismissal often doesn't engage with the tradeoffs of whatever alternative solution it proposes in the context of Rust, among other things), and would like you to know there's a lot of us who are very very grateful for all the productivity and empowerment you've enabled through your contribution to Rust.

Sent an email!

It's motivating to hear others think similarly! Thanks for the encouragement.

An "offline-first" client web app for Github. I don't want to have to wait seconds to load up an issue, and then wait seconds (or keep another tab open) to go back to the list of issues/PRs, ...etc. I want everything to feel instant, with optimistic updates, and a backend sync process that doesn't require me to refresh the page to see new updates.

(Small note: I'm doing it in full-stack Rust, including web frontend, using leptos).

¯\_(ツ)_/¯