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

Should I Rust or Should I Go?

kerkour.com

Post reply on HN
Print view View original

21–30 of 178 posts

Re: Should I Rust or Should I Go?

#21

Post by azakai »

jpgvm wrote: post #17

In what world is Go more reliable or faster than Java? Especially modern Java (or other good JVM languages like Kotlin). It compiles faster but that is about it. Which is a good thing too because it's verbose AF and heavily reliant on code generation even after generics shipped so that compiler lines/s actually matters. The only knock you can put on Java for reliability is null-safety but lets be real, nil pointers,…

Perhaps another factor the article was referring to is that Go compiles ahead of time to static binaries. Java is typically JIT compiled which means extra overhead and unpredictability at runtime as code warms up.

Re: Should I Rust or Should I Go?

#22

Post by Xeoncross »

jpgvm wrote: post #17

In what world is Go more reliable or faster than Java? Especially modern Java (or other good JVM languages like Kotlin). It compiles faster but that is about it. Which is a good thing too because it's verbose AF and heavily reliant on code generation even after generics shipped so that compiler lines/s actually matters. The only knock you can put on Java for reliability is null-safety but lets be real, nil pointers,…

> Java is easily faster and more reliable than Go

I work in Java for my day job and I disagree.

1. Cold starts for Java serverless (lambda) are worse than scripting languages

2. For everything else, Java uses 5-10x more memory than Go. The memory overhead difference is really noticeable while the CPU difference is often similar.

Re: Should I Rust or Should I Go?

#24

Post by husarcik »

tejinderss wrote: post #12
Animats wrote: post #8

- Webcrap - use Go. The arguments for Go for that use case is that 1) Google provides the libraries for most web back-end things you'll need, and since Google uses those libraries internally, even the obscure cases have been exercised, and 2) Goroutines are both low-cost and can block, so you don't have to face Rust async/thread combo hell. - Hard problems that have concurrency, performance issues, or have to be high…

Why Go for web and not Typescript with nodejs/deno. The ecosystem is also huge and widely used. The type system is miles ahead of Go and is closer to rust. The async await is single threaded too.

I question this myself as bun.js is approaching golang speeds.

Re: Should I Rust or Should I Go?

#25

Post by jpgvm »

tejinderss wrote: post #12
Animats wrote: post #8

- Webcrap - use Go. The arguments for Go for that use case is that 1) Google provides the libraries for most web back-end things you'll need, and since Google uses those libraries internally, even the obscure cases have been exercised, and 2) Goroutines are both low-cost and can block, so you don't have to face Rust async/thread combo hell. - Hard problems that have concurrency, performance issues, or have to be high…

Why Go for web and not Typescript with nodejs/deno. The ecosystem is also huge and widely used. The type system is miles ahead of Go and is closer to rust. The async await is single threaded too.

Why use an ecosystem that needs 2-3 layers of build tooling, none of which is designed to work together when you can use any of the sane stacks instead? Not to mention the hell that is Jest, Eslint and trying to make those play with aforementioned 2-3 layers of crap. Then you also have to put up all the downsides of purely single threaded concurrent programming instead of Go M:N model which is much less prone to problems like event loop exhaustion.

Go for all it's faults has one build system/tool and spits out machine code, hell it does that probably 10x faster than just tsc can typecheck.

Personally I don't like either but Go > Typescript seems like a no-brainer unless you are hell bent on the isomorphic code thing and all the extra work that entails. i.e. making sure someone doesn't reference window in an isomorphic lib or node APIs in the opposite scenario, etc.

Re: Should I Rust or Should I Go?

#26

Post by seurimas »

The features vs versions graph is more than a little nonsensical, and its conclusions even more so.

> They should be stable and move slowly so that most of the time of your develoeprs is not spent fighting with their tools.

I can't speak to Go's tooling base, but Rust's is head and shoulders above any other ecosystem that I've had to work with. This is definitely more a point in Rust's favor than against.

Re: Should I Rust or Should I Go?

#27

Post by Xeoncross »

tejinderss wrote: post #12
Animats wrote: post #8

- Webcrap - use Go. The arguments for Go for that use case is that 1) Google provides the libraries for most web back-end things you'll need, and since Google uses those libraries internally, even the obscure cases have been exercised, and 2) Goroutines are both low-cost and can block, so you don't have to face Rust async/thread combo hell. - Hard problems that have concurrency, performance issues, or have to be high…

Why Go for web and not Typescript with nodejs/deno. The ecosystem is also huge and widely used. The type system is miles ahead of Go and is closer to rust. The async await is single threaded too.

Go is significantly more performant and can natively use multiple CPU cores without needing work-arounds with things like service workers. I've had to convert a few node.js services to Go to overcome raw speed issues.

Rust is even better, but not everyone wants the added complexity on their projects.

(also, I haven't worked with bun yet)

Re: Should I Rust or Should I Go?

#29

Post by wbl »

Animats wrote: post #8

- Webcrap - use Go. The arguments for Go for that use case is that 1) Google provides the libraries for most web back-end things you'll need, and since Google uses those libraries internally, even the obscure cases have been exercised, and 2) Goroutines are both low-cost and can block, so you don't have to face Rust async/thread combo hell. - Hard problems that have concurrency, performance issues, or have to be high…

I've used Go and Rust for a number of highly scaled services that you've definitely interacted with if you do something online.

In my experience Go does fine with a lot of concurrency and the GC can make some dirty lockfree tricks a lot easier. It also has a much more mature contribution story: Go test, go bench etc. work the same and proff endpoints in production are a godsend. We never really had a time we couldn't have used Go.

Rust has a slight performance advantage with some sharp edges around designing for the borrow checker, as well as much less fleshed out core set of libraries. The C interop story is better and async does work but can get messy.

Overall I think the tradeoffs are in ease of understanding, experience of team and tooling vs. the extra bit of performance, and can go either way.

Re: Should I Rust or Should I Go?

#30

Post by jpgvm »

husarcik wrote: post #24
tejinderss wrote: post #12

Earlier quoted context omitted.

Why Go for web and not Typescript with nodejs/deno. The ecosystem is also huge and widely used. The type system is miles ahead of Go and is closer to rust. The async await is single threaded too.

I question this myself as bun.js is approaching golang speeds.

I highly doubt it's doing type checking though so you aren't going to be eliminating tsc from the picture even if you are using bun.js unless you want to just cross your fingers and hope for the best.
Post reply on HN