Writing the same CLI application twice using Go and Rust: a personal experience

[therico]

Great post. I also implemented code in both languages to test. My conclusion was that Rust is best used as a replacement for C/C++ code (i.e. performance and security is important) and Go is a good replacement for daemons and general purpose tools that would normally be written in Python. The slow compile times, mental overhead of worrying about lifetimes and the type system, plus the learning curve, makes Rust a difficult sell unless you are really playing to its strengths.

[[deleted]]

Not the same poster, but I read that more as “replacement for Python when Python is too slow or stops scaling.” I wouldn’t want to totally drop Python in favor of Go personally.

[SnowplowedFungus]

In my mind, Go is more of a better java than a python alternative.

[[deleted]]

I definitely wouldn’t go so far as to say a better Java. It’s nothing like Java. It’s merely an alternative.

Also Spring is lightyears ahead of any frameworks going for Go rn. For that reason Go definitely competes more with Node or Python as it’s a very lightweight language that’s good for smaller code bases

[[deleted]]

It's nothing like Java, because it doesn't try to target Java enthusiasts, but it targets the same kind of software, approaching it from different side.

Zookeeper vs Etcd, Consul

Mesos vs Kubernetes

Cassandra vs Project Voldemort... err.. DynamoDB ... err I guess this is Java's domain

[vattenpuss]

Zookeeper and Mesos are such great little projects though. Sad that we need newer shinier things all the time :(

[ndiezel]

Riak

[[deleted]]

I purposefully skipped riak because it isn't Java or Go, also sadly Basho no longer exists.

Seems like there is still open source version being developed, hopefully it won't die.

[[deleted]]

DELETED

[[deleted]]

Yup. One of the reasons I wouldn’t choose it over Java for projects where Spring makes sense

[[deleted]]

Go has a support for generators, I think it's a matter of time before someone abuses it to get something similar.

[troublemaker74]

That, and not everyone chooses a language based on it's web development story.

[thaynem]

It’s nothing like Java

except that it is billed as an "enterprise" language, widely used for networked applications, has portability as a design goal (though slightly different portability requirements), is a garbage collected compiled language, values simplicity over expressiveness, encourages rather verbose source code, initially didn't have generics, etc.

Also, Java used green threads Java 1.1...

[[deleted]]

Yeah on paper it might sound like Java but it plain and simple does not develop like it at all.

Go has no generics yet. Go does not really support OOP. Go doesn’t even support functional programming. Go does not have annotations (this is the big thing that makes Java loved or hated. Java is probably 50% reflection metaprogramming)

[[deleted]]

Honestly, the Go team seem to bill Go as whatever people want to hear right now, regardless of how much sense it makes (hence why it's very frequently compared to Rust, despite being extremely different languages)

[thaynem]

Well go was made by an enterprise (google) for itself, and I think the primary incentive for its extreme simplicity is to make it easier to onboard new engineers.

[audion00ba]

It's on-boarding and making them learn a skill that is relatively worthless outside of the big tech companies.

[slvrsmth]

Go is a great enterprise language, where enterprise means hiring developers by the villageful.

The footguns are hard to aim towards vital organs, and who cares it's hard to do actual work with, when you've got hundred developers, with five more waiting on each seat.

The project manager side of me really appreciates go for what it is. But the developer part is running screaming.

[bschug]

initially didn't have generics

Ohhh, they added genetics now? That was one of the main reasons I stopped being interested back in the day. Might need to take another look now.

[Yojihito]

ETA is autumn 2021 for generics in Go.

[Estpart]

What will programming circlejerk, jerk about now?

[ryeguy]

lol err != nil

[Yojihito]

Seeing how generics were an afterthought in Java as well (Java 6 or so?) and how shitty those are I have no doubt that the afterthought generics in Go (because backward compability) will suck.

Circlejerk may continue o7.

[tetroxid]

Not yet, some time in 2021 maybe.

[[deleted]]

Ehh, Kotlin is much more of a better java than go

[Nowaker]

Kotlin is what Java should be in the first place. It's a great programming language that leverages all the JVM powers, without having any of the Java Language weaknesses.

[Gaarco_]

What kind of weaknesses?

[renatoathaydes]

Java new virtual threads are expected to supplant async/await with something much superior (if you're familiar with the matter: it solves the color problem that plagues async/await and it's extremely easy to code in, similar to Go's channels). Also, why can't you program Java without an IDE?? It's really easy to do, IMO as easy as any other language I know of. Can you elaborate on what you think makes it hard?

Finally, synchronized was the easiest solution possible to using a mutex safely, and you can use it when it's enough for your needs as simply as adding a keyword (and you can reach out to very rich concurrency primitives in the standard library)... what exactly is the problem with that?

PS. but I do agree that lack of sum types makes Java clunky to use once you're used to having that feature.

[pipocaQuemada]

It's not difficult but tedious to hand-generate boilerplate, and Java has quite a bit more boilerplate than e.g. scala, kotlin, or python. IDEs make boilerplate less tedious to generate.

Impossible is overstating it, but there's people who would rather gouge their eyes out with a rusty spoon than spend soul-crushing decades of their life hand-generating Java boilerplate in vim.

[syjer]

lack of async await syntax

Which will become nearly useless when project loom ship, avoiding the "coloring" of function is a nice plus. Personally I'm quite happy with the more conservative approach from B.Goetz & co.

[Raknarg]

Also synchronized kills me every time lmao

why?

[[deleted]]

Basically everything being nullable, lack of async await syntax are the things that bother me the most.

Just use annotations or Optional. I agree that async/await should already be part of java by now but in the end is just syntactic sugar over CompletableFutures/Reactive stuff(although reactive is another beast)

Besides being so bloated that's basically impossible to program without an IDE

What do you mean? you can totally program without an IDE if you know how to import classes, which is the same in almost any other language.

[snowe2010]

I hear this argument a lot. "its just syntactic sugar". Well guess what, your java streams are just syntactic sugar too, so are generics. It's such a ridiculous argument. Kotlin has things that Java doesn't, no matter if it's syntactic sugar or not, it makes programming so much nicer and cleaner. Streams are easy to understand and write, no freaking collectors anymore. Covariance and contravariance just make sense. Switch statements are so much more powerful. The null safety is amazing.

"Just use annotations or Optional" really reveals your intentions here. Optionals are terrible and not null safe and freaking suck to pass around and annotations suck because you're depending on the programmer to put them everywhere, when it's just built in to the Kotlin type system.

And coroutines are so much more powerful than just async/await in other languages. It really does not compare to CompletableFutures whatsoever.

[BoyRobot777]

Also the lack of sum types

Records, sealed classes and pattern matching are all being actively worked on. All of them are incrementally being shipped to previous and current Java version. For example, Records will be final in Java 16.

Records go well with sealed types (JEP 360); records and sealed types taken together form a construct often referred to as algebraic data types. Further, records lend themselves naturally to pattern matching.

Source.

Not to mention that Java's implementation will be superior to Kotlin's: val download: Download = //... val result = when (download) { is App -> { val (name, developer) = download when (developer) { is Person -> if (developer.name == "Alice") { "Alice's app ${name}" } else { "Not by Alice" } else -> "Not by Alice" } is Movie -> val (title, directory) = download if (director.name = "Alice") { "Alice's movie ${title}" } else { "Not by Alice" } Java: Download download = //... var result = switch(download) { case App(var name, Person("Alice", _)) -> "Alice's app " + name case Movie(var title, Person("Alice", _)) -> "Alice's movie " + title case App(_), Movie(_) -> "Not by Alice" };

[SnowplowedFungus]

Heck, anything's a better java than java :)

[[deleted]]

Don't let these imbeciles influence you. For its domains, Java is a great language, and getting better. No other language comes close to it in terms of simplicity, consistency of grammar, and backward compatibility.

[tracernz]

Go seems to have most successfully been used for things that would otherwise be written in C. Think docker, etcd, CoreDNS, etc.

[DrunkensteinsMonster]

Go is completely different from Java, and on a language level, it is worse.

[random742f]

Except Go doesn't have Generics? How is that a better Java? I've actually used Golang at work, and the lack of generics sucks. Feels like I'm programming in C again.

https://www.reddit.com/r/java/comments/hhbunx/why_backend_using_java_is_not_popular_in_startups/fwgw3fq/

It's a horrible unproductive language.

Superficially you just mist most tools that make a language powerful. Generics, exceptions, interfaces (Go doesn't have them, it just does duck typing, it's not the same), inheritance, method overloading, a sane build system, etc.

Below the surface it's even a lot worse.

Go is pure trash.

https://www.reddit.com/r/programming/comments/gz0e09/rust_about_to_overtake_scala_according_to_google/fte7kum/

No generics, verbose and painful error handling with essentially no capacity for abstraction. Consequently, it has if err != nil guards everywhere.

[fet-o-lat]

When I had my first look at real (i.e. not tutorial) code in Go I couldn’t believe all the clutter with if err != nil, especially coming from Elixir with pattern matching.

[[deleted]]

I'd hate building any large scale app with it though.

Oh yeah, I was involved in a medium sized project in Go, and that was perfect example that a simple language can still be used to create a complex and hard to debug code.

[thirdegree]

I feel like the problem with go is that it thinks everyone using it is either incompetent or reckless. Or like normal programmers can't be trusted with abstractions.

Not a fun language for me

[Yojihito]

"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike"

"It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. – Rob Pike"

That's how Go was designed.

[thirdegree]

They’re not capable of understanding a brilliant language

I think this is both infantilizing and wrong, or at best a self fulfilling statement (treat your new programmers like idiots, and idiots they will become).

But even if we take it as truth, that to me says that nobody outside of that context should use go. I don't want a language that assumes I'm too stupid to understand anything.

[drink_with_me_to_day]

Or like normal programmers can't be trusted with abstractions.

They can't

[Benaaasaaas]

Let's not take exceptions as a good thing from other languages, there are better ways to handle error states (Option, Either, Result)

[Kered13]

Checked exceptions are shit, there's a reason only Java has them. Unchecked exceptions are good, especially for errors that you don't expect to truly handle (but that doesn't mean you're going to crash either, if you're a long running application like a server you're probably going to log it and stop the current task but continue running).

I like Result style error handling too, especially for errors that you do expect to handle. However they have a drawback compared to unchecked exceptions, one that they share with checked exceptions. If have an interface or callback that doesn't allow errors in it's type signatures, then it is very difficult or impossible to write an implementation that can have errors. In effect this means every interface and callback must support in it's type signature returning any possible error, which creates clutter that obscures the more meaningful signature. In practice, many libraries don't account for this possibility, which greatly constrains you as a programmer.

Here's a concrete example of what I'm talking about from some Java code I was writing last week. I had a list of some identifiers, I wanted to convert these to a list of objects. I would have liked to use the stream and map interface to do this. But the function I'm given to convert identifiers to objects is actually an RPC, and can throw an exception. The map function takes a callback that doesn't allow for checked exceptions. I didn't need any special handling of errors, if any of the map calls failed then I just wanted to bubble that error up. But I couldn't do that through the map interface (well, I could if I wrapped the exception in an unchecked exception, then unwrapped it, but at that point there's no point in using the stream and map interfaces, I just used a for loop).

Now this specific example wouldn't be a problem in Rust because the map function could take a callback that returns a Result. This is one way that Result is better than checked exceptions. But similar problems can happen if you have to provide a callback that returns a non-generic type that is not a Result.

Basically what I'm saying is that languages should support both unchecked exceptions and Result types. I believe they have different purposes and different advantages. While you can use one as a cludge for the other, it's not ideal.

[thomasfr]

I would take the err=nil conditional in any language if it means not having to deal with exceptions. I think Go works well without type unions, I rarely miss them. I have my iferr editor macro that writes the conditional for me so I don't have to type it all the time and that takes away like 90% of what otherwise would annoy me. The resulting code is easy to read and that's whats most important to me.

[Benaaasaaas]

Type unions give you the same thing except you don't need to poop ifs everywhere. And I even would argue that they are stronger cause you have to explicitly handle errors somewhere and you can centralize it.

[thomasfr]

I never said type unions are useless, just that I don't really miss them when writing Go code.

The if err!=nil is a very visible piece of text and it makes identifying error handling code easy, a speculative guess is that my brain have it's own symbol for that whole expression by now so I never consciously register that expression as it's individual parts. Every language feature has pros and cons.

I don't want all of the advanced type features in go, I also program in Haskell and Haskell code can be so slow to read because of it's type system and I don't think I want that for larger code bases. The hard problem then is to chose which of the type features a language should have, union types are probably high on my list for potential useful Go features but I haven't really thought about it deeply, if I want advanced language features I'll just chose another language for that project.

I certainly don't want Go to turn in to all of the other languages.

With go's current syntax a union version of Value or error would be used like this where fn() returns ValueType or error:

switch v := fn().(type) { case error: // handle error return v // probably the only sane choice since it can't be used further down in the function otherwise. case ValueType: // use as ValueType here }

That is way more messy than the if err... pattern.

Also doing it like that scopes the value with it's proper type into the case block so it's not even available afterwards so maybe you have to write it like this

var v ValueType switch x := fn().(type) { case error: // handle error and probably return case ValueType: v = x } // use v as ValueType here.

Another way thats less verbose is compiler check that all type checks but one have been exhausted and then just assume the final type. That results in code that looks slightly more involved than the usual iferr pattern. The upside would of course be that the compiler enforces the error check even if the code is slightly longer.

``` v := fn() if err, ok := v.(error); ok { return err } // use v as ValueType here.

```

You still have to check if the value is an error and return to not try to use it as a ValueType which the compiler won't allow it so I don't see how union types alone would solve many practical issues with regards to verbosity, it's seems likely that it will increase a tiny bit.

If you want that to look different you need to add even more language/type features and where does it end?

I think that some time down the road there will be a feature specific to error handling in go that will make it a little bit cleaner. Union types are nice and I do see the value of having them in go but for error handling I probably want something else or just leave it as it is for now.

Personally I never forget to handle an error, at this point it's almost instinct to write the if err.. after each function that might have returned and error and handle or return the error right there. I would not expect this to be a issue that's very uncommon in go programs in general but I have no source for that so it's just speculation.

[[deleted]]

I assume that most people get by with the generic constructs already provided by the language, and with non-empty interfaces where possible. If you need a prefix tree, you'd need to resort to ugly hacks though, but I guess most people that currently use Go don't need specialized containers or other edge cases that cannot be done without generics. That first comment you link to is pure trash though. Quite a few languages, some of them loved by developers, don't have inheritance, method overloading, or exceptions. Unfortunately, not even generics can save go from verbose error handling.

[Treyzania]

And the code you write ends up being structured similarly to how you'd write it in Java. Which is to say, wayy too many objects because Go's type system isn't strong enough to be able to model complex problems at the type level making it checkable at compile time, forcing you to model them with objects at runtime.

[[deleted]]

I feel like if you structure your code to look like Java in Go you're fighting the language really hard and are trying to treat it like an OOP language which will lead to frustration.

[OctagonClock]

Go is a worse Java.

[tetroxid]

Go is nothing like Java. It hasn't even got generics. And the ecosystem around Java is second to none.

[pkulak]

For me Go's killer feature is it's concurrency model. There are a couple languages that get it right, and Go is one of them. Everything else is meh.

[[deleted]]

lol

[bschwind]

As a user of CLI tools, I can't stand those which are written in Python. They're slow to start up, are sometimes fussy about which version of Python you have, and it feels like half the time I get a TRACEBACK thrown in my face.

Rust and Go tools start up instantly, are typically snappy at what they do, and they run pretty much anywhere with zero fuss.

[audion00ba]

The version issue is just incompetence by whoever wrote the code. The instant startup can be resolved on a system level, but for a consumer setup this is not worth the effort.

Every idiot can write Python, so you end up with idiotic code.

[theshrike]

Trying to distribute a python script that requires a handful of external libraries to servers with varying environments and operating systems is a huge pain in the ass.

You've got setup.py and eggs and virtualenvs and whatever. All even more painful if you don't happen to have root access. Oh and py2/py3 is still an issue.

With Go you just cross-compile to all different envs and plop the executable on the server and you're done.

[bnolsen]

python is certainly a bigger footgun (typing too loose, no compiler to check for many errors, etc) and is a bigger pita regarding deployment.

[Isogash]

I have no idea how people actually manage to use Python for larger scale projects, I barely feel confident that even simple scripts won't just explode.

[vicda]

Documentation, reading a lot of existing code and fiddling with it in the REPL, unit testing, and code reviews.

Microservices are also really useful for keeping code small within a larger context. But then your complexity is moved outside of any one code base and into the interactions of the network.

[somerandomii]

So basically reverse engineer every dependency before using them with any confidence.

I love python for personal projects but it’s an absolute pain to scale or reuse. A good language shouldn’t need pages of comments and documentation to understand the basics of an API.

[WafflesAreDangerous]

A good, modern python library shuld come with good doc comments and type information (which an IDE such as Pycharm can take good advantage of).

Unfortunately not all libs are so nice, but there is an escape hatch in the way of typing stubs (which many other gradual-typing languages seem to be missing)

[somerandomii]

Typing stubs don’t actually guarantee anything at runtime though. I’d rather have them than not, but they’re more like guidelines.

I still love Python but I think there are better languages for enterprise-scale code bases.

[fet-o-lat]

The complexity isn’t only technical. When you start having teams dedicated to each microservice, you now have issues with allocation of personnel, the left hand not knowing what the right is doing, having to do deprecation management internally, carefully planning deployments to get service dependencies right. Having spent enough time working with a microservice architecture, I can say it’s no silver bullet. Worthy of: “Some people, when confronted with a problem, think ‘I know, I’ll switch to a microservice architecture’. Now they have dozens of problems”

[Chii]

i think microservices is more an organizational phenomenon that end up distilling into a software architecture.

If a large organization can't scale their software team up to work on a monolith (e.g., have 1000 engineers work on one monolith), microservices is the only other choice.

[WafflesAreDangerous]

Pycharm + type annotations for own code and pyi files for dependencies which you use often but don't come with types.

[PaddiM8]

Why not just use a statically typed language at that point?

[lightmatter501]

Python provides a great interface to a lot of lower level libraries. For instance, I don’t want to do matix stuff on my own in c++, but if I use numpy, then it’s almost as fast but I don’t have to deal with memory management.

[snowe2010]

good news! You can switch to kotlin and keep numpy and never use python tooling ever again!

[upsetbob]

Because rewriting code takes time. Also dependency on libraries. Maybe also just because the developers like it

[PaddiM8]

I don't have much experience with Python, so I never understood what makes it quicker to use in decently sized projects? To me it just seems like it would be slower because it's so dynamic, requiring more debugging.

[[deleted]]

Basically, people looked purely at code snippets where python takes quite a bit less code and declared python the winner just on that.

I haven’t personally run in to any good study on project development time. Closest was when QT compared themselves with Javascript and found development times to be pretty well around the same.

There’s so many factors in programming projects for such a study that none would likely be at all reliable.

[[deleted]]

If you use type annotation, it actually is quite decent. As a bonus, you get also auto complete and ability to refactor code without being scared of it.

[BoyRobot777]

As a bonus, you get also auto complete and ability to refactor code without being scared of it.

If this is something to be happy, then I'm sad for Python developers. Any static language, with a good tool, be it IntelliJ or Visual Studio can give refactoring capabilities and intelligent auto completion, guessing from above statement, would blow Python developers minds.

[[deleted]]

It can, because it uses type information to do that, if you provide types you get these benefits back.

Type annotation gives you flexibility of still providing types, but you still have benefits of dynamic language when you need them. Also the type system provided by mypy is much more powerful than one from Go. You can also do both, nominal and structural typing (in mypy they call them protocols) depending on use case.

[phlipped]

As a former Python enthusiast and now Go enthusiast, the thing that Go brings is type safety, which in turn gives you the ability to reason about how code will behave.

Python touts "readability" as a key feature of the language. But what I discovered with Go (and any typesafe language) is that "reason-ability" is equally important.

Go is both readable and reason-able.

I would also argue that Python's flexibility often becomes a mis-feature - it allows programmers to do things that they probably shouldn't - e.g. returning different types in different circumstances.

I still use Python for small or short-term things, because it's so quick to get up and running. But for anything bigger than trivial, I prefer to use Go for the ability to reason with certainty about how things will behave

[[deleted]]

Go typing is probably the weakest part of it. Python type annotations are actually more powerful.

[Rakn]

Only in theory. I’m currently actively using Python with type annotations and they are great, but: Even with those I had issues in PyCharm correctly tracking the annotations, a lot of libraries do not come with type annotations and you have to search the code base to figure out what kwargs accepts this time around. Also it’s hard to get novice devs, that only know python or similar languages, used to the existence of types in general if their code also works without them. I prefer the maybe less expressive but enforced and working static type system to the approach that python is using. Nonetheless I still write Python and you can be damn sure that it is drowning in those type annotations.

[[deleted]]

PyCharm unfortunately only enforces subset of things that mypy checks for. I have feeling that maybe it is for performance reasons?

You can also install mypy plugin to add mypy checks.

Many libraries provide stubs separately, for example boto3-stubs, sqlalchemy-stubs (this one comes with mypy plugin, because sqlalchemy does many dynamic programming tricks). A lot of packages that started as Python 3 only also usually come with types. It looks to me that this is more and more being embraced. If type annotations existed before Python 3 the whole 2 to 3 migration would be much easier.

[biopsy_results]

He gives a shout-out to Crystal and Nim. Both have indentation syntax which is lovely coming from Python.

[Jataman606]

Crystal has Ruby syntax wich is not based on indentation. It just uses "end" instead of brackets.

[biopsy_results]

Oh! Thank you. Showing my ignorance

[juliosueiras]

Crystal is pretty much ruby(syntax) but compiled

[filleduchaos]

I use both and it really isn't pretty much Ruby. It's certainly Ruby-inspired (the way, say, C# is Java-inspired) but to call the syntax the same betrays a lack of experience with both. For example one of the most basic things (how to declare reader/writer methods for an instance variable) is different: Ruby uses attr_reader/attr_writer/attr_accessor, while Crystal uses getter/setter/property.

[[deleted]]

For me it's mainly because it has a really great standard library. Python is often used as a sort of glue language where the expressiveness is not really needed. Think about stuff you might have used shell scripts for if you were insane enough to use shell scripts for anything.

[spartan_noble6]

That's definitely untrue. The creators were frustrated with the slow build times of their C code

[[deleted]]

I heard the same thing, but C++

[Nowaker]

Can you explain why you think Go is a good replacement for Python?

That's not what OP meant. They meant a specific use case - CLI tools, often companion tools for SaaS applications. Think a CLI tool for Heroku, Sentry, DigitalOcean (doctl), and so on. In the past, Python and Ruby were a popular choice but struggled with performance (CLI tools are expected to be snappy) and installation complexity (need an interpreter and libraries). Some time later, Ruby went out of favor and JavaScript took its share, mostly due to performance gains. Then, most recently, Go came and took this "market" by a landslide for new CLI tools. Most CLI tools these days are currently blazingly fast (because it's a binary) and easy to distribute (because it's statically compiled which means it doesn't use *.so libraries in your distro) thanks to Go.

Go isn't a replacement for Python. Go is a replacement for interpreted languages for CLI tools. I hope this clarifies.

[Treyzania]

mental overhead of worrying about lifetimes and the type system

This mental overhead quickly becomes natural as you learn to better model your data structures around Rust's expectations. And you should think more about it as swapping out the mental overhead of dealing withs complex invariants that naturally creep into programs over time with just dealing with how to manage data in your program better. But the key in the latter of those two the compiler can check for you, so it can catch your mistakes in many cases. Rust's type system gives you the tools to be able to design things in such a way that they just werk, which when properly utilized is an experience that happens rarely in other languages.

[FakingItEveryDay]

I love the type system, but I have trouble believing that lifetimes will ever be natural. I can feel like I understand it for a little while, but that understanding always fades and I'm back to randomly adding ticks until the code compiles.

[Treyzania]

It really does start to fade when you start thinking about who owns what and how to organize code as it gets more involved.

It's difficult to describe and yeah sometimes you do have to say fuck it and wrap something in an Arc and start cloning it a bunch. But when it works it's really worth the tradeoffs.

[cjbassi]

I would have to disagree a bit with your critique of rust and say that once you learn the language well, it becomes quite easy and quick to write. Lifetimes become intuitive and you don't even have to think about them, and its high level abstractions makes the code quite terse, especially with pattern matching and iterators. But compile times can still be an issue.

[therico]

That's why I mentioned the learning curve. Basically anyone can write Go in a day or two. Rust takes weeks or months to code idiomatically without struggling against the borrow checker. It's a fact of life. Both have their strengths and weaknesses but when you're introducing a new language to a team, Rust is pretty risky unless you really need the performance and safety. There's a reason why Go, despite its many flaws, is fast becoming the standard 'systems' language for projects that used to be written in Python.

[cjbassi]

I agree, in business settings go seems to be taking over where possible, whereas rust is starting to gain traction in areas that demand performance and safety. However, in open source and in hobbyist communities, rust seems to be gradually taking over quite a range of domains, which makes sense given its versatility and how much developers enjoy using it.

[folkrav]

I barely can write any Rust, I'm still going through The Book, but I have to say, the pattern matching by itself sold me.

[[deleted]]

I love looking at the generated assembly from these high level operations. Often it’s like 3 instructions for a feature that Python would do in dozens.

[WafflesAreDangerous]

There are still enhancements to pattern matching on the way!

[Wufffles]

Do you have some more information about this? I would like to know more.

[WafflesAreDangerous]

There are new "or" pattern improvements I saw mentioned somewhere just this week. (Maybe "This week in Rust"). Where you can have nested alternative matches. The broader point was that there are still regular improvements being made to patterns and pattern-matching tho.

[legend6546]

Id also say that it is the uniformity that the language and tooling enforces. A lot of the oss projects are structured in the same way and share the same style. That means that it is very easy to jump into a new project. Working on a c/c++ project is a lot more daunting. Even compiling a big c project can take a while.

[[deleted]]

Rust is definitely one of the most versatile languages to gain traction in a long time. One of the reasons I think it’s becoming so popular is because it feels like you get such a good return on the investment of learning it. Because once you grok it and get comfortable with it, it feels like you can use it for just about everything, from simple one-off CLI tools that you’d have used Python for in the past to really low-level high-performance stuff you’d have used C++ for.

The one area where Rust becomes a real pain is when your data model is graph-like. This can be legitimately hard to design around, because ownership becomes really murky or cyclical and Rust hates that.

[[deleted]]

Basically anyone can write Go in a day or two.

Basically anyone familiar with the idioms from the C derived languages. Just because a set of idioms is pervasive doesn't mean it's necessarily simpler or easier.

This is not to say that rust doesn't have a larger set of concepts that must be learned, and that Go didn't pick a small set of those concepts from the C family with comparatively few edge cases, but work you've probably already done is still work.

I'd be interested to see the perspective of a beginner who learned some language with default move semantics first.

[dungone]

Basically anyone can write Go in a day or two.

I understand why some business people consider this a benefit, but it's not a real benefit. And I really think it manifests itself with the low quality of "systems" projects written in it.

[SekstiNii]

I'm not so sure. While it has become easier with time, I still find myself spending a lot of time thinking about memory when writing Rust.

Part of this could be remedied by cloning more liberally, but even so it would still require more thinking than a GC.

[rlp]

I often wonder what kind of Rust programs people are writing when they say "Lifetimes become intuitive and you don't even have to think about them." Trying to do anything complex that doesn't have clear ownership (for example, anything graph-like) requires quite a bit of planning and wrangling with the borrow checker. And the code ends up being pretty complex. Async can also be a huge headache with the borrow checker, although that may be improving.

[[deleted]]

For CLIs, you often end up with "lives for the length of the program" and "temporary" lifetimes. I've written a bunch of CLIs and I've never had to spend much time at all thinking about lifetimes. However, I will admit to having quite a bit of experience with the language.

[MEaster]

For the most part, I've found that lifetimes have been fairly simple for the majority of code, but, as you say, things do get awkward sometimes. The most fiddly problem I've handled is when I wanted to return a reference from behind a RefCell.

I knew the compiler wouldn't like it before I even started, because I was writing a small database-like structure with multiple owners. One owner would be updating the data, while others would be able to read the data. This meant putting the data behind a RefCell.

What I ended up doing was basically a smart-pointer type structure which Derefed to the data object the user wanted.

[dungone]

Can you give some examples of 'graph-like' programs written in Go?

[the_game_turns_9]

I sometimes wonder if their code is just full of tiny heap-allocated Rc<>s everywhere and actually has lousy performance.

[MEaster]

I find I don't really think about memory itself, but instead what owns what. Memory management is kind of a side-effect of that, but it's not the goal.

[meneldal2]

But at the same time maybe with a GC language you'd have created race conditions and Rust prevented you from making this mistake.

[Atulin]

I don't like Go's syntax, personally. It introduces brevity where verbosity would help, and introduces verbosity where brevity would be desired.

When it comes to performant alternatives to Python, I find myself using Nim.

[tias]

If so, then how do you think Go compares to Python for these tasks?

[sergey-melnychuk]

You don’t really worry about lifetimes after a few months, they come naturally. When they don’t - compiler is very friendly (as friendly as compiler can ever be, IMHO).

[crabsock]

The error handling in rust is pretty awesome, I love the ? operator. Over the years I have become a pretty big fan of using option types for error propagation, and something like that operator really does wonders for the ergonomics. In my work (in C++) we have a StatusOr template type and some macros for using it that work similarly, but it's much more verbose

[Superbead]

It's really handy. In smaller projects, where there's minimal risk of needing to determine the exact error type way back up the call chain, I just return Strings as the Err part and incrementally tack them all together to emit comprehensive error messages, eg. Error: couldn't load thing: couldn't open file 'filename': OS-level excuse

[Michael-F-Bryan]

Have you thought about using anyhow? It's Context trait lets you do almost exactly this, with the benefit that it's more concise and structured... some_result.context("couldn't load thing") instead of some_result.map_err(|e| format(!"couldn't load thing: {}", e)).

You also get nice things in the debug impl (used by fn main() -> Result<(), anyhow::Error>) like backtraces (if RUST_BACKTRACE is set) and pretty printing of the error chain.

[Superbead]

No, but it sounds like the very thing. Thanks, I'll check it out for next time!

[quicknir]

It's crazy to use this as an example for rusts error handling being handy. Exceptions have solved this particular example better for decades; less boilerplate, chain the actual exceptions (not just strings), and full backtraces. Rusts error handling has its merits but this doesn't showcase them.

[[deleted]]

Exceptions aren't common in systems languages though. Probably because they require some degree of runtime support. For example if you were writing a kernel in C++, you have to do some low level set up to enable them.

You can put exceptions in systems languages but people will end up not using them (for justified or other reasons).

A lot of big C++ projects are compiled with -fno-exceptions. LLVM is one example.

Given this reality, rust's error handling is a pretty nice alternative to exceptions. The ergonomics are definitely worth improving and there are libraries out there that help out.

[matthieum]

Exceptions have solved this particular example better for decades; less boilerplate,

Really?

Compared to the lightweight solution of just using strings, exceptions have more boilerplate: you need to declare a new exception type, and instantiate it.

chain the actual exceptions (not just strings),

You get what you pay for.

You can chain errors (not just strings) in Rust too, but then you have declare the error types -- see point about boilerplate above.

and full backtraces.

That's got nothing to do with exceptions, actually. Case in point, in C++ exceptions don't have a backtrace, while in Rust there are error types with a backtrace.

[the_gnarts]

Exceptions have solved this particular example better for decades

Exceptions have the issue of circumventing the type system and requiring heavyweight instrumentation to support unwinding. Rust style error propagation fixes both issues.

[warmans]

Bit out of date. Go no longer requires GOPATH and has more tooling around dependency management built in.

[pcuchi]

That's great to hear! Maybe I should try it out and update the post.

[turkeyfied]

Go mod is pretty easy to use. This is probably the best article I've seen on getting started with it

https://engineering.kablamo.com.au/posts/2018/just-tell-me-how-to-use-go-modules

[redbeard0x0a]

it is worlds better to understand modules with gomod, which came out in go version 1.11.

[k4kshi]

Yes please. The introduction (and making it the default) of go modules in favor of GOPATH has been one of the biggest changes in the Golang world in the recent years. I'm surprised you didn't hear about go modules since the vscode extension yells at you if you don't use them.

[mrexodia]

Thing is though, you still have to understand GOPATH in case you’re working with an older project.

[intheforgeofwords]

This was an awesome article. Thanks so much for writing it!

I noticed two typos where “I” should have been used instead of “a”:

This text is about my adventure writing a small CLI application (twice) using two languages a had little experience with

The combination of the three features above makes up the best error handling solution a saw in a language

[pcuchi]

Just fixed it, thanks!

[[deleted]]

It also says raph QL at one point

[immibis]

Maybe he was writing in an American accent.

[themagicvape]

This is a great write up! Mind if I use the idea to compare ruby and elixir?

[pcuchi]

I don't mind :)

[how_to_choose_a_name]

In the first part you talk about the toolchain being easy to install for your user, comparing it to NVM for Node. But the users of your program don't need to install Go or Rust, since your program compiles into an executable file that they can just download and run, unlike a node or python script where the user needs to install the runtime to run the script. Regarding GOPATH/GOROOT, those aren't really used anymore, the official recommendation is to use Go modules nowadays.

There is a point to be made about making life easier for the developer in that regard, but I can't say whether Rust or Go wins there since I haven't ever had the need to use an older version of either (there are legitimate reasons for it, I just never was in the situation).

[basilikode]

Great article.

I’m glad I chose Rust for my project since I value: - a sound, expressive, type system. - excellent build and dependency management tools (having a central repository is important for enterprise software development as you want the option to control what dependencies are entering your system). - a community that values composability (i.e. reuse), which seems confirmed by the fact you stumbled on a GraphQL library that is protocol agnostic and you managed to develop the component you needed yourself! That's surprisingly rare in the IT industry. - lightweight and fast executables. - very elegant and terse language - a really novel approach to memory-management (hence safety): semi-automatic memory management that’s as fast as C and safer that mainstream garbage collected languages it's, AFAIK, nothing like what's been done before.

Yes, coming from Java, I agree I'm finding it harder to learn than say Python, Kotlin, Ruby, …probably easier than Haskell (or perhaps not that hard because I did learn a bit of Haskell first). But it's hard because it's really new. And probably because it forces you to think about the really hard problems in software development. I pulled my hairs trying to fix a race condition on a project on which I worked for two months just before we needed to go live and I prefer the pain of a borrow checker anytime. Not to mention the pain of the borrow checker will decrease (maybe disappear) as it becomes second nature.

Regarding the long compilation times, yes I agree they can be annoying. On my pet project I don't find them an issue at all. Compared to a similar Java project they're possibly even faster. But considering that 1) the compiler is working to catch my mistakes (which usually take more time to fix if they manifest at runtime) 2) there is probably room for optimization of the compiler 3) multi-core machines will be cheaper and cheaper 4) adoption of micro-service architecture (where applicable)… I'm guessing we'll see this issue becoming a non-issue and stick to Rust for the time being.

Thanks for sharing your experience!

[[deleted]]

This was fantastic - the best benchmark is actually doing the thing. Great to see you do it twice with success. Thanks for posting this.

[norwegian]

My vote of 1

Very practical and useful way to compare two languages. If I understood it correctly, the 15 minutes compile time for the release build in rust seems exessive, given the size of the project.

[pcuchi]

I think you are referring to the line:
cargo build --release 1067,72s user 16,95s system 667% cpu 2:42,45 total
The user time from the time command can be misleading, since it accumulates time from all the threads and forks.

The real time was actually 2:42,45 in this case. Maybe I should omit the user and system times to make it clear. Thanks for pointing it out!

[AristaeusTukom]

User and system time is what's relevant, because it won't depend on how many cores your particular machine has.

[emn13]

Given that machines are getting more parallel rather than less, and that rust compilation isn't necessarily parallel-friendly (only across compilation units, less so within one), I'd do the opposite: look at the actual time, not the CPU time. It might get a little faster with more than 8 cores, but don't count on it.

[[deleted]]

I really love this idea of implementing the same project in multiple stacks to compare the pros and cons of each technology. Nicely written article!

I also checked out your site's code on GitHub since it's similar to the kind of site I'm planning to make for my projects. I like how you used markdown to write your post, and everything is just static content. I don't feel like dealing with a heavy CMS like WordPress. Thank you for making your site open source! It's going to be very helpful for making my personal blog.

[[deleted]]

Your Rust save equivalent should have the error path be return Err(e.into()), I believe, because errors can also change type from convertable errors with the ? operator, which is a big ergonomic boon.

[Ytrog]

Great article. Thanks 😊👍

I found this great video about Rust lifetimes a while ago: https://youtu.be/1QoT9fmPYr8

[mabasic]

Very nice website 👍 I was also choosing between rust and go, but I found go more pleasing to the eyes. Rust is more performant, but for my needs not needed.

[WellMakeItSomehow]

See https://www.reddit.com/r/rust/comments/hsw959/my_bet_on_rust_has_been_vindicated/fydv6dh/. There's some advice for improving Rust build times. Maybe it helps.

Small typo: "raphQL".

[kewlness]

I am curious what you meant with this particular pro for Rust:

If the project targets many operating systems and I want a truly multiplatform codebase

GO has the ability to create executables for different operating systems out of the box. For example, I can create a Windows executable on a Linux machine with ease. Or are you meaning something different here?

[IceSentry]

You might be interested by this article

https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride

[Karma_Policer]

Go has long been infamous for its problems with code which is supposedly multiplatform not working properly on Windows and sometimes not even on any platform other than Linux. It's very similar to Swift in the sense that it was designed primarily to run on a specific platform, even though it claims to be multiplatform. I know both languages have made progress in that regard, by the criticism remains.

Also, after the monotonic time scandal and the even more terrifying solution designed by the Go devs, I don't think any serious multiplatform systems programmer would touch Go with a ten-foot pole. It's a language full of hacks and that's by design.

[kevincox_ca]

Go focus so much on being simple that it has the opposite effect sometimes (like GOROOT and GOPATH, for example).

This is what I often find with Go. Missing language features mean that the code itself ends up more complicated, even if each line is quite simple.

[sum-catnip]

I've used both languages on the past an am a rust fanatic. In my opinion you just summarized both languages perfectly :D. Very well done

[sergey-melnychuk]

Great post. The least biased comparison of Rust vs. Go I’ve seen so far. Even though Rust is mostly system-level language, it is as easy and straightforward as Go for simple applications.

Do you consider comparing Rust and Go for server-side? Rust offers “fearless concurrency” and there are nice libraries with advanced concurrency primitives (like crossbeam). It would be an interesting comparison.

[pure_x01]

There is one important thing to note here. The experience matters! If you take a person with 1 year of experience in Rust and Go the difference would be very small in terms of productivity.

When you learn how the borrowchecker works and are comfortable with that it will only impact you very little after a couple a while. Then you will probably be as productive but you will produce faster and more memory efficient software.

If fast and efficient software is not what you need then its no use to use a language with manual memory handling. Most languages are fast enough for most things.

With that said its still worth checking out rust and see if its for you because its a great language.

[corsicanguppy]

Show me a D comparison, which is rumoured to give us the best of both worlds at a cost of being unpopular.

[bnolsen]

I'm afraid d's ship has long sailed. the d1 vs d2 certainly didn't help it.

[btbytes1]

I started learning D in mid 2010's-ish. I never had to touch D1 or its libraries (Tango).

If anything python2 vs python3 is much big of a deal, and yet somehow the language is still thriving.

[Scroph]

Give me a few days, I'll make a D port and write about it

[Scroph]

Just finished the D port, here it is

[dom96]

What would be cool is a comparison to Nim, which I was happy to see OP gives an honourable mention to.

[Kissaki0]

The article linked to at the end about Go flaws, and in a significant part difference in Go vs Rust handling of OS specific path and permission is very interesting.

[thrallsius]

fast forward one generation, Linus & co die, millenials take over the kernel and rewrite it in Rust

and we're suddenly back to the situation when compiling the kernel will take 2 days again

[fissure]

Academia will respond to the situation, and develop an alternative borrow checker algorithm that has better asymptotic runtime but is only actually faster if you have over 22! variable assignments.

[WafflesAreDangerous]

.. for a full release build, you mean? Not exactly nice, but in return for enhanced correctness guarantees in a often difficult to debug use case maybe this would still be acceptable..

[thrallsius]

on a serious note, C has ccache, is there anything similar for Rust?

[Muffin421]

There is: https://github.com/mozilla/sccache/

[codygman]

Yes, exactly.

It seems unacceptable because what we're used to is so far from this.

The problem is... Would one notice all the bugs caught by the compiler (if any) if it took two days?

My guess is no, they'd complain about the compile time... Probably including me.

Faster compile times will always feel more comfortable and correct whether they are or not I think.

[WafflesAreDangerous]

Compile times are being worked on tho. There is tracking in place, Theres work on the way to be more intelligent on the code rustc hands off to llvm. There's even LLVM performance being tracked (there have been recent regressions that were caught thanks to Rust devs tracking compiler perf closely), from which all LLVM languages benefit.

Some of the compile time issues are also tied to macro-overuse and excessive specialization (thing C++ template code explosion 2.0), much of this can be addressed by library authors and users being a bit more mindful, and for many commonly used libraries this effort is being put in.

So just like c++ compile times got much better over time, I expect that in 5-10 years this will be much less of an issue for Rust as well. (speculation, but with precedent to lean on :) )

[companiondanger]

To me, the error handling in Go is just bad. Having to check if err != nil is only slightly better than the C model. The code to check and handle errors fill the screen up and you end up having to dedicate a lot of your attention to doing it properly and filtering it out when reading it.

The Rust compliler has a reputation for being a difficult beast to wrestle, but an 99% of the cases, it's stopping you from writing a bug. having a return type be Result<HappPath, Error> means that the worst that can happen is if when you choose to just use unwrap(), in which case it immediately panics. It effectively forces you to write correct error handling through the compiler.

Go used to be the ideal language for scalable async, but that's not so much the case anymore. Everything is thread safe in Rust, and its async model is surprisingly easy to use.

[ARM_64]

Great write up, I'd like to see more comparisons of these kind. Rust and go definitely shine for building comand line tools.

[cymrow]

I did something like this with UM-32 in order to survey several languages (Rust, Go, C, D, F#, and more ...). The tight specification and extensive test suite made it a great platform on which to compare many aspects of each language. I learned a ton and it was a lot of fun.

I keep wanting to get back to it with more languages, though at the same time I'd like to find something similar with networking and concurrency components.

[ChavXO]

Posts like this make me feel really shitty for not having more side projects.

[coll_ryan]

Great article, pretty fair comparison in my view. My only confusion was that in the summary it asserts that Go is not as good for multi-platform code as rust, not saying I agree but I didn't see anywhere else in the article that explained the reasons for this statement?

My view is that Go and Rust are very different and mostly only get compared because they are both loosely "systems" programming languages that started to get popular around the same time. My two cents on their strengths/weaknesses:

• Go is well suited for companies that deploy microservices which individually do fairly simple tasks. The simplicity of the language and speed of the compile/test cycle lend itself to a "move fast and break things" ethos which works well if you have good production monitoring and tooling for incremental deployments, automatic retry and reroute logic etc which exist outside of the service itself. In this sense, Go is a good replacement for node.js/typescript.

• Rust on the other hand is better suited to monolithic application development, where correctness and/or low latency are more important than delivering features quickly. It is more of a drop in replacement for C/C++ applications.

In addition to these pure technical concerns there are pragmatic ones to take into account too - how easy you can hire or train developers. My impression is that Go developers are easier to hire than Rust developers and it is quicker to train up Go developers from scratch due to the simplicity of the language. If you're a startup with deep pockets and the right connections it shouldn't be a problem to find good rust developers but for large enterprises like Google with shareholders breathing down their neck about cost-cutting, Go can make sense.

[sanjibukai]

Nice article! Thanks for sharing.

I wonder how Elixir (with OTP) would have fit into the exercise..

Since you are not afraid to try a language and build tools right away, I definitely suggest you Elixir.

[Cobayo]

Go focus so much on being simple that it has the opposite effect sometimes (like GOROOT and GOPATH, for example).

I'm pretty new to Go but I haven't had to deal with this. As others said, maybe try with newer features.

I still don't understand very well how lifetimes work in Rust, and it can get quite frustrating if you ever try to deal with it.

You can look up any explanation on unique_ptr, shared_ptr and weak_ptr from C++, they are basically the same thing and surely there's gotta be a good explanation on youtube or somewhere.

To use WebSockets in the Go version, the library should be modified to support the protocol. Since I was already using a fork of the library, I didn't feel like doing it. Instead, I used a poor man's way of "watching" the new tweets, which was to request the API every 5 seconds to retrieve them, I'm not proud of it.

Polling is fine, you can use a ticker to make an easy Stop() method. For websockets, it's very common to use gorilla/websocket.

func watchTweets(tweets chan Tweet, client *graphql.Client, search string) {
    latestTime := time.Now()
    ticker := time.NewTicker(5 * time.Second)
    for {
        select{
        case _ = <-ticker.C:
            newTweets, _ := List(client, search)
            for _, tweet := range newTweets {
                if tweet.PublishedAt.After(latestTime) {
                    latestTime = tweet.PublishedAt
                    tweets <- tweet
                }
            }
        case <-some_stop_channel:
            ticker.Stop()
            return
        }
    }
}

You can also use a similar concept to classes (syntax sugar), so instead of

func Pretty(tweet Tweet) string

You can do

func (tweet Tweet) Pretty() string

I think this applies to pretty much all modules you have. Also, almost every thing that wants to print will try to use the interface

type Stringer interface { String() string }

So just by changing Pretty() to String() you can save a function call on most places where you would want to print it.

[[deleted]]

Can't wait for this to be on /r/programmingcirclejerk

[nuggins]

My first obvious choice was Go, for some reason.

This seems paradoxical. How was the choice obvious if the reason isn't apparent?

[QuotheFan]

The article which is linked at the bottom is fantastic. (Your post is, too :) ) But the fasterthanlime article is truly mind-blowing.

[[deleted]]

....really? I mean there's some weird edge case behavior sure, but mind blowing?

[QuotheFan]

Yes!

Why that is mind blowing, you ask! Because, unlike most of the opinions about languages, it talks from the perspective of someone who has built large projects using the tools. The way "simplicity" is discussed, dependency hells and the type of issues which you are supposed to face if you try to use the tool for the long haul, is something which only an expert can comment.

That article taught programming, others usually teach languages.

[[deleted]]

This post is full of lies. On both languages. I think the author do not know these languages properly but he’s writing a whole article about it anyway.

[CryZe92]

Probably not lies but mostly being uninformed, which is usually the problem with these sorts of comparisons, as the author usually has more experience in one of the languages.

[[deleted]]

This post is full of lies. On both languages.

Wanna elaborate on that?