Go Is the New Ruby | Hacker News Reader

Go Is the New Ruby

00f.net

105 pointsjedisct159 comments

Go really is the easiest language I've used. It installs with no fuss. The VSCode extension sets everything up and works perfectly. The library documentation is so clear that it usually answers any question I have without having to dig up blog posts and without dodging top search result Stack Overflow pages closed without answering the question. The highly opinionated nature means I can go into any Go code base and make sense of it quickly.

Go is the new Java.

It runs everywhere, is easy to learn and use and people who don't get it hate it with passion.

Anyway, comparing go documentation with rust docs, I'm surprised anyone can get any work done with rust.

I'd say Go is more like Basic.

I’m a devout Go developer and I feel like this is accurate. It’s got some uglies (eg no generics, verbosity in general), but man, overall, it’s so pleasant to work with. Which is probably how great Java developers feel. Thanks for inspiring empathy!!!

And Java also didn't start with generics either. They were bolted on later.

Which is why it uses type erasure for generics rather than reification like C#.

C# didn't either, it was introduced in C#/.NET 2.0. As I've understood it, Java chose type erasure to stay backwards compatible with older JDK versions, whereas .NET instead chose to break compatibility with 1.x and force dependents to target 2.0.

> Anyway, comparing go documentation with rust docs, I'm surprised anyone can get any work done with rust.

That's an unexpected comment. Rust has among the best documentation I've seen, and arguably the best ecosystem around documentation, which helps a lot and encourage third party developers to write high quality doc. I understand when people complain about the learning curve (like this article, because fighting the borrowchecker is only a thing while learning) but docs, really?

For comparison:

https://doc.rust-lang.org/std/fmt/index.html

https://golang.org/pkg/fmt/

I don't know why I find Go's version easier to follow, but I do.

In terms of content, they seem to be on par, and I think it's safe to say that's true for both stdlibs.

Across the ecosystem (and particularly the third-party culture of documentation) is much more important; in my own experience playing with both languages, I tended to encounter more useless 1-line descriptions in golang than I did in Rust.

Also golang struct descriptions always seem to be a bit lackluster..

But I can't point to any particular lib at the moment though.

Context: I wrote most of the stdlib docs

the fmt docs are... not ideal. That said, there's a lot there, and it's all useful, but it's just tough. Frankly, I just punted on improving them, and haven't taken the time to do so in the years since.

It seems like enough people find their way around them. Refinement might make them easier for people like me with less experience navigating language documentation, but that might come at the expense of developing the language. Priorities are important. Especially since Rust doesn't have Google's resources.

Even if it's not the author's favorite piece of doc, this is still a pretty good example of why I like rust docs. The rust version has :

- syntax highlighting

- a quick example of the feature

I am not a fan of Rust’s documentation. To take one example: sending a HTTP request. There is tons of documentation of properties of the the HTTP classes built into the standard library, but it is extremely hard to find an example of working code. Wouldn’t a simple usage example of something like sending a single HTTP request be one of the most useful things to document?

As far as I can tell, the best-documented approach is to use some external library and ignore the http support built into Rust.

Rust’s standard library has no http support, so this post is a bit confusing to me.

This stuff, for example:

https://docs.rs/http/0.1.19/http/request/index.html

"standard library" is probably not the correct term for this in Rust-world because it is under the "http" namespace rather than the "std" namespace. I just meant, "the stuff you use via typing `use http`".

Yes, that is not the standard library, that’s a third party package. Its documentation does explain that it’s not a client or server.

Hmm. Its documentation doesn't explain that very well at all, to me.

I am comparing the experiences of:

1/ Trying to do some http requests in go, searching for "golang http", and coming across the fairly well documented standard "net/http" library in go, at https://golang.org/pkg/net/http/

2/ Trying to do some http requests in rust, searching for "rust http", and coming across this as the first result:

https://docs.rs/http/0.1.19/http/

which includes statements like

"It's intended that this crate is the "standard library" for HTTP clients and servers without dictating any particular implementation."

That's cool, I don't mind if no particular implementation is dictated to me. I just want to know how to use it by reading this documentation... but that never becomes possible.

You could say the problem isn't that rust is documented poorly, the problem is that the standard library is missing some things that are in the standard library of other languages, and it's those third-party libraries that are documented poorly.

The big issue here, is that you assume that you can get the same ultra-light Google search to give you the same answer for Go and Rust. That's a totally unrealistic expectations! If you google “nodejs http”, “PHP http”, “python http” or “Java http” you don't have the answer you're looking for either!

“How to perform an http request in Rust” is a Google query that makes much more sense, and works for all the aforementioned languages.

I disagree.

Searching for [python http] works fine. Top result is this page:

https://docs.python.org/3/library/http.client.html

which explains precisely how to send http requests.

Searching for [nodejs http] works fine as well. You get this page:

https://nodejs.org/api/http.html

Which does, in fact, give you a library that can make http requests.

I won't dig into php and java because I'm not familiar enough with those languages to say what a decent way of sending http requests is.

Finally, searching for [how to perform an http request in rust] does not work! It sends you to https://docs.rs/http/0.1.5/http/request/index.html which is the same fundamentally broken library as you get with [rust http].

In conclusion, the Rust documentation is worse than any of Go, Python, or Node.

The second link for "rust http" for me (and in incognito mode) points to https://github.com/hyperium/hyper, which is exactly what you want.

Agreed, the Rust docs seriously suck, but once you get used to the language you can write incredibly fast code witgh only about 15% more effort than Python. Also, Cargo.toml is great.

I don't really get the affinity of Go and Ruby. The most similar thing I could say about them both is that they're both not Java. This makes sense from a hiring sense, either your hiring from the large Jvm/.Net pools or you're not.

I suppose both Ruby and Go have less steep learning curves compared to Java/Kotlin/Scala.

I can't wait until Go v2 gets generics then I can use it like other statically-typed compiled, gc'd languages. At the rate of Go language development, Java might get coroutines and value-types before then.

I haven't used Rust but I read the "Rust where the compiler constantly shouts “fuck you”" quote differently. I read it as, where the non-existent Ruby compiler will shout “fuck you” in production.

The affinity for the author is in the last line,

"Go has become the new Ruby. A language I use to get things done, and enjoy programming again."

Good for him

It does seem a weird comparison.

It would be hard to find two more different major languages.

Go is underpowered, explicit, and statically typed; Ruby overpowered, implicit, and dynamically typed.

But I think they're alike because the author likes both of them.

Yeah, new Rust programmers always fight the borrow checker. Once you get used to it though, Rust's compiler is literally orgasmic. It has a build in spell checker for christ sake.

“All languages suck, but they all bring interesting concepts as well, that can overall make you a better programmer.”

True on so many levels. Learning other languages means learning a new way of thinking due to the reasons those languages were created in the first place. Even if you never change the language you use daily, learning other languages and doing small projects in them will make you better in your “home” language.

Not true, There are lots of languages that bring absolutely nothing to the table in terms of making you a better programmer. Take something like Elm, it doesn't make you a "better programmer". It does make your program better by being statically typed. Kinda like typescript doesn't make you a better programmer than if you use javascript, but it makes your program better. You can say this for a lot of languages.

I don’t agree with this. Using typescript really helped me understand the value of types, which wound up radically changing the way I read and write vanilla JS. I’m much better at recognizing and preventing bugs in vanilla JS because typescript has changed the way I think about JS.

Uhm, Elm is a really bad example to pick, given how many other languages now have libraries that implement "the Elm architecture" for UIs of various sorts, while Elm itself is almost entirely a "please spit out some HTML" toolkit.

I enjoy learning new languages. In my day job I spend most of my time writing JS (ReactJS specifically) building dashboards and other internal business tools. Sometimes I need to build API's or perform tasks that just cannot be done in the browser and I take the opportunity to experiment with other languages.

A few examples:

- We purchased a cheap USB duplicator (10 slots) to copy the contents from a master USB to the clones. It worked, but wasn't a great solution. It was slow, error prone and when it failed you never really knew what USB was having the issues (or what went wrong). Using a Golang backend and ReactJS frontend I created an alternative which had a nice GUI showing what files were copying, the percentages complete, error messages, etc. It was a far better solution and using Goroutines it was fun. We ended up scaling the system to 100 USB's at a time and that was fun to watch (lots of blinky lights :D). The solution didn't take much time to write (Golang was quick to learn) and we finished the duplication WAY sooner than the due date.

- We needed to automate a bunch of DNS stuff with CloudFlare. I ended up creating a parser for a custom config we wrote, hooked it up to CF's API and we ran it as a service. The language I used for this project was Nim[0]. I liked the syntax and the final binaries were TINY and FAST.

- More recently I was approached by an IT guy at the company that manages all of our software licenses. He showed me this command line tool he uses to query all licenses and goes through the cryptic output trying to figure out what licenses were being used, by whom, etc. I ended up using Go to parse the command and serve a ReactJS application with all sorts of bells and whistles (reports, history, alerts, etc). Since the application is browser-based he can even use it mobile which he loves.

- I've been working on some prototype BLE Mesh stuff in C, but that is a ways out and not yet worth mentioning much more.

Rust has held my interest for a while as well, just waiting for the right project to come along.

[0]https://nim-lang.org/

On top of ReactJS, what else do you use to build dashboards and internal business tools?

React SemanticUI is great.

I typically do everything custom these days. In the past I would use Bootstrap, Semantic or one of the many other CSS frameworks but I found that I add a lot of size to my applications when I only used a few things from it. Most features (sidebars, grids, menus...) are simple enough to just implement on your own. I was a graphic designer that moved into development so I feel I have a pretty good sense of design and UX.

I do however use various charting libraries out there for ReactJS as they are typically quite well done and small in size. If I need something a little more custom I'll install D3 and build it out.

For backend I have used Node/Express quite a bit to serve API's and such. But as mentioned in my previous post lately I've been using system programming languages a lot more for building backend things mostly as a learning exercise and because I have the freedom to do that in my job.

Building out these tools and seeing them being used daily from nearly all employees in a ~400 person company is really rewarding. It really gives me a sense of appreciation for the work I do and I get a lot of good suggestions on how to improve the applications that in turn improve the work these employees do.

Other things I've used in the past for various projects include Ionic Framework & PhoneGap (mobile app), Zephyr RTOS (BLE Mesh Programming), React Native, Angular, Electron (Visitor Check In/Out Kiosks), and lots of CSS frameworks (too many to name).

Your DNS-project sounds exactly like mine! I parse a custom format of text-files, and update AWS DNS records via git-pushes:

https://dns-api.com/

Very cool! Our tool only recognized A/AAAA, CNAME, and TEXT records (that's all we needed at the time). Your solution is much more complete and looks really good. Clever use of git! Your pricing is super affordable as well, nicely done.

The key point of the article is that Ruby and Go are similar for being very developer friendly and productive languages. It is not about keyword arguments or the expressive power of the language or something similar. Although it's not explicitly mentioned why Go is the new Ruby, given that both are equally productive, I would assume that it's because Go is much faster where it counts.

I kinda throught Elixir / Phoenix was the new Ruby / Rails. Nice read none the less.

Indeed. For scripting languages, it's usually Python people moving to go and Ruby people adopting Elixir.

More like Javascript is the new Ruby and Go is the new Java.

Moving to a new job with Perl and Go. I know neither of them. This article has me excited!

> But, just like in Java, if I need speed, I can preallocate and reuse memory to avoid hitting the GC.

No, you can't. Language constructs in Go allocate in ways that are not immediately obvious. When the GC runs, it still has to scan all of that memory, regardless of whether you preallocated it or not, which is especially unfortunate with a non-generational garbage collector like that of Go.

Also, I have to say that I really don't get it when people say that they have to think about the borrow checker for a long time before writing a program in Rust. That's not the case for me or anyone else I know.

One possibly useful thing to know is that the Go GC doesn't scan non-pointer memory, so if you have big strings, byte arrays, or structs that don't contain pointers, they don't need to be scanned.

Also, while the garbage collector may not be generational, it's mostly concurrent. Looks like GC pauses are below 1ms now?

> For me, Go has become the new Ruby. A language I use to get things done, and enjoy programming again.

Despite my annoyance with the direction that Go's taken since 1.10, this line really resonates with me.

TL;DR

Windows + PHP + slow laptop drove me to put away my childish anti-Google fears for a weekend and try Go, and for the first time since I started coding (with Pascal) I enjoyed programming.

Cool story:

Around late 2010, after a few years of using (btw, Arch) Linux exclusively, I was given a slow Windows laptop for work. The laptop came with Windows Vista IIRC and the whole experience of writing PHP code on an unfamiliar OS combined with a slow laptop was just misery - it was even worse than my memories of Windows ME/XP.

I tried everything to get a familiar Linux env going: Cygwin, msys, KDE... and it just added insult to injury.

Anyway, soon after, it was Go's birthday so it was in the news again and one weekend I decided to put away my childish anti-Google fears and try it and I never looked back.

Something about the simplicity, its lack of CMake, Makefiles, latest build-system-of-the-week, dynamic linking hell, C++ complexity, D and its 2 std libs, etc. was a breath of fresh air.

Before even falling in love the the concurrency primitives, I started writing "bash scripts" in Go - something I do to this day. I even started writing prototypes in Go to then port them to PHP and Python because I could write the inefficient, naive, brute-force code to validate an idea... and it'd still end up being faster and use less memory than the code the was deployed to production.

I later also discovered that my shitty naive linters written in Go that parsed and checked whole PHP packages every time I saved a file ran near instantly compared to the heavy disk-destroying IDE indexing - it was crazy.

I thought Crystal was...

https://crystal-lang.org/

as for rails, pick your poison

https://luckyframework.org/ https://amberframework.org/ https://spider-gazelle.net/

I tried Lucky, Amber, then finally Kemal which is more of a Sinatra. It was the only thing that compiled fast enough to feel productive.

A statically typed compiled systems language with anachronistic C semantics and a regressive package dependencies system is never going to be a new high level DSL oriented scripting language. A far better take is that Crystal is the new Go, because it mixes the benefits of a high level language with the benefits of a lower level language, and learned a lot more of the lessons from the ruby and node ecosystems about how to manage code dependencies.

I mean this to come of in a non antagonistic way, but did you read the article? You seem to be refuting the title of the article without addressing any of the points made within it.

Then what is the new Rails?

the standard library if you ask most Go developers it seems. It's an old joke that whenever you ask for something like Rails in Go many / most of the devs will tell you to use the standard library. The sad thing is, they actually do that again and again.

That being said, someone said "screw that" and built Buffalo https://gobuffalo.io/en which is as close as you can get in Golang at the moment.

Someone should create a Rails-like framework named Go to Gaol.

You can't have Rails in Go.

I mean you can, but "go advocates", would crap on your work with an endless litany of articles about why whatever you wrote shouldn't be used because it's not the "go way". Remember Martini? That's right you don't.

Fortunately for Go, the biggest pain in the ass when it comes to web development is kind of a solved problem with the use of JSON support in SQL Dbs. All you have to do then is un-serialize directly from the DB, which helps getting rid of ORM when building object graphs.

I have no idea where all this salt comes from about go advocates, but there are plenty of Rails-likes in Go that are accepted and used by the community. Buffalo is probably the most Rails-ish (from a glance, I've not use Rails extensively), and it's maintained/advocated for by folks who have long been pillars of the community. Martini was effectively replaced by Gin (https://github.com/gin-gonic/gin), which is still heavily used.

Martini wasn't replaced by Gin, 2 different developers.

Buffalo uses code generation sure, but it doesn't make an extensive use of interface {} like Martini did, thus can't really be compared to Rails in terms of polymorphism.

I wonder what the authors thoughts is about not having a secret annotation for wiping secrets.

Why would you say something so controversial yet so brave?

I don't understand the comparison with Ruby. Go, as a language, is underpowered by design. Ruby is "overpowered". Ruby should better be compared with Kotlin and Swift.

In more ways than one.

Go is not the new Ruby.

Ruby has keyword arguments and optional arguments with defaults.

Among [many] other things.

Reply on news.ycombinator.com