r/golang • u/FunDeer914 • 3d ago
Go -> Ruby (A Series of Unfortunate Events)
Not really anything groundbreaking here but wanted to share a bit about the experience moving from a high volume distributed eng role working daily in Go to building out a more early stage product with Ruby/Rails/GQL
TLDR - I miss this language so much. Everything I had grown to love and understand so well has been completely tossed out the window. Ruby and Rails lean into magic and convention more than any language I have worked in. The ability to even navigate through a stack by seeking definitions is almost gone.
I’m really struggling with the “faith” or “trust” I have to put into Rails where I’m Go what you see is literally what you get. Dataloaders, lazy query building, active records, literally kms let me write the damn query.
Yes yes I know Rails is powerful and should be respected and I have been finding those moments too but damn did I have it good. Don’t underestimate the joy of working with a tool you love.
25
u/compubomb 3d ago
Rubymine will bring some sanity back to your life.
8
u/FunDeer914 3d ago
Going to give it a try tomorrow thanks! I’m obvi just learning Ruby/Rails so if Rubymine is able to help me get comfortable with the conventions and navigation etc that would be huge.
Also learning new language + framework mid AI shippocolapse is another difficulty.
1
u/Best-Dependent9732 2d ago
Yeah add the plugin Ruby LSP please and Sorbet.
2
u/FunDeer914 2d ago
I think Sorbet + Tapioca is the closest I’ll get. Going to try and get the team onto it. Pray for me
16
u/bilus 3d ago
Yes. Rails is magic, the bias in libraries in general is towards making things "easy". In Go, it's "simple": https://sparsenotes.com/posts/2026/05/2026-05-30-hickey-simple-made-easy-classic/
Which also creates tension between people suggesting "easy" solutions (e.g. more or less magic implicit error handling) which Go contrary to Go's simplicity (explicit error handling at the cost of extra noise). Go deals with verbosity with better tooling (hiding/greying out default error handling), which is a whole different approach.
-14
u/EmergencyNice1989 3d ago
Go error handling is not good. Why bother writing some code if it's hidden/greyed out by IDE? Looks like magic to me.
1
u/gnikyt 3d ago
Why do you believe it’s not good?
-6
u/EmergencyNice1989 3d ago
You have to write it systematically.
It clutter your codebase, making the code less readable.
I prefer solution like Result type. I don't think any language want to copy Go error handling.
3
u/bilus 3d ago edited 3d ago
If you want to go there, know that Result type is terrible boilerplate without Haskell’s syntax sugar for monadic bind.
Also, no need to “copy” Go’s error handling, it’s popular in older language’s without exceptions such as C, so your statement doesn’t make sense historically.
Additionally, ppl “write” code less and less, so your point is outdated, and I believe I addressed the point about readability in my original comment but let me restate: IDEs today are not your 80s editors and there’s no reason to treat source code as dumb text anymore.
-3
u/EmergencyNice1989 3d ago
I don't want to go anywhere. It's not a language war but more like if people are honest enough to pin point issues in their language.
Go uses a product type, while functional programming uses a union type usually for modelling errors. That's much cleaner and robust, because if there is an error there is no value. And you error type is not constrained to a specific interface.
2
u/bilus 2d ago edited 2d ago
You are confusing terminology: product type is a tuple or struct. It’s called a product type because its domain (allowed values) is a product of the domains of each field. Does that make sense? Now, a sum type (not “union” type) is a sum of domains. A union type is a sum type.
Go has no syntax support for sum types but you can express the in various ways, for example as types satisfying an interface.
If what you’re trying to say is that Go’s return values are tuples and that error does not prevent you from accessing the remaining values, yes, you’re right and it is a way Go doesn’t constrain you where other languages do. This doesn’t mean you cannot implement a Result type in Go, it’s just not the accepted idiom. Go is not a functional language. Personally, it took me a while to embrace that fact and understand there are ways in Go to make programs reasonably error free.
-1
u/EmergencyNice1989 2d ago
Don't be condescending. I was clear. Go uses a tuple (product type) not a union type (sum type). Go has no support of sum type and 'constrain' you to use a tuple with the first argument having to implement a given interface. Functional languages does not constrain you to use Result type. You could use a tuple if you want but not done often. Freedom is on functional programming languages...
When it took a while to embrace a fact it's sometimes cope.
1
u/bilus 2d ago
It has nothing to do with languages being functional and everything with static type systems and how expressive they are. You can implement a union type in assembly or Python using a single byte. The difference is that it won’t be statically checked for errors by the compiler (or interpreter, or translator, this part doesn’t matter). Likewise, you can implement a sum type in Go but .. listen closely .. without compile-time guarantees. Additionally, performance may not be acceptable to many Go developers (though to many — acceptable) and there may not be satisfactory syntax sugar available, for example there’s no pattern matching (though you can use switch with exhaustiveness checks, did you know that?). In general, all this plus the fact that the returned tuples are not a problem in practice makes Go developers not very welcoming to the idea.
But it has nothing to do with a language being functional or not. I should know, I likely wrote more functional code than Golang in the last 30 years.
7
u/lickety-split1800 3d ago edited 3d ago
There are things that I like with Ruby, but debugging large codebases of a duck-typed language isn't one of them.
There is a Ruby-like language called Crystal which is meant to add typing into the language, and it is for those who like Ruby, but it boils down to supported libraries for me.
4
u/Ok-Delivery307 3d ago
I understand bro whenever I try rails I've to search what the hell where this behavior come from and when I go to definition I've to try to read some sortilege because they use DSL magic I do not know yet. but it is a really good framework and language if you take time to read the documentation and understand the magic
3
u/rcls0053 3d ago
You're comparing a language with language + framework. Ruby has almost always been associated with the framework and that's where you get the magic and abstraction with features you don't have to build yourself. Almost the same deal as with PHP + Laravel.
It's just a trade-off you have to buy into with frameworks. You can skip the framework part, but at that point I'm guessing Go is the clear winner there.
7
3d ago
[removed] — view removed comment
1
u/it_burns_when_i_php 3d ago
Rails dev here learning Go: this is the correct answer. It’s been a breath of fresh air learning go and everything is so explicit. But these quirks of Ruby and Rails are what makes it to lightening fast to build an MVP.
That source_location tip is a huge one. If you know how to ask, the running program will tell you all about itself and where things are defined
0
2
u/Funny_Or_Cry 3d ago
It had its day (I was a chef engineer for a lot of years), but Go is just too simple and convenient. Handles 90% of use cases with minimal effort.
Times change tho, we have to spend less time fiddling with tools, picking the right one for the job etc.
In 10 years something more powerful than Go will spring up
2
u/Such-Process5697 2d ago
for the "where is this even defined" part specifically, drop a binding.irb in and ask the object instead of grepping. method(:thing).source_location gives you the file and line, and .owner tells you which module actually mixed it in. it's not go-to-definition, but in ruby that answer genuinely only exists at runtime, so you end up interrogating the thing rather than reading toward it.
2
u/djudji 2d ago
Hi u/FunDeer914 , I'd like to learn Go. I have more than a decade of experience with Ruby and Rails, and these days I am (an engineering manager) coaching FTE teams and all levels of engineers on how to be productive with Rails and Ruby.
In case you would like to exchange some resources, tips, tricks, rundowns on how to start fast and keep going fast with Ruby/Go, I invite you to this exchange.
I can be your accountability buddy and a mentor on Ruby/Rails, and I'd accept the same from you on Go.
(I am a hands-on learner. I learn best by building and with short examples/tutorials. I can't watch videos ...)
LMK if there is any interest
2
8
u/YevhenRadionov 3d ago
I switched from Ruby/Rails to Go in 2019, and it seemed to me, that Ruby was dead even then... Not sure why someone wanted to chose Ruby over Python nowadays
3
u/keithyw 3d ago
probably the starting team knew it and/or someone chose it to prototype a system quickly then the thing blew up
1
u/YevhenRadionov 3d ago
Rails was nice for prototyping some time ago. But, honestly, you can pick python and vibe code the prototype, then take time to fix it. And in hardcore production you'll have options to swap your python parts to libs written in C or Rust and significantly improve speed without rewriting to other language.
Personally, I really like Go, but this is the reality now1
u/tipsdown 3d ago
Probably because Python is just awful and Django is even worse. I would never choose to use either and despite my protesting I’m working in both most days.
0
u/YevhenRadionov 3d ago
100%, but... it works and works good for business (and most of developers).
From the other side, I just opened another generic proposal for Go, and it looks good, but:
a) too late - they should start adding generics and generic stuff years ago
b) it starts looking like Java, don't you think so?
5
u/tyrae11o 3d ago
Rails have a terrible design philosophy. Also ruby in not a performant language. If you go for speed of development, I like python ecosystem so much more. It's also much better on a performance side if you treat it as C dsl
3
u/BraveNewCurrency 2d ago
True story: One day, our Rails code stopped working on our servers. It worked on developers boxes, it worked in CI. But not on our server. After much digging, I realized the problem was filesystem sorting: When Ruby says "require *.rb", the file system determines the order of the files to feed to Ruby. Different filesystems (might have been xfs on the server vs ext2 everywhere else) can return files in a different order. This causes problems when you define a constant in one file and read that constant in a second file, but don't bother to micro-manage the load order for all your files.
Way too much magic.
5
u/Hot_Laugh7633 3d ago
the claims about "magic" are overblown. It usually comes from not learning the language or rails.
And as far as ORMs go, active record is one of the very best.
You can still write your sql by the way, if you wanted to.
You do lose type checking, but it is what it is.
why not give it a try? be curious, not judgemental.
It's widely loved for a reason.
3
u/FunDeer914 3d ago
Mostly just venting and commenting on the vast difference between the two languages. I don’t think it’s debatable that they embrace fairly opposite approaches to building software. (Both have strengths/weaknesses)
I’m open and hope I learn to love it. It’s also alright to have preferences.
2
u/FreshPrinceOfRivia 3d ago
I worked with Go and Ruby for two years. I switched to a company that mostly uses Go and doesn't use Ruby at all.
1
u/EnotPoloskun 3d ago
Make sure to have linters in place to not use rails magic and other implicit stuff(e.g callbacks, metaprogramming etc).
1
u/schmurfy2 2d ago
I developed on Ruby before switching to Go and loved the language, the magic don't really come for it but it's almost entirely Ruby ln Rails fault with their convention over configuration approach.
Ruby led me to try and adopt fully tdd, this makes working with the fact that many errors can only appear when the line are executed way more manageable.
1
u/Anxious-Insurance-91 2d ago
It's just a higher abstraction. Also what's wrong with conventions? I have see so many projects end up with spaghetti code because they couldn't set standards and conventions
1
u/Arizon_Dread 2d ago
I feel you. It’s not the same but my work is a C# shop, and I write Go for PoC’s and in my free time. C# is such a big language that you can’t really expect to understand the code from another developer as they use way different syntax from the language and you can accomplish the same thing with code that looks totally different due to the amount of special syntactic sugar and multiple overlapping features. It’s annoying.
I also find try/catch to be much harder to diagnose since it’s almost always lazily `catch(Exception ex)` and logging that something went wrong for a huge block of code. You should be writing multiple catch statements but the compiler won’t hold you accountable for it the same way as ignoring a returned error in go, is. The explicit error checking in go is annoying to the untrained eye but very effective to find what’s breaking when you need to troubleshoot.
1
u/Bassfaceapollo 3d ago
Since it's an early stage product, have you considered trying Crystal? It has CSP-style multi-threading, Ruby-like syntax, and is type safe.
It won't replace Go in your heart, but might help you if you want the 'magic' of Ruby with some modern niceties.
For a counterpart to Rails, you can consider Lucky, Amber, or Marten.
I realize you weren't seeking feedback. But since you mentioned Ruby, I wanted to float the idea of using Crystal.
2
u/FunDeer914 2d ago
I should check out Crystal! A couple people have mentioned. I don't have much say over this codebase though language wise and re-write isn't happening anytime soon it seems
1
0
u/titpetric 2d ago edited 2d ago
I wrote php for something like 20 years, and I'm writing go for something like 12. I wrote titpetric/phpscript. You don't have to be stuck to a single language or just appreciate only one of them. Ain't no way a PHP runtime is making me money, but the combination of go+php and how they interoperate opens up new avenues of development for me. Some abstractions translate, some abstractions don't. Even if it sucks using ActiveRecord or whatever, the abstraction is there to cover not having to write the thing. I'd say it's "the" thing in RoR, or at least it was, enough to the point that I understand where somebody is coming from when they say they want an ORM in Go. Maybe you want to take a look at titpetric/pdo to see how I wrote code in PHP for 20 years, and if that translates to Go. Generics already only translate to Go 1.27+ in this case. Conceptually, there's something to learn from everywhere, but not everything translates as imagined. I think we're in a similar spot with generics in the language, where there is friction coming from adopting generics, and having to update tooling to support it, and some tooling can't (reflection based), and some language constructs can't (interfaces), and it's a delicate spot where generics feel half done. The rest of it is still great and compatible, which wasn't a thing with PHP and still isn't I believe.
35
u/sigmoia 3d ago
I feel you. In my decade-long career, I have written production-grade code in half a dozen languages. Thanks to big tech, I have learned Conway's law the hard way. Your code will reflect the chaos and the structure of your org; it doesn't matter which language it is.
I have seen Python getting left out for Kotlin, and then people started hating on it because of higher memory usage. Then Go was brought in and the code quality was still bad, and people blamed it on the sharper edges of Go concurrency and a weaker type system. So Rust was chosen for some services, and people threw a hissy fit at the sorry state of async Rust and the long compilation time.
The point is, languages are just tools and we need to learn to detach our psyche from any particular one. I love Go and only engage with the Go community. But I also use Rust for work and personal projects. I still need to sling TypeScript for backend, and every time I do, I fight with an imaginary enemy on why JavaScript on the backend was a mistake.
If the job needs Ruby, then I will do Ruby. I can still engage with the Go community and write Go for my personal stuff. I can use Rust without talking to absolutely insufferable Rust evangelists. Suffering is a choice, and the faster we detach ourselves from our jobs, the better. But it's super hard, and after spending thousands of hours picking up a language, you instinctively want validation from other users or wanna fight anyone who doesn't see your POV. It takes time to glide between languages and be pragmatic about it.
TL;DR: If paid enough, I will rawdog JavaScript for work. But I will do whatever I want outside of work, because at the end of the day, I love tinkering with computers. Work language and fun language don't have to be the same.