Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rewriting in Rust

blog.jetbrains.com

Post reply on HN
Print view View original

51–60 of 68 posts

Re: Rewriting in Rust

#51

Post by jemmyw »

sashank_1509 wrote: post #21
BluSyn wrote: post #10

Small related anecdote: Was just testing latest gen LLM capabilities, and decided to give it goal of rewriting a small opensource project in Rust. (Should be noted: was not some tiny library, but an actually useful network service). It completed the entire rewrite from typescript to rust in about 2 hours, ~600k tokens used. Worked perfectly on first try with no follow up changes required. Memory and CPU usage now a t…

I’ve seen people do this and I’m always confused, do they believe they will never have to reason about the code ever again. I suppose if it is like the Zig Rewrite where essentially all development is being done by Claude, I can imagine this making sense. But in any other case, you had a codebase that presumably you wrote, you could reason about, you could refactor etc. and then you made it into a completely unintell…

A small typescript util rewritten into rust is going to look so similar that I don't think this will be a problem. As the parent commenter said, maybe not for a larger project. But rust semantics are really close to typescript for the most part, at least the bits you'd use for a simple tool.

Re: Rewriting in Rust

#52

Post by joshdavham »

antonvs wrote: post #18
joshdavham wrote: post #7

I would love it if jetbrains were to speed up IntelliJ. I started a new job writing Java professionally last year and, up that point, I had no idea that IDE's could actually be that slow. My company gave me a brand new, beefy Macbook pro and that thing can barely handle IntelliJ sometimes...

Just use VS Code. Its Java support isn’t the best, but it’s good enough and the rest of the IDE makes up for it. I feel like a lot of the love for IntelliJ is a sort of Stockholm Syndrome combined with relief at not using Eclipse.

I’ve been using cursor mainly (so sorta vscode in a way). I just use IntelliJ for unit tests and the debugger mainly.

Re: Rewriting in Rust

#53

Post by serbuvlad »

collinfunk wrote: post #9

Note, I am a co-maintainer of GNU coreutils. Whether that makes my opinion relevant, biased, or both, you can decide. :) I really wished the documented their benchmarking methodology here, or at least cautioned the reader not to jump to conclusions based on the benchmarks shown. GNU 'sort' performance can drastically be altered by the locale in use, the input, and the arguments given to the --buffer-size and --parall…

Hi, co-maintainer of GNU coreutils!

Is there any effort from the GNU organization to solve long-standing issues and pain points such as locales?

As it stands I am generally averse to using GNU tools because my feeling is that they will be slow, clunky and exhibit arcane behavior in particular edge cases. ripgrep is significantly faster than GNU grep -R; fd than GNU find, etc.

For example, before LLMs were common, I once had to spend an entire day getting GNU flex and GNU bison to generate code that was: a) properly prefixed with a custom prefix, not yy_ et. al and b) did not use global variables.

I would have understood if, for backwards compatibility, this was gated behind a --sane flag or similar, but the GNU manuals were, at least at the time, under the confusing impression that what I was doing was advanced usage and used semi-fancy terms like "re-enterant" to describe what should be the normal behavior. I had to toggle several different knobs, some working for macros, others for functions, and the knobs were different for flex and bison.

POSIX locales in particular are an anti-feature, and I say this as a non-English native, so uutils adding support for them feels like bug-compatibility with GNU, not feature-compatibility.

Other issues involve the dynamic linking requirements of glibc and of the nsswitch in a world that would increasingly prefer to link things statically.

I am really saddened if the reaction is just that GNU is the old and stable is the main argument here. Because when you read many GNU documents and manpages, written years ago, you get the feeling that the original authors were looking to do things properly, make breaking changes where they were sane (hence POSIXLY_CORRECT), innovate (Emacs), and overall would not have been particularly swayed by the "old and stable" argument of traditional Unix distributions at the time.

The Rust community seems to be the one making exciting innovative stuff nowadays. uucore is more complimentary as well, ripgrep and fd are much more interesting. Sure, there may be certainly kinks, as you pointed out. But Rust programs can be debugged. Can GNU programs innovate?

Re: Rewriting in Rust

#54

Post by vrighter »

TonyStr wrote: post #25
frollogaston wrote: post #23

Earlier quoted context omitted.

What most people mean when they say this is GC vs no GC. Rust is the latter. You have to care about ownership unless you're wrapping in Rc/Arc.

I agree with you, but I just want to point out that there are other seamless solutions to memory management like refcounting, used by for example GDscript (Swift? Perl?). You definitely wouldn't consider this manual memory management

if refcounting is gc, then c++ is a garbage collected language. It has std::shared_ptr

Re: Rewriting in Rust

#55

Post by BluSyn »

sashank_1509 wrote: post #21
BluSyn wrote: post #10

Small related anecdote: Was just testing latest gen LLM capabilities, and decided to give it goal of rewriting a small opensource project in Rust. (Should be noted: was not some tiny library, but an actually useful network service). It completed the entire rewrite from typescript to rust in about 2 hours, ~600k tokens used. Worked perfectly on first try with no follow up changes required. Memory and CPU usage now a t…

I’ve seen people do this and I’m always confused, do they believe they will never have to reason about the code ever again. I suppose if it is like the Zig Rewrite where essentially all development is being done by Claude, I can imagine this making sense. But in any other case, you had a codebase that presumably you wrote, you could reason about, you could refactor etc. and then you made it into a completely unintell…

This wasn't a codebase I originally wrote or cared to reason about deeply. It's fairly straight-forward rust, so not hard to understand or follow. Again, this was originally just a test to see how well it would work (better than I expected).

Not something I need to maintain much going forward, so I have no reason to manage the code manually ever.

Re: Rewriting in Rust

#57

Post by joshka »

This feels like a really good blog post to write - something I'd really want to read - but the generated AI prose distracts, and makes me lose trust and not want to read this. I'm very AI-pilled, so this is not a criticism of AI as a whole, just this piece.

Re: Rewriting in Rust

#58

Post by frollogaston »

ghusbands wrote: post #48
TonyStr wrote: post #25

Earlier quoted context omitted.

I agree with you, but I just want to point out that there are other seamless solutions to memory management like refcounting, used by for example GDscript (Swift? Perl?). You definitely wouldn't consider this manual memory management

Refcounting is indeed a form of GC (and the languages that want to handle cycles then need an extra form of GC on top of it).

GC specifically means you leave unreferenced mem on the heap until it gets collected in one big sweep later.

Re: Rewriting in Rust

#59

Post by frollogaston »

vrighter wrote: post #54
TonyStr wrote: post #25

Earlier quoted context omitted.

I agree with you, but I just want to point out that there are other seamless solutions to memory management like refcounting, used by for example GDscript (Swift? Perl?). You definitely wouldn't consider this manual memory management

if refcounting is gc, then c++ is a garbage collected language. It has std::shared_ptr

Refcounting isn't GC, but also C++ isn't a refcounted language. You could spam shared_ptr everywhere, but it's not designed for that and probably wouldn't be performant. And because of that, realistically all your libs take raw pointers, so you still have to unwrap your shared_ptrs then be back to managing ownership.

Swift has refcounting built into the language and assumed everywhere. You could always use raw refs in Swift, but that's not the norm.

Re: Rewriting in Rust

#60

Post by frollogaston »

TonyStr wrote: post #25
frollogaston wrote: post #23

Earlier quoted context omitted.

What most people mean when they say this is GC vs no GC. Rust is the latter. You have to care about ownership unless you're wrapping in Rc/Arc.

I agree with you, but I just want to point out that there are other seamless solutions to memory management like refcounting, used by for example GDscript (Swift? Perl?). You definitely wouldn't consider this manual memory management

I wouldn't consider Swift manually managed, but also not GC. And not being GC has some practical implications like needing to break cycles yourself, so you need to at least be aware of ownership a little. It's like a manual transmission vs automated manual vs true automatic, AMT removes most of the work but still cannot be treated like full auto.
Post reply on HN