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

Migrating from Go to Rust

corrode.dev

Post reply on HN
Print view View original

441–450 of 544 posts

Re: Migrating from Go to Rust

#441

Post by wting »

tptacek wrote: post #417
pas wrote: post #317

Earlier quoted context omitted.

Rust's stdlib is small, Go took more of Python's "batteries included" strategy. So in that sense it seems like a category error to try to look for crypto stuff in the standard library. Of course this brings the well known problem of "okay, but then which one should I use?". Nowadays this is largely solved by a few web searches and LLM queries, and people are quite helpful at https://old.reddit.com/r/rust/ . Go was sh…

Have you argued yourself to "it's a bad thing that the Go standard library has a cryptography library"?

Rust has clearly opined that they prefer a small standard library and a "choose your own libraries" vs "batteries included" approach.

If Rust included a crypto lib and a vulnerability was discovered, many fixes are backwards incompatible. Rust maintains strict backwards compatibility, which means updating the relevant crypto functions in the std lib would necessitate a major version bump. By keeping crypto outside of std, it allows the community to make backwards incompatible changes at a higher pace.

Python handles backward incompatibility changes via multi-year deprecations. I'm not familiar with Golang but a quick Google search reveals that it deals with this by using feature flags via GODEBUG. Excessive feature flag use is a bad pattern in my experience years ago, but I don't know if that's applicable here.

I prefer the trade-offs of a "choose your own lib" approach, but I understand the advantages and preferences of those who prefer a "batteries included" approach.

Re: Migrating from Go to Rust

#442

Post by Aurornis »

hu3 wrote: post #128
tempest_ wrote: post #93

Earlier quoted context omitted.

The use of LLMs has caused Rust usage to explode. If youre not writing the code yourself and vibing away which I think most people generally are despite the disdain around here then why would you not choose the "more performant language" (I know that isnt necessarily reality but it is a common perception). Go's managed runtime is less valuable when the LLM is perfectly happy to slap a bunch of stuff together for you…

Correction: The use of LLMs has caused every major language usage to explode. And as mentioned in other comments, Rust slow compilation can be detrimental to LLMs + fast iteration speed. And it's not just speed, Tauri takes 20GB of disk space to compile. It's bonkers. This is npm/js ecosystem all over again but slower. Another reason to pick Go if you're leaning on LLMs is the standard library. Often you can do more…

> And it's not just speed, Tauri takes 20GB of disk space to compile

I’ve worked with enough UI frameworks and large applications that this doesn’t sound unreasonable. It’s a smaller disk footprint than I’ve needed for several other C++ codebases with similar scope.

Re: Migrating from Go to Rust

#443

Post by chlorion »

rr808 wrote: post #392

One reason I like Go is the fast compile. Rust really slows you down. Esp in days of AI when agents are building/testing in cycles.

How large are your rust projects?

I am able to write rust on a moto g power (a cheap android smartphone) inside of termux, running on battery, in battery saver mode, and cached compile times for every single one of my projects is under 5s easily, if not faster. Fast enough that I don't notice it at all.

Even a "cold" compile was under 1 minute for me, and I have a decent amount of deps.

I guess my projects are fairly small compared to others though so idk.

Re: Migrating from Go to Rust

#444

Post by satvikpendem »

gritzko wrote: post #420
x-yl wrote: post #244

Earlier quoted context omitted.

In my experience LLMs (I speak mainly of Claude Code & Cursor) write very poor quality Rust. They treat it like it's JavaScript, falling back to using String/&str needlessly instead of making new types. They do ugly `static Mutex Of course these are all surmountable with an experienced developer to regularly step in and unfuck the code, but forcing them into 'harder' territory where every problem is not solved by a .…

That is interesting. I make LLMs write C with the general hope that a simpler language they can manage well. That is not entirely true, though. They reason about C fluently indeed. The problem is, Claude pumps lots of bad C into the codebase if left unattended for 5 min. So, I need some clean-up passes afterwards to get to some acceptable quality level (both by LLMs and my own eyes). At which point, Claude sees the p…

> general hope that a simpler language they can manage well

It's the opposite; a language with lots of guardrails allows the AI to write better code especially as it is able to use the compiler and linter to guide it through the process. It's why OpenAI for example was able to disprove some recent theorem recently, due to the LLM converting its thoughts into a formal language theorem prover to then check its work.

Re: Migrating from Go to Rust

#445

Post by chlorion »

za3faran wrote: post #359
nicce wrote: post #332

Earlier quoted context omitted.

> other network services better than the JVM with its hot spot? JVM hotspot optimization is just band-aid for something Rust does always everywhere naturally? Assuming that you use lifetimes etc properly and not going to Arc rampage.

Rust: concat/string time: [77.801 ns 78.103 ns 78.430 ns] change: [+0.0275% +0.3169% +0.6169%] (p = 0.03 Java Benchmarks.concat string avgt 15 8.632 ± 0.105 ns/op Benchmarks.format string avgt 15 64.971 ± 1.406 ns/op Java's string concat is faster than rust's offerings.

Java is probably able to bump allocate memory or something similar, where rust is using a general purpose allocator.

I guess if you are formatting strings constantly this is important, but you can also use a bump allocator in rust if you really wanted to.

Re: Migrating from Go to Rust

#446

Post by wanderlust123 »

Luker88 wrote: post #315
wanderlust123 wrote: post #305

Earlier quoted context omitted.

The simplicity of Go is a feature…

I have to come to believe that Go is simple for the compiler , not necessarily for the programmer. `nil` is not simpler than references and Option . lack of enum is complicating my code. automatic type promotion is a hidden bug waiting to happen and preventing proper strong types, lack of `?` is making things verbose. struct tags look simple, until you realize they are hiding a ton of code and creating a ton of corne…

I find working with Go a lot like working with Lego. I agree it lacks some nice primitives (Result / Option types as you mentioned) and nil pointers is a flaw, but overall sheer plug and play nature of the language makes it highly productive. There is simply a lot less compiler gymnastics between what I want to code and how to get there. Combined with LLMs to do sanity checks it’s pretty nice to work with.

Re: Migrating from Go to Rust

#447

Post by bborud »

pas wrote: post #317
bborud wrote: post #296

Earlier quoted context omitted.

For the vast majority of software you want a managed runtime. Some of the problems Rust “solves” are problems you shouldn’t be having in the first place because we mostly write software that doesn’t need direct control over memory. Borrow checking isn’t something you want to have to deal with - it is something you have to accept when you have chosen to manage memory. That choice has a high cost that cost never gets p…

Rust's stdlib is small, Go took more of Python's "batteries included" strategy. So in that sense it seems like a category error to try to look for crypto stuff in the standard library. Of course this brings the well known problem of "okay, but then which one should I use?". Nowadays this is largely solved by a few web searches and LLM queries, and people are quite helpful at https://old.reddit.com/r/rust/ . Go was sh…

It turns out that the needs of Google overlaps significantly with the needs of software engineers outside Google. That argument could have been valid for a while after its initial release. But now it is just a lazy argument today.

I think batteries included is a better strategy. To the degree where I think Rust should reconsider this decision.

Re: Migrating from Go to Rust

#449

Post by awesome_dude »

dxdm wrote: post #416
awesome_dude wrote: post #33

Earlier quoted context omitted.

Package management is the bane of nearly every language/technology Nobody has "solved" it, and I don't think that there will ever be one (never say never, though, right?) For Go we rely on developers of libraries to adhere to the semver versioning scheme accurately, and we cannot "pin" versions (a personal bugbear of mine) There is a couple of workarounds - using SHAs not unlike the git commit hash to provide a pseud…

> I had the misfortune of having to use Python with a virtual env on the weekend - it did not end well, and reminded me why I migrated away from Python. I see this sentiment a lot, and it doesn't match my experience at all. In my decade-old bubble of using Python professionally, I've never had an issue with virtualenvs. The few issues I might've had with dependency resolution must be so far in the past that I don't r…

I used Python for a decade (professionally), gave up on it once I started using Go (professionally) in earnest - about 8 or 9 years ago.

I never liked virtual envs, having to remember where they were, what their names were, and what was installed into each one was a pain point for me.

This weekend I was trying to learn some AWS stuffs, and I cloned the official repo of example code which was Python. I followed the directions exactly and ... boom Python versioning issues... inside the freaking venv

Who needs that?

Why do I need to spend the better part of a couple of hours debugging a versioning problem? (FTR The problem turned out to be the repo was hardcoded to 3.8 and my local Python was 3.9.. or something along those lines - you are welcome to correct me, but that's what I remember of a painful waste of my time)

With Go I have backward compatibility guarantees - usually (there have been instances in the past where the backward guarantee have been broken AND the build process got broken hard for modules, with the claim that it was external and therefore not subject to the same guarantees)

> I see this sentiment a lot, and it doesn't match my experience at all.

My old HCI professor used to tell me - if users are complaining (or producing workarounds like post-it notes on their monitors) - regardless of how clean or elegant you think the system is - it's not.

You're saying you see people complain about it a lot - therefore it's a genuine problem.

Re: Migrating from Go to Rust

#450

Post by awesome_dude »

mxey wrote: post #394
awesome_dude wrote: post #33

Earlier quoted context omitted.

Package management is the bane of nearly every language/technology Nobody has "solved" it, and I don't think that there will ever be one (never say never, though, right?) For Go we rely on developers of libraries to adhere to the semver versioning scheme accurately, and we cannot "pin" versions (a personal bugbear of mine) There is a couple of workarounds - using SHAs not unlike the git commit hash to provide a pseud…

Actually with Go modules you are always pinning dependencies. What’s in your go.mod is what is used. If your go.mod needs to be updated because a dependency wants to bring in a newer version of a transient dependency, the go.mod has to be modified (by the go command, not by you)

I don't think you understand the term "pinning"

go mod tidy will update your go modules whenever it feels it needs to and there's nothing you can do to stop it.

The workaround is vendoring, where you control the versions in a cache.

Post reply on HN