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

111–120 of 178 posts

Re: Should I Rust or Should I Go?

#111

Post by erik_seaberg »

pram wrote: post #101
zelphirkalt wrote: post #53

Earlier quoted context omitted.

I think you need to qualify the aspects, in which you think Rust is 7-8 years back. I rather have the impression, that the designers of the Go language had a too simplistic view of what Go should offer and then it took them 12 years to get something as common as generics. Rust has many language features and of course had generics waaay before Go. In general it seems the Rust ecosystem does sometimes have things later…

Shocking but true: you could program things in Go before generics.

Now a pile of legacy code needs to be burned to the ground and replaced (it sounds like a lot of Kubernetes was generated to work around it). In the Java ecosystem we’re fortunate that this is long since finished.

Re: Should I Rust or Should I Go?

#112

Post by emi2k01 »

eikenberry wrote: post #81
seurimas wrote: post #26

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.

Go's tooling is much better in one key aspect, compile times. Rust's compile times and feedback loop are terrible and it is not a community priority (ie. they want to make it faster, but only incrementally and not the orders of magnitude improvement it needs). Go's could be better but at least it is a priority.

Rust's compile times are worse than Go but are still way better than people make it to be.

Here are some examples:

---

Rust Analyzer:

Clean build: 31.02s

Incremental build: 3.07s (Added a `println!` in a level-2 dependency in the dependency graph)

SLOC: 306,467

SLOC of dependencies: ~879,304 (After removing `win*` packages which make up for another 1.3M)

---

Zola:

Clean build: 24.58s

Incremental build: 1.34s (Added a `println!` in a level-2 dependency in the dependency graph)

SLOC: 17,233

SLOC of dependencies: ~2,087,781 (After removing `win*` packages which make up for another 1.3M)

Obviously, not all source code gets compiled due to conditional compilation but it makes for a good approximate if you only take into account 2/3 of it.

---

For comparison with Zig by building ZLS:

Clean build: 20.13s

Incremental build: 10.27s (I believe this builds the ZLS package again from scratch so not really incremental)

SLOC: 45,806

SLOC of dependencies: I don't know how to get this.

---

This was on a Ryzen 5600x

Re: Should I Rust or Should I Go?

#113

Post by jpgvm »

smitty1e wrote: post #95
jpgvm wrote: post #47

Earlier quoted context omitted.

Oh I am well aware of Java's warts and you hit a few of them but they are clearly -not- performance or reliability. Yes there are lots of things that suck about Java and the JVM but you can't in good faith argue that it's slow and unreliable.

Once it hits full stride, sure. While not a Java dev, I work with plenty of Java enterprise systems (looking at you, ElasticSearch, and probably big chunks of AWS). One appreciates the engineering durability of it all. I do refer to the healthy startup time for the cluster as the "Java pause". Perhaps that's a cheap shot, blaming the language, given that we're getting rich logging and a predictable approach that make…

Yeah the JVM definitely makes tradeoffs that adversely affect startup time, things like autowiring DI, etc all contribute to this - it's not just the runtime. It can be slightly annoying so periodically effort is invested to make it fast again, see recent Spring Boot startup speeds which are pretty damn quick now but can be made super fast with static wiring. (all without needing to resort to CRaC or AoT)

I was really getting at the fact that you can't reasonably call something unreliable or slow when it's probably powering some of your most loved (and performant) distributed systems that your applications rely on - doubly so if you are running on AWS or GCP. If it was either unreliable or slow, let alone both it wouldn't be fit for purpose.

Re: Should I Rust or Should I Go?

#114

Post by throwawa14223 »

steveklabnik wrote: post #97
throwawa14223 wrote: post #64

> I think that a modular and rich standard library such as Go's or Node.js's offers way higher productivity to developers, consistency to the ecosystem and reduced costs for businesses. Is the Go standard library really considered rich? Coming from languages like python or ruby I found it pretty lacking. Admittedly I haven't used Go in 3 years.

All of these things are a spectrum. For network services especially, Go's standard library is generally considered pretty comprehensive, yes. In comparison to Rust specifically, like the context of the post, I don't think anyone could really argue a different way, though if you're comparing to something else, or for a different kind of task, it's possible that you may have a different opinion, sure.

I felt like it had a lot to do things web related but was pretty lacking on primitives for algorithms and data structures out of the box.

Re: Should I Rust or Should I Go?

#115

Post by jpgvm »

za3faran wrote: post #94
User23 wrote: post #39

Earlier quoted context omitted.

I’ve heard three main arguments in favor of using Go. First, that it has a standard library that is world class for building a worldwide ads serving network. If your use case is that or something that’s technically similar, then it’s great. Second, Go has extremely limited facilities for abstraction. Frankly, I dislike that about it, but the argument is that forcing programmers to use a quite limited set of abstracti…

> that it has a standard library that is world class for building a worldwide ads serving network What does the golang standard lib have for that use case that Java doesn't have, or do better? > but the argument is that forcing programmers to use a quite limited set of abstractions makes code more readable There's a good balance. Sure you can probably argue that Scala opens the door for many different ways to write a…

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 scope and structure for building big line of business applications (where only really C# competes). Outside of embedded (excluding smart cards) and the browser mono-language you would be hard pressed to find a field that you can't use JVM to effectively solve a problem.

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.

I guess what I am trying to say is Java is easy to read, easier even than Go IMO because Go's verbosity is in the wrong places, i.e error handling, loop iteration ceremony, struct construction, etc. while Java's is more inherent to class/application structure which does more to communicate intent.

One thing I did like about Go though from a readability perspective though was their take on visibility. By eliminating the public/private/internal visibility modifiers as seen in JVM code it becomes simple at a glance no matter where you are in the codebase if a method is part of a public API or not just based on it's capitalisation.

Re: Should I Rust or Should I Go?

#116

Post by jpgvm »

arccy wrote: post #59
jpgvm wrote: post #51

Earlier quoted context omitted.

Yeah those are all good reasons to consider Go. I think the static binary argument is a bit flat though. With Java I don't even need to compile for multiple architectures, I can copy a fat-JAR onto any machine with a JVM and it will execute. i.e an artifact with exactly the same hash and no worries about Mac OS X DNS resolver weirdness or CGO nonsense.

but now you have the nonsense of dealing with jvm versions and choosing the right one

That is fairly overblown, especially post Java 9 (2017).

Generally speaking you just target a minimum version if you want to not distribute the JVM itself but these days most Java software is backend software, most of which is containerized, packaging the runtime with the code itself.

Re: Should I Rust or Should I Go?

#117

Post by cutler »

jpgvm wrote: post #51
User23 wrote: post #39

Earlier quoted context omitted.

I’ve heard three main arguments in favor of using Go. First, that it has a standard library that is world class for building a worldwide ads serving network. If your use case is that or something that’s technically similar, then it’s great. Second, Go has extremely limited facilities for abstraction. Frankly, I dislike that about it, but the argument is that forcing programmers to use a quite limited set of abstracti…

Yeah those are all good reasons to consider Go. I think the static binary argument is a bit flat though. With Java I don't even need to compile for multiple architectures, I can copy a fat-JAR onto any machine with a JVM and it will execute. i.e an artifact with exactly the same hash and no worries about Mac OS X DNS resolver weirdness or CGO nonsense.

But bad news if you actually need a decent interface to C libraries.

Re: Should I Rust or Should I Go?

#118

Post by microflash »

Xeoncross wrote: post #22
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.

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

I've run plenty of Java applications in Lambda and they are pretty fast (like done in a few minutes fast). I've yet to try SnapStart which can make those workloads even faster.

Re: Should I Rust or Should I Go?

#120

Post by horeszko »

Ok, so I'm no expert on Rust or Go or whatever, but I've noticed that many posts and comments seem to rip on Go, and that Go is bad, Rust is better, language X is better than Go, etc etc.

My question is why all the hate on Go? And if Go is so bad as these posts claim, why compare everything against it?

I'm not saying Rust isn't good or anything like that, but why the never ending hit pieces on Go? Lets just evaluate Rust or any language on its own merits.

I agree comparisons can be useful but its getting out of hand with these never ending Rust vs. Go pieces.

Post reply on HN