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

161–170 of 178 posts

Re: Should I Rust or Should I Go?

#161

Post by za3faran »

super_flanker wrote: post #158
za3faran wrote: post #92

Earlier quoted context omitted.

Having worked on one of the largest golang code bases on the planet, I agree completely. I would always think to myself how much simpler and more reliable the programs I saw would have been in Java. But hype is hype I suppose, not to mention so many unsubstantiated claims.

Could you please tell a bit more about your project, I'm very curious.

It was a monorepo, with many hundreds of programs in it. I worked on a handful of them, but I was able to see what other people were writing.

Re: Should I Rust or Should I Go?

#162

Post by rcarr »

goku12 wrote: post #139
rcarr wrote: post #5

As someone who doesn't know either language, would love HN's opinion on this video that was recommended to me by another HN user on a Rust thread a few days ago: https://www.youtube.com/watch?v=p-tb1ZfkwgQ The general gist of the video is the creator prefer Rust for functional programming and programs without much state and Go for everything else. As someone who's coming from a React background I don't see why if Rus…

I have experience in Rust, but not in Go. The video was more informative than I expected - a lot of comparative insights into the type systems. Ocaml sounds interesting. And while personally prefer Rust for everything, I agree that Go might be the better choice if the developers have to learn it from scratch or have to develop the application quickly. Rust takes a lot of effort to reach the level where you can apprec…

Very informative reply, thank you

Re: Should I Rust or Should I Go?

#163

Post by jpgvm »

adrianmsmith wrote: post #150
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,…

> Non-blocking code with synchronous coding style? Virtual Threads are much much better than goroutines. That's going to need some justification. I work with Java and Go. I haven't worked with Virtual Threads yet but my understanding is Go's approach to goroutines and Java's approach to Virtual Threads are pretty much equivalent. (Channels, however, are quite different.) Let me know if I've missed something.

The runtime is similar, both are continuation based under the hood etc.

What sets VirtualThread apart is that all the support you get from the Java Stdlib. i.e ExecutorService and friends and now ThreadGroup with the improvements in Java 21. Not to mention the structured concurrency features that are planned to complement them. Another key difference is how much easier they interact with interrupts for cancelation without having to resort to context, channel and select hacks.

Compare this to Golang where this is very little tools for managing groups of goroutines. You have the sync package, specifically WaitGroup which get you some of the way there but it's still massively behind the equivalent JVM stdlib support for real concurrency. JVM has equivalents to everything in the sync package but in addition to that it for instance the collections library which contains ConcurrentHashMap, which naturally works perfectly with VirtualThreads vs Golang which map is not goroutine safe and you have to go outside the stdlib to get concurrent safe structures.

So yeah, if you are working in Java already you should checkout VirtualThread for your i/o intensive needs, especially if you were using Go for those tasks before.

Re: Should I Rust or Should I Go?

#164

Post by pjmlp »

imetatroll wrote: post #160
pjmlp wrote: post #142

Earlier quoted context omitted.

Also work in cloud and we only do .NET, Java, and node, coupled with C++ when needed. Anecdotes.

This particular thread is about golang use in google. So your comment doesn't appear to apply.

It is called Go, and whatever.

Re: Should I Rust or Should I Go?

#165

Post by littlestymaar »

necubi wrote: post #78
icholy wrote: post #75

Earlier quoted context omitted.

For all the praise cargo gets, the lack of namespaces seems like a pretty huge oversight :/

This is endlessly debated within the community (e.g., https://internals.rust-lang.org/t/blog-post-no-namespaces-in... ), and there's no consensus on whether namespaces would be an improvement

There's no consensus mostly because namespace proponent, despite all the noise they make, haven't been able to articulate a constructed argument about what namespace is actually bringing to the table.

For instance, most of them bring typosquatting as a problem that namespaces solve, yet they completely ignore namespace typosquatting: for instance instead of typosquatting `ripgrep` with `rigrep`, you'd typosquat `burntsushi/ripgrep` with `bunrtsushi/ripgrep`…

Re: Should I Rust or Should I Go?

#166

Post by jpgvm »

User23 wrote: post #153
jpgvm wrote: post #115

Earlier quoted context omitted.

I agree that Java definitely strikes a middle ground. It has enough features you can write code in the ways you want (generics, first class functions) but not so many you can create unintelligible messes (implicits). I generally tend to think of Java is "truly general purpose" because it has enough speed/scalability to implement a database while being generally easy enough for beginners to learn and providing enough…

> Java I would still call verbose, it's more verbosity than I tolerated when I was greener but I have come to appreciate a certain amount of ceremony isn't necessarily bad - if it helps to efficiently communicate the intent of the programmer. In my experience the trick with Java is to use a purpose built editor like Eclipse or IntelliJ. Once you've achieved competence with an appropriate tool the syntax kind of fades…

100% agree.

It was tough coming from a VIM only workflow to IntelliJ but I am really glad I toughed out the transition.

The power is in how all the tooling comes together but it requires a certain investment to get there.

Re: Should I Rust or Should I Go?

#167

Post by timeon »

a_wild_dandan wrote: post #76
endisneigh wrote: post #56

Earlier quoted context omitted.

Yes, Javascript is single threaded. This has its benefits and drawbacks. In many applications using the Cluster API is enough, but as you said you'll never be able to do super performance stuff with Javascript, but you can use NAPI and call Rust if you'd like. Memory usage is pretty good with Go, yes. I'm skeptical how much this matters in a real world application, though.

HN's memory usage obsession is basically a meme now. You'll see vastly more JS consternation here for RAM usage than praise for benefits like getting MVPs up stunningly fast, having a gigantic hiring pool, using one codebase to deploy on every major platform, etc. (These critics are often ironically the same folks who endorse avoiding premature optimization.) And hey, memory usage can be crucial! But the community's…

Is it really meme? There is often opinion that developer and business friendly process is more important than user experience and energy resources.

I do not think that there is single narrative.

Re: Should I Rust or Should I Go?

#169

Post by assbuttbuttass »

pjmlp wrote: post #159
assbuttbuttass wrote: post #148

Earlier quoted context omitted.

That's surprising to me, I don't think .NET or node are approved languages at Google. Are you part of some acquisition?

I work in cloud, as in, cloud native development, targeting AWS and Azure based infrastructure.

Ah got it. I was talking about Google Cloud

Re: Should I Rust or Should I Go?

#170

Post by FullyFunctional »

tome wrote: post #145
FullyFunctional wrote: post #134

Earlier quoted context omitted.

"Rust makes you think about everything you're doing ... overhead for people who just want to move fast." Honestly, I find it much easier to move fast in Rust because for explorative code, I just bang out the code and used copy/clone liberally and once I have a skeleton it's usually a few iteration until rustc agrees to compile my code. Strong types makes it very easy for me to move fast. Doing this in C/C++ never wor…

> I don't think Rust is over-hyped; almost everything I would have used Haskell for I do in Rust now. As a Haskell fan this is very interesting! What sort of things do you write where you find Rust is a better fit? No code that I write in Haskell would be much better off without GC so I struggle to think of reasons Rust could be a better fit.

The _language_ isn't a vast advantage; the type system is near-identical (which is important). Both have their advantages, but the ecosystem (tools, crates, documentation, educational material, community) is so much better and richer in Rust, and of course wrt. performance and memory frugality, Haskell doesn't even compete. (I haven't never been able to use Haskell professionally because of that, but I use Rust for work now).

Something things about Haskell have always boggled my mind: integer overflows aren't caught (so much for safety) and the argument for this choice was performance, but at the same time, the default string type is a linked list of characters. In fact, Haskell relies far too much on lists. In Rust, the rough equivalent is Vec and Vec slices, which takes less memory, is much easier to parallelize, and is just much faster overall.

It is true that garbage collected languages allow more flexibility than languages with an ownership model (~ linear types), but so far I have been able to work with this and the end result usually benefits (I haven't had to use interior mutability yet).

Disclaimer: I'm neither a Haskell or Rust expert, but probably equally intermediate in both.

Post reply on HN