[dead]
RustGPT: A pure-Rust transformer LLM built from scratch
61–70 of 186 posts
Re: RustGPT: A pure-Rust transformer LLM built from scratch
#62As someone who has spent days wrestling with Python dependency hell just to get a model running, a simple cargo run feels like a dream. But I'm wondering, what was the most painful part of NOT having a framework? I'm betting my coffee money it was debugging the backpropagation logic.
"a simple cargo run feels like a dream"
A cargo build that warms up your CPU during winter while recompiling the whole internet is better?
Re: RustGPT: A pure-Rust transformer LLM built from scratch
#63Earlier quoted context omitted.
Every tool for the right job. If you are doing tons of scripting (for e.g. tests on platforms different than Rust), Python can be a solid valid alternative. Also, tons of CAE platforms have Python bindings, so you are "forced" to work on Python. Sometimes the solution is not just "abandoning a language". If it fits your purpose, knock yourself out, for others that may be reading: uv is great for Python dependency man…
>Every tool for the right job. If you are doing tons of scripting (for e.g. tests on platforms different than Rust), Python can be a solid valid alternative. I'd say Go is a better alternative if you want to replace python scripting. Less friction and much faster compilation times than Rust.
I am not a huge fan of Go, but if all the world's "serious" Python became Go, the average code quality would skyrocket, so I think I can agree to this proposal.
Re: RustGPT: A pure-Rust transformer LLM built from scratch
#64Earlier quoted context omitted.
lowkey ppl who praise cargo seem to have no idea of the tradeoffs involved in dependency management the difficulty of including a dependency should be proportional to the risk you're taking on, meaning it shouldn't be as difficult as it in, say, C where every other library is continually reinventing the same 5 utilities, but also not as easy as it is with npm or cargo, because you get insane dependency clutter, and a…
> lowkey ppl who praise cargo seem to have no idea Way to go on insulting people on HN. Cargo is literally the reason why people coming to Rust from languages like C++ where the lack of standardized tooling is giant glaring bomb crater that poses burden on people every single time they need to do some basic things (like for example version upgrades). Example: https://github.com/facebook/folly/blob/main/build.sh
i'm saying that ease of dependency inclusion should not be a main criterion for evaluating how good a build system is, not that it isn't the main criterion for many people...
like the entire point of my comment is that people have misguided criteria for evaluating build systems, and your comment seems to just affirm this?
Re: RustGPT: A pure-Rust transformer LLM built from scratch
#65Earlier quoted context omitted.
lowkey ppl who praise cargo seem to have no idea of the tradeoffs involved in dependency management the difficulty of including a dependency should be proportional to the risk you're taking on, meaning it shouldn't be as difficult as it in, say, C where every other library is continually reinventing the same 5 utilities, but also not as easy as it is with npm or cargo, because you get insane dependency clutter, and a…
This is the weirdest excuse for Python's terrible tooling that I've ever heard. "It's deliberately shit so that people won't use it unless they really have to."
i just realised that my comment sounds like it's praising python's package management since it's often so inconvenient to use, i want to mention that that wasn't my intended point, python's package management contains the worst aspects from both words: being centralised AND horrible to use lol
my mistake :)
Re: RustGPT: A pure-Rust transformer LLM built from scratch
#66Earlier quoted context omitted.
lowkey ppl who praise cargo seem to have no idea of the tradeoffs involved in dependency management the difficulty of including a dependency should be proportional to the risk you're taking on, meaning it shouldn't be as difficult as it in, say, C where every other library is continually reinventing the same 5 utilities, but also not as easy as it is with npm or cargo, because you get insane dependency clutter, and a…
What tool or ecosystem does this well, in your opinion?
any language that has a standardised build system (virtually every language nowadays?), but doesn't have a centralised package repository, such that including a dependency is seamless, but takes a bit of time and intent
i like how zig does this, and the creator of odin has a whole talk where he basically uses the same arguments as my original comment to reason why odin doesn't have a package manager
Re: RustGPT: A pure-Rust transformer LLM built from scratch
#67Earlier quoted context omitted.
Every tool for the right job. If you are doing tons of scripting (for e.g. tests on platforms different than Rust), Python can be a solid valid alternative. Also, tons of CAE platforms have Python bindings, so you are "forced" to work on Python. Sometimes the solution is not just "abandoning a language". If it fits your purpose, knock yourself out, for others that may be reading: uv is great for Python dependency man…
>Every tool for the right job. If you are doing tons of scripting (for e.g. tests on platforms different than Rust), Python can be a solid valid alternative. I'd say Go is a better alternative if you want to replace python scripting. Less friction and much faster compilation times than Rust.
Go performance is terrible for numeric stuff though, no SIMD support.
Re: RustGPT: A pure-Rust transformer LLM built from scratch
#68Earlier quoted context omitted.
lowkey ppl who praise cargo seem to have no idea of the tradeoffs involved in dependency management the difficulty of including a dependency should be proportional to the risk you're taking on, meaning it shouldn't be as difficult as it in, say, C where every other library is continually reinventing the same 5 utilities, but also not as easy as it is with npm or cargo, because you get insane dependency clutter, and a…
Is your argument that python's package management & ecosystem is bad by design - to increase security? In my experience it's just bugs and poor decision making on the maintainers (eg. pytorch dropping support for intel mac, leftpad in node) or on the language and package manager developers side (py2->3, commonjs, esm, go not having a package manager, etc). Cargo has less friction than pypi and npm. npm has less frict…
nah python's package management is just straight up terrible by every metric, i just used it as a tangent to talk about how imo ppl incorrectly evaluate build systems
Re: RustGPT: A pure-Rust transformer LLM built from scratch
#69Earlier quoted context omitted.
Have you tried uv [1]? It has removed 90% of the pain of running python projects for me. [1] https://github.com/astral-sh/uv
uv is great, but I think the real fix is just abandoning Python. The culture that language maintains is rather hostile to maintainable development, easier to just switch to Rust and just write better code by default.
I know Python since version 1.6.
It is great for learning on how to program (BASIC replacement), OS scripting tasks as Perl replacement, and embedded scripting in GUI applications.
Additionally understand PYTHONPATH, and don't mess with anything else.
All the other stuff that is supposed to fix Python issues, I never bothered with them.
Thankfully, other languages are starting to also have bindings to the same C and C++ compute libraries.
Re: RustGPT: A pure-Rust transformer LLM built from scratch
#70Earlier quoted context omitted.
> lowkey ppl who praise cargo seem to have no idea Way to go on insulting people on HN. Cargo is literally the reason why people coming to Rust from languages like C++ where the lack of standardized tooling is giant glaring bomb crater that poses burden on people every single time they need to do some basic things (like for example version upgrades). Example: https://github.com/facebook/folly/blob/main/build.sh
i'm saying that ease of dependency inclusion should not be a main criterion for evaluating how good a build system is, not that it isn't the main criterion for many people... like the entire point of my comment is that people have misguided criteria for evaluating build systems, and your comment seems to just affirm this?
> like the entire point of my comment is that people have misguided criteria for evaluating build systems, and your comment seems to just affirm this?
I think dev_l1x_be's comment is meant to imply that your believe about people having misguided criteria [for evaluation build systems] is itself misguided, and that your favored approach [that the difficulty of including a dependency should be proportional to the risk you're taking on] is also misguided.