davidatbu

Thank you weiznich! Tbh, it's really hard to come up with concrete proposals to solve these problems, and I still haven't figured out how much of the "not-super-easy-to-learn" issue with Diesel is inherent complexity that can't be avoided if one wants to have runtime-constructed-and-yet-compile-time-checked db queries in Rust.

I think it will require some thought. I hope that, once I get around to using diesel in a second substantial project (already using it for my first), I will write up my thoughts on how to make DX better for diesel.

Ah, in that case, I'm much less interested :D , because that would mean that you let the untypedness of the DB queries propagate through pretty much the entire codebase.

> And my system is safer in the end because I take that time I would've spent fighting the type system / tooling and instead spend it writing integration tests.

I'm a type-safety kind of guy, but this argument (that time spent "fighting" the type system) is better spent writing tests when it comes to DB queries, has me very very curious. Would love others' opinions/experience on this!

Personally, what I'm looking for from an ORM is composability and type safety. To my knowledge, it's impossible with sqlx, for e.g., to conditionally add a WHERE clause, and have compile time checked queries. With diesel, it is possible.

I 100% agree with your point about Diesel's dev experience leaving a lot to be desired when it comes to docs and ease-of-learning though. But to me, that is a straightforward problem to solve when compared to the fundamental limitation of sqlx that I described above.

But isn't dioxius also using a vDOM like react? I'm curious, what do you think are the advantages of dioxius over sycamore?

I've had to write my own `useCallbackOne()` hook that is guaranteed to not be recomputed if it's dependencies don't change.

    export function useMemoOne<T>(valueProducer: () => T, deps: unknown[]) {
      const [initialValue] = useState(valueProducer);
      const memoizedValue = useRef(initialValue);
      const memoizedDeps = useRef(deps);
      if (
        deps.length != memoizedDeps.current!.length ||
        _.zip(deps, memoizedDeps.current!).some(
          ([dep, memoizedDep]) => dep != memoizedDep
        )
      ) {
        memoizedValue.current = valueProducer();
        memoizedDeps.current = deps;
      }
      return memoizedValue.current;
    }

    // eslint-disable-next-line @typescript-eslint/no-explicit-any
    export function useCallbackOne<T extends (...args: any[]) => unknown>(
      fn: T,
      deps: unknown[]
    ) {
      return useMemoOne(() => fn, deps);
    }

FWIW, for this and other reasons, I've recently been looking into "actually reactive" frameworks (like Solid/Svelte), and I think I vastly prefer their paradigm to react's.

Specifically, I used sycamore-rs to build a Rust/WASM UI, and it's great (once you get the hang of dealing with lifetimes in sycamore).

_This_ is what I want to know.

So I tried converting an ASR model[0] to ONNX about a year or two back. It was really painful. The pain could largely be ascribed to:

(1) code that is very dynamic, making it hard for Pytorch to convert the modules to TorchScript (which it does before converting them to ONNX)

(2) ops that were simply not available in ONNX. Especially, torch.fft, also some others.

[0] https://github.com/burchim/EfficientConformer

"Rust is pretty hard to write" is an opinion.

FWIW, I happen to have the opposite opinion. I find Rust easier to write than, say, Ruby or JS, because it is statically typed, has enums and great pattern matching, and traits are great.

Good to know!

Gotcha. Appreciate the encouragement!

> he who types statically types twice the amount and thus half as fast.

If you mean by this, "static typing is not worth the effort", the zeitgeist is definitely not with you on this one.

> There's honestly no need for static typing in Elixir.

I'd love for that to to be the case! Is the only way for me to find out for me to give it a try, or are there somethings you can say to help me believe?

Can someone _please_ get around to building a framework for Gleam[0] so that I can finally get over my hesitance to dive into a BEAM language over erlang's/elixir's dynamic typing?

[0] https://gleam.run/cheatsheets/gleam-for-rust-users/

Have you heard of the No True Scotsman fallacy?

I'm fairly certain that the model was not at all trained on language data. It's just that the "neural architecture" (specifically, the Transformer architecture) was first discovered in the NLP realm.

If your question is why does an architecture designed for NLP work well for aminoacid sequences, it turns out that the Transformer architecture is surprisingly versatile. It works amazingly well for other sequence-like data (like audio), and even for images (which, to me, is surprising, since images are not a one dimensional sequence like text or audio).

The Transformer architecture (Particularly, the Multihead self-attention[0] mechanism within the Transformer) is, in my estimation, once of the key innovations in deep learning in the past 5 years. It's used in pretty much everything in deep learning (GPT-3, AlphaFold, DALLE-2/Stable Diffusion, OpenAI's Whisper, come to mind).

[0] https://lilianweng.github.io/posts/2018-06-24-attention/#mul...

You're right. I should give it another try.

Thanks. My interest is piqued now for sure.

Thanks for the tip!

I keep reading on HN and elsewhere that Scala's feature-full-ness encourages complex/unmaintainable code, but I gotta check out myself.

I'll bring up the Kotlin LSP[0] every time I see Kotlin on HN because I really hope the LSP takes off (which would make it viable to use Kotlin with a non-IntelliJ editor).

Kotlin as a language looks really cool, but I don't want to give up terminal-based, modal editing (which I'd have to in order to use IntelliJ).

Along those lines, I once tried diving into using Gradle outside IntelliJ, and I couldn't find any good resources to help with that. If folks have hints/links-to-blog-posts with regards to that as well, that'd be great!

[0] https://github.com/fwcd/kotlin-language-server#this-reposito...

I now understand the primary value-prop of this project is the friendlier syntax. Thanks for clearing that up!

Thanks! But you haven't convinced me that this adds any value right now on top of Axum, at all. Perhaps this is sort of an early release, since you mention elsewhere that the plan is to support GraphQL (and that would be the value-add)?

The only way this feels like an improvement over Axum (a library this is built on) is a tiny syntactical change in how one hooks up a route handler function to a route.

Otherwise, it feels like it adds nothing on top of Axum. In fact, I don't see a way to do statically typed query param extraction with this, so I'm not even sure if the tiny syntactical change is worth it.

Am I missing something?

Almost every study of security vulnerabilities concludes that roughly 70% of them are caused by memory unsafety.

I'm sure that nvim-lspconfig doesn't take care of installing binaries for LSP servers like this. You either set the path to the binary in your config, or you are using another neovom plugin to make sure LSP server binaries are installed

Not OP, but I get their frustration. File browsing is not very amenable to keyboard based navigation IMO. I'm currently using fdfind through telescope.nvim as well as another neovim plugin for this, but I can easily see why someone would want to use a terminal based text editor, with a mouse based file navigation tool.

FWIW, the maintainers have been exploring various extensibility solutions. For e.g., I remember seeing a PR to allow a WASM-based plugin system, though I think it was abandoned because of the tradeoffs it posed.

I'm currently looking into using CRDTs for a side project, and would love to pick your brain:

CRDTs don't solve the semantic issue of a conflict, but nothing ever will, because the semantics are defined by business requirements, right?

Isn't the idea behind CRDTs to develop a set of "primitives" upon which one can build conflict free data structures?

And isn't all the hype about CRDTs a result of the fact that providing those primitives in a serverless way (ie, without requiring a central authority) was a hitherto unsolved problem?

I forgot to say thanks regarding this!

> Tensorboard tracks the datasets as hyperparams.

Clever!

> Warehouse side .. Prefect

I'll have to checkout warehouse-side things and Prefect to see what you mean.

Appreciate all the pointers!

Thanks!

Note to self: I really have to get around to reading fundamental papers in the area as opposed to bothering generous HNers :) .

Thanks! I do agree that most tech companies in general could use more straightforward terminology when describing what they do lol.

To make sure I understand, your issue not with their technical assertion that it's possible to do web hosting in a decentralized and trustless way as well as without massive compute overhead, but with their implementation of that claim, right? (because they only signed on one cloud provider to back their thing).