Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
davidatbu
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
6 ms
·
31.
▲
by
davidatbu
1y ago
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.
32.
▲
by
davidatbu
1y ago
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
33.
▲
by
davidatbu
1y ago
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 ope
34.
▲
by
davidatbu
1y ago
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 goo
35.
▲
by
davidatbu
1y ago
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 intentio
36.
▲
by
davidatbu
1y ago
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.
37.
▲
by
davidatbu
1y ago
You really should check out pyright/pylance/basedpyright. Just an all around better type checker. Even has the "unknown" from typescript (kinda).
38.
▲
Typesafe Routing in Rust/Leptos
(dnaaun.github.io)
2 points
by
davidatbu
2y ago
|
0 comments
39.
▲
by
davidatbu
2y ago
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 dismissi
40.
▲
by
davidatbu
2y ago
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!
41.
▲
by
davidatbu
2y ago
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'l
42.
▲
by
davidatbu
2y ago
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
43.
▲
by
davidatbu
2y ago
It turns out this wasn't my issue (more on this on other threads here), but I genuinely appreciate your time and help.
44.
▲
by
davidatbu
2y ago
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 comp
45.
▲
by
davidatbu
2y ago
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 discussi
46.
▲
by
davidatbu
2y ago
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
47.
▲
by
davidatbu
2y ago
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 X
48.
▲
by
davidatbu
2y ago
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).
49.
▲
by
davidatbu
2y ago
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 perso
50.
▲
by
davidatbu
2y ago
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 definit
51.
▲
by
davidatbu
2y ago
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 futur
52.
▲
by
davidatbu
2y ago
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...
53.
▲
by
davidatbu
2y ago
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
54.
▲
by
davidatbu
2y ago
This makes total sense!
55.
▲
by
davidatbu
2y ago
This makes total sense!
56.
▲
by
davidatbu
2y ago
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 th
57.
▲
by
davidatbu
2y ago
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 a
58.
▲
by
davidatbu
2y ago
Sent an email!
59.
▲
by
davidatbu
2y ago
It's motivating to hear others think similarly! Thanks for the encouragement.
60.
▲
by
davidatbu
2y ago
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
More ›