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

381–390 of 544 posts

Re: Migrating from Go to Rust

#381

Post by za3faran »

cube00 wrote: post #151
amelius wrote: post #69

Go has shorter and more predictable GC pauses. If a reference count drops to zero in Rust, it may take an unbounded time to free all the things it refers to (recursively if necessary).

I still prefer having deterministic control over when the free occurs. For example, I can transmit the response to the client and then free the memory afterwards so they're not kept waiting.

What if you have many clients that are constantly coming in, when do you decide to free the memory after sending their respective responses?

Re: Migrating from Go to Rust

#382

Post by hota_mazi »

fpoling wrote: post #275
physicsguy wrote: post #231

Earlier quoted context omitted.

> Rust still rely on many C and C++ libraries Yes but Rust has a lot more availability of libraries to do stuff as a result. Want to do anything ML or scientific? You at least have a route in Rust where you don’t with Go.

With Go basic stuff like url parsing or HTTPS support is written in Go and comes with the standard library. With Rust too many necessary things are just wrappers around C and C++ making cross-compilation and reproducible builds much harder to archive. As for availability if CGO is ok, then calling C or C++ code from Go is not that hard. Also, there is always an option to just start C++ process if extra data copies ar…

Nonsense, Rust has plenty of native libraries for HTTP and JSON.

Re: Migrating from Go to Rust

#383

Post by hota_mazi »

marcus_holmes wrote: post #138
the__alchemist wrote: post #135

Earlier quoted context omitted.

Interesting! Are Go backend building custom auth, admin, DB ORM/migrations/auto migrations, templates, email, dev server etc for each project? Or each person and org has their own toolkit they use?

We tend not to use ORMs, because they're evil. There are various libraries people use for auth, etc. But rolling your own isn't hard - Go has (e.g.) bcrypt in the standard library, so most of the heavy lifting is already done, you can write a solid auth implementation in Generally Go prefers libraries to frameworks. Wrap the hard bits up into a library that can then be used widely in any implementation, rather than r…

> We tend not to use ORMs, because they're evil.

This is typical Go culture. If it is not readily available in the language or the standard library, it's evil. It's an easy cop out to explain away the gaps in the ecosystem.

Not long ago, the Go team was saying that generics are evil for that very same reason.

Re: Migrating from Go to Rust

#384

Post by throwaway2037 »

Animats wrote: post #6

I could see migrating from C or C++ or Python to Rust, for various reasons, but for web back-end work Go is a good match. I write almost entirely in Rust, but the last time I had to do something web server side in Rust, I now wish I'd used Go. The OP points out the wordyness of Go's error syntax. That's a good point. Rust started with the same problem, and added the "?" syntax, which just does a return with an error…

What is "formal QA support"?

Re: Migrating from Go to Rust

#385

Post by nicce »

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.

I would be careful with this benchmark even thought it shows JIT efficiency. This is a special case which might not really reflect realworld - string was static? What if you use random string?

Re: Migrating from Go to Rust

#386

Post by cdelsolar »

pas wrote: post #301
ruicraveiro wrote: post #258

Earlier quoted context omitted.

Go was never about being easy to write (thought it is), but it was always about being easy to read and it is, by far, the easiest language to read that I've ever used (and throughout the decades, I went through Basic, Pascal, C, Java, JavaScript, C#, TypeScript, Ruby and Python). That becomes even more important if you are not writing the code yourself...

it's too verbose, yet not explicit. you need to know the conventions to spot what's not there (did you miss the error handling? or the magic comment for the whatever codegen serializer? c'est la vie!) edit: just a few comments below an even better description of what I'm trying to convey: https://news.ycombinator.com/item?id=48264853

Disagree, if you miss the error handling the code won’t compile (unless you return _, which should be easy to spot)

The magic comment stuff is very much “do it once” and it’s done (for example if using go generate).

Re: Migrating from Go to Rust

#388

Post by estebank »

dwattttt wrote: post #272
mook wrote: post #165

Earlier quoted context omitted.

Doesn't Rust already have that solved via editions? If anything, that's the language that's especially well positioned here.

I believe the stdlib can't be versioned like that: there's only one stdlib linked into a final artifact, you can't have two versions with differing APIs in there.

There's work on edition aware name resolution so that a type with the "nice path" can change over an edition while still accessible through a longer path, but 1) it's not implemented yet, 2) it hasn't been used yet (see 1), 3) if it is ever used it should be done very sparingly (because of the bafflement that can occur if someone follows older docs in the new edition, implementation will come with efforts to mitigate these problems).

Re: Migrating from Go to Rust

#390

Post by phplovesong »

christophilus wrote: post #323
Animats wrote: post #6

I could see migrating from C or C++ or Python to Rust, for various reasons, but for web back-end work Go is a good match. I write almost entirely in Rust, but the last time I had to do something web server side in Rust, I now wish I'd used Go. The OP points out the wordyness of Go's error syntax. That's a good point. Rust started with the same problem, and added the "?" syntax, which just does a return with an error…

I just hate how many dependencies you have to pull in for a typical Rust project vs Go. As far as Go being an ugly language, there are some interesting wrappers that put lipstick on that pig such as https://lisette.run/ But personally, I don’t mind Go at all. I’ve even begun to prefer it for some things. That may be Stockholm syndrome, though.

Been playing with Lisette for a few weeks, so far im really liking it. Think is has some potential.
Post reply on HN