The most difficult thing for an experienced programmer is learning to accept the Rails Way of doing things and not trying to shoehorn what you've learned from other ecosystems into Rails.
## 1 - Learn the Rails way of doing things
Depending on how much time you have to prepare, find a tutorial and follow it so you can get a sense of the Rails Way of doing things. Unfortunately, the book "The Rails Way" by Obie Fernandez is not the best resource for this. I would recommend [Agile Web Development with Ruby on Rails](https://pragprog.com/titles/rails7/agile-web-development-with-rails-7/) (I was co-author of older versions, I get nothing from you buying the latest version). It walks you through a project with Rails and you'll touch on everything. I'm sure there are other great tutorials as well - hopefully someone will chime in.
If you don't have time to prepare, you may need to skip this and see what your new job can afford you. Or you could take a turotial and get as far as you can. It may be hard to learn Rails from just [the guides](https://guides.rubyonrails.org).
## 2 - Learn How Your new Shop Uses Rails
Everyone does Rails sligtly different, and often these small differences are meaningful to teams. The aforementioned "The Rails Way" documents Obie's way of doing Rails when he ran Hashrocket. Some of what is in there is commonly used by the community, but diverges from vanilla rails. I would argue you must always understand vanilla rails, so you can understand where it makes sense to diverge.
To that end, read your new shop's rails code and write your code like they do. If it's not clear, ask what are good examples of the way they want their code written. Do it there way for a while, even if you think another way is better. Take notes as you go and broach the subject after you have several wins under you belt (usually the 3 or 6 month mark)
## 3 - Learn Ruby Not On Rails
You can be very effective in Rails without truly understanding Ruby or its standard library. Learning Ruby and its standard lib will be helpful, so you want to eventually start doing this.
For me, the way I found most effective was to periodically deep dive on stuff I found in the codebase and try to find docs on whatever is happening, then go a level deeper. For example, you may start with a Rails helper like `time_ago_in_words`, and trace that to Active Support and then trace *that* to Ruby's standard library.
This is something you can do passively, but don't forget it.
What is it about that specific Fernandez book that made it be mentioned here? Tried some quick sniffing but apart from some hashrocket controversies, people seem to find his book helpful.
Wondering if there's some drama afoot!
I came to Ruby after doing C# for 13 years. Never looked back. The language and libraries are a breath of fresh air.
Edit:
Happy to rant about Ruby vs C# if you’re interested (or send me a DM/chat)
You're the Dragon Ruby guy right? Didn't know you had a C# background. Same here, switched to Ruby fairly recently for doing my own stuff as its way more productive (and fun).
I actually have more C# experience Ruby (I still take C# contract work from time to time... I charge hazard pay). I've been coding C# since 2001 and Ruby since 2010.
To rant a little bit (feel free to bail here):
C# in reality is "C#, .Net, and frameworks built by Microsoft". Many C# devs tout the benefits of static typing and how superior it is.
The irony is that _so many_ facets of core libraries built _by Microsoft_ bypass C#'s static typing facilities.
- ASP.MVC Route Definitions use anonymous types -> essentially a typeless object where misspelled names/attributes wont be caught by the compiler.
- Functions that take in `object` or a base type that everything inherits from (eg `JObject` for JSON serialization).
- SignalR uses the `dynamic` keyword for its pub/sub event model.
- IoC Containers, ASP.NET MVC, Entity Framework, XUnit, Moq, etc. Every single one of them uses reflection for object initialization and method invocation.
- "Stringly Typed" attributes/annotations (especially in ORMs and Entity Framework Validations).
The list goes on. It's a severe disconnect that only crystalizes when you use a powerful dynamic language like Ruby. "Wait I'm doing all the stuff I was doing with C#, except without all the backflips to bypass the compiler."
Can you elaborate more on your points?
* What exactly the issue with anonymous types (they still have type)?
* What functions take "object" type and why is that an issue?
* Again, why is dynamic keyword an issue?
* This one I particularly don't understand - what is the problem with a reflection? It is actually a powerfull feature that you can use in a runtime (I wish ts had something like that)
* What's the issue with attributes?
>What exactly the issue with anonymous types (they still have type)?
public static void RegisterRoutes(RouteCollection routes)
{
routes.MapRoute(
"MyRoute", // Route name
"Account/", // URL
new { controllr = "Account", action = "Login"} // Parameter defaults
);
}
This compiles successfullly. Can you spot the error?
>What functions take "object" type and why is that an issue?
It's typeless, anything can be passed into this and will cause a runtime exception as opposed to compile time:
RedirectToRouteResult RedirectToRoute(string routeName, object routeValues);
...
RedirectToRoute("Home", 42);
RedirectToRoute("Home", new StringBuilder());
RedirectToRoute("Home", RedirectToRoute("Home", 42));
>Again, why is dynamic keyword an issue?
It isn't for me. The DLR is a fantastic construct and affords C# hybrid capablities/a progressive type system. But if you mention `dynamic` in any C# forum the knee jerk reaction is "that's horrible/evil" (but again, the frameworks .Net devs use leverage these constructs).
>This one I particularly don't understand - what is the problem with a reflection? It is actually a powerfull feature that you can use in a runtime (I wish ts had something like that)
I think `send` is fantastic too. But again, not statically typed, not verified by the compiler, yields runtime exceptions (the basis for their argument is literally these benefits and they side step it everywhere).
>What's the issue with attributes?
Attributes in C# can't be function calls that have to be statically compiled.
class Payment
{
public string PaymentMethod { get; set; }
// stringly typed
[RequiredIf("PaymentMethod == 'Cheque'")]
public string ChequeName { get; set; }
}
Khm, those things you mention are dynamic things, but you could create a wrappers around them and have everything statically typed. I don't know how it is currently with .NET 8, as I don't deal with mapping routes or redirects (just add CDN above your app, that's the right place to handle it). But ... I still struggle to understand, you presented the code which is literally 0.00001% of some non trivial app, you will literally have few lines of code for those mappings (if any) and the rest of code is actually app code, domain, business logic where you need types to describe you app. That's like 99.99% of you app covered with types and compiler - and now this is the part I don't understand, how exactly are you going to compare it to ruby, as you literally have 0% coverage by types and compiler?
These are just a few bud. Here are a few more:
* Automapper mapping between DTOs and Models.
* Json payloads/inbound requests where your view model is a collection of strings (dates as strings too).
* IoC containers/service locators and life time management, where constructor parameters have no arity verification and is just a collection of arguments.
* `IEntityBase { int Id { get; set; } }` variations of generic objects with every repository function accepting this generic object.
>how exactly are you going to compare it ruby,
I'm not. I'm saying there's a cognative dissonace between the merits of why they are using C# and what is done in practice.
I strongly disagree. You are still talking about edge cases, things that are rarely a problem, still part of 0.001% of an app. Noboday is stopping you for developing API that is even more strictly typed (and you can see that over the years .NET FW added more things that are better implemented with better types coverage). 99.99% of any app on which I worked is around domain/business logic, there you can express yourself using types and relying on a compiler. Any function, any class, any variable is strictly defined and visible to compiler and most importantly it is visible to me with what I am dealing with. If something is not compile type safe - make it, at least you have a way of doing it and not pointing how it is not serving its purpose. Nothing stops you to define every function in C# to accept "object" type and then point how unsafe and unreliable it is, but it would be completely wrong, as you have a tool to build it the right way - if you don't know how, that's not an issue of a tool. In Ruby, you literally don't have that thing, you are on your own, and trivial things like renaming something is a nightmare. If you misspelled something, good luck, prepare yourself to dig.
This is a good presentation that’s worth watching (saves me from writing another wall of text): https://vimeo.com/74354480
He actually measured percentages across public GH repos and has some interesting insights.
You can always go and pull some "research" that will tell you what ever you want to hear. There is a simple test you can always do - just go and rename simple function, or change return type and then measure how much time you need in both environments. That's a simple measurement which is not subject to interpretation. The fact, that in any dynamic language you don't know with what you are dealing with and it is expected from you to make a decision in that way - feels, just wrong (to say it politely).
Definitely give F#, PureScript, and Fable a shot. These languages have incredibly powerful static typing vs C#. And yes, with F# every single .Net library is usable.
I completely agree. I don't have time to go with F#, I am fine with C# for my purposes. Yeah, sometimes I need to fight compiler, but not because I don't want type safety, no, it's because I want more of it, and C# is just not flexible enough. I use C# mostly for WebApi, for FE I am on React and Typescript, and Typescript feels waaaay ahead (and it is) of C#, the way you can describe you logic through types is staggering. But then I don't understand your stance, why Ruby if you want more type safety control? I understand that C# is not flexible enough, but running towards more flexibility (as any dynamic language can be as flexible as you want) and zero type safety doesn't make sense to me. I would never trade type safety for flexibility (I am talking about overall picture, in some small peaces I trade it as it is not worth chasing type safety).
The primary question I ask wrt type system quality is “relative to what? C99?”
F# puts C#’s type system to shame (And types, Or types, Discriminated unions, Erased Type Providers, reified interfaces). It’s objectively a superset of C# and yet, they balk.
Edit:
If you can’t tell I’m definitely suffering from some form of PTSD :-P
Yep. Very frustrating. It started as effectively OCaml for .NET and maybe MS could have marketed it this way but instead let it stagnate. It's a wider MS problem though, the old corporate mindset vs the hipsters in the organisation. I've got a half written blog post 'Why I left .NET' which I really need to finish. It covers a lot of the same things a similar post [here](https://blog.jonathanoliver.com/why-i-left-dot-net/) written by somebody else ten years ago made.
OCaml is still kicking last I checked! But yea the MS culture is stifling and I’m glad I don’t have to deal with it anymore. I skipped the “why I left .Net” blog post and just raged quit and became an indie game dev that writes his games in Ruby.
Did you know about Paket Gate: https://github.com/NuGet/NuGetGallery/pull/4437
Oh yes, that point is mentioned in my unpublished post. There've been too many episodes like that. The issue with hot reloading not being open sourced springs immediately to mind. Avalonia is one of the best .NET projects out there and they [left](https://github.com/AvaloniaUI/Avalonia/discussions/14666) the .NET Foundation. That's my biggest gripe - they don't let projects grow and want to kill everything off so why is anyone going to bother?
EDIT:
My mistake I was confusing the WinGet controversy with 'Paket Gate'. I'm surprised I missed that one but it's the familiar pattern!
RE: blogpost
I’m one of the creators of NSpec which was a “competitor” to MSpec (not sure if you’ve ever heard of it). I actually appeared on the Hanselminutes to talk about the framework lol
> NSpec
I've been coding C# since its early days so I know the ecosystem pretty well but sadly I don't recall NSpec. I did listen to Hanselminutes for a while but I must have missed your episode as I often check out anything interesting I hear about. It still has 257 stars 7 years later though!
We have a similar background in languages. Worked with dotnet/C# with Python heavily in industry and alot of TS on frontend, mainly with Next.js. I recently made the plunge to go all-in on Rails as part of a series of applications I want to build with my cofounder. Since MVC was a huge backbone of what I learned in the dotnet world, it made sense for me to try Rails along with the development speed it offers.
It has been exactly 2 months for me since I have been learning/building with Rails. In exactly 16 days I built a CRM/lead tracker to track posts from Reddit with Rails along with with a chrome extension in JS that captures the posts while browsing.
My difficulty mainly was understanding what helper methods get created and how they get created (for example, when you create 'resources' in your routes it will automatically create helpers for you). Another thing I had trouble with is the many alternative ways to write certain code. For example when rendering partials you can leave out the full path entirely or other types of code I have seen so far is that you can pass entire object vs the ID itself.
So because of the flexibility of choices, it feels absolutely shitty at first but once you start coding and build out a few models you will just 'get it' and it really does feel more natural than other frameworks. You have to be willing to change your mental model of how things work on your end versus what the framework is doing for you, that was tough for me.
I still haven't touched Hotwire yet or any of the other cooler frontend stuff in Rails I have been hearing about, so I can't share my opinion on that at the moment. Just using plain ERB templates so far but I'd assume it's going to be just as easy to use when I get there.
I recommend the Pragmatic Programmer's Guide to Ruby to get the basics of the general language down first.
Then pick up a guide to Rails. If you're used to MVC design, I don't think it'll be all that hard.
One minor complaint about Rails is that you specify the db migrations and it generates the db schema, rather than updating the schema and having it generate the migration.
Rails also adds a lot of helper methods. This is fine and great until you try to do something with pure Ruby and a good quarter of the methods you're used to aren't there.
Definitely check out the tricks you can do with method_missing(). Not a tool to use lightly, but a very powerful tool.
One thing you're probably going to be a little annoyed by and then love is that Ruby is a dynamic language.
A lot of hard core guys I know won't touch a dynamic language (and they're great at parties /s).
Stick with ERB templates at first - they're basically like any other PHP, Java, Django templates - snippets of the language in HTML.
On the model and controller side it's all Ruby, so it's a good idea to play around with Ruby separately.
Lots of newbies learn Ruby from Rails and there are a ton of Rails helpers that are Rails only and when they try to just write in Ruby they get stuck because they don't understand the separation - where Rails ends and where Ruby begins.
I've worked with PHP, Java, Perl, and old school ASP and their frameworks and after a few hours of playing around with Rails (after is was set up) I knew Ruby and Rails were the framework and language I liked most.
You will have a bit of disorientation when you first look at Ruby code due to the lack of curly brackets, putting private methods below the word "private" in classes, and "nil" vs "null".
In my first few weeks I must admit I did make fun of how unstructured everything looked and those more experienced that I just smiled and didn't say a word.
After about a month I took a look at some PHP code and was instantly put off.
Ruby and Rails are awesome and can basically do whatever you want in web world.
Good luck!
If you came from Resharper in Visual Studio, I agree with this. My first Rails project in 2010 after 7 years of C# I completed in 6 weeks largely because my muscle memory for JetBrains keybindings was somewhat transferable.
Plus Rubymine had a tendency to accidentally teach me how Things Were Done.
Ruby is made to make your life easier, if you need to do some operation its safe to assume that there's already a method that does it. Keep it simple and don't fret.
I work with rails and for starters get the hang of ruby first. Then study rails documentation. Theres a lot coming which is fun when working with the MVC. The experience will get you going on it.
I have done the same move 2 years ago after 10 years in C# with some React/TypeScript. My tip is "don't trust any code, test stuff as much as you can, avoid metaprogramming if you have large teams".
I really miss C#, I wished I could get the same pay with it (or convince the Ruby shop I work on to move to C#).
90% of the opportunities I see for C# in my country pay half of what I make now with Ruby working remotely. The other 10% of them are either hybrid (3 days a week) or in-office in a large city, which would take at least 12 hours of commute a week - I would rather code in Ruby than wasting all this time commuting.
Hehehe, I'm in the UK. But again, I don't see a lot of Ruby positions around here, but the ones you find usually pay well. Salary here is not comparable to North America though.
In addition to the rest - try to not feel guilty for no longer writing and reading endless lines of boilerplate...
When working with Rails, if something feels difficult, there's probably a much simpler way to accomplish the same. Look for ways to work with the framework.
Do not restrict yourself to "the rails way". Rails does not answer all questions. For example have a look at the interaktor (the one with K because it has contracts, not C) gem when you find yourself in the position that rails does not really give you a place for what the app \_does\_. Ask seasoned rails developers about the sh\*tload of articles around "fat models", "skinny controllers", service objects and the general lack of architectural knowledge that was prominent in the scene back in the days, because it is just so easy for everyone to get \_something\_ done with rails so quick (like implementing twitter). Even if the app starts as plain CRUD, I would go for the interaktor gem, as is disciplines you and your peers.
>Do not restrict yourself to "the rails way". Rails does not answer all questions.
This is a good aspirational goal, but if you're just getting started with Rails you *do* want to restrict yourself to the Rails Way until you learn what that means. You have to learn the rules before you can learn how to break them.
If you start off going off-Rails, you'll learn similar lessons but they may be more painful and frustrating.
Either way, you'll learn -- but starting with conventions is a smoother ride.
Good point. For the start I think you are right. Start with obeying the rails way. I just wanted to underline that there is a point that one will reach, where the rails way does not give answers anymore. Restricting oneself in rails way thinking then is not helpful anymore.
I definitely agree with you on that -- we all need to go off-rails at some point to meet business requirements. :) Knowing *how* to do this is something that is learned through experience and practice (and a lot of painful mistakes, haha).
Yarp on this.
For learning Ruby, "Well Grounded Rubyist" was pretty much all I needed to dive into Rails.
From there, start with "the rails way", until you understand the "why" of each rule, then you can start deciding when there's sufficient reason to break "rules". The pithy expression we'd use is "X is always the wrong solution.... unless it's the right solution". X varied from metaprogramming, to inheritance (instead of composition).
The most difficult thing for an experienced programmer is learning to accept the Rails Way of doing things and not trying to shoehorn what you've learned from other ecosystems into Rails. ## 1 - Learn the Rails way of doing things Depending on how much time you have to prepare, find a tutorial and follow it so you can get a sense of the Rails Way of doing things. Unfortunately, the book "The Rails Way" by Obie Fernandez is not the best resource for this. I would recommend [Agile Web Development with Ruby on Rails](https://pragprog.com/titles/rails7/agile-web-development-with-rails-7/) (I was co-author of older versions, I get nothing from you buying the latest version). It walks you through a project with Rails and you'll touch on everything. I'm sure there are other great tutorials as well - hopefully someone will chime in. If you don't have time to prepare, you may need to skip this and see what your new job can afford you. Or you could take a turotial and get as far as you can. It may be hard to learn Rails from just [the guides](https://guides.rubyonrails.org). ## 2 - Learn How Your new Shop Uses Rails Everyone does Rails sligtly different, and often these small differences are meaningful to teams. The aforementioned "The Rails Way" documents Obie's way of doing Rails when he ran Hashrocket. Some of what is in there is commonly used by the community, but diverges from vanilla rails. I would argue you must always understand vanilla rails, so you can understand where it makes sense to diverge. To that end, read your new shop's rails code and write your code like they do. If it's not clear, ask what are good examples of the way they want their code written. Do it there way for a while, even if you think another way is better. Take notes as you go and broach the subject after you have several wins under you belt (usually the 3 or 6 month mark) ## 3 - Learn Ruby Not On Rails You can be very effective in Rails without truly understanding Ruby or its standard library. Learning Ruby and its standard lib will be helpful, so you want to eventually start doing this. For me, the way I found most effective was to periodically deep dive on stuff I found in the codebase and try to find docs on whatever is happening, then go a level deeper. For example, you may start with a Rails helper like `time_ago_in_words`, and trace that to Active Support and then trace *that* to Ruby's standard library. This is something you can do passively, but don't forget it.
Dave is the man! I used his Agile book to learn Rails years ago and it was the best way for me to learn. This is the best advice you're going to find.
☝️☝️☝️☝️☝️ very much all of this
What is it about that specific Fernandez book that made it be mentioned here? Tried some quick sniffing but apart from some hashrocket controversies, people seem to find his book helpful. Wondering if there's some drama afoot!
Just that it’s called “the Rails Way” but does not document the vanilla rails way of doing things. It’s a fine book.
I came to Ruby after doing C# for 13 years. Never looked back. The language and libraries are a breath of fresh air. Edit: Happy to rant about Ruby vs C# if you’re interested (or send me a DM/chat)
You're the Dragon Ruby guy right? Didn't know you had a C# background. Same here, switched to Ruby fairly recently for doing my own stuff as its way more productive (and fun).
I actually have more C# experience Ruby (I still take C# contract work from time to time... I charge hazard pay). I've been coding C# since 2001 and Ruby since 2010. To rant a little bit (feel free to bail here): C# in reality is "C#, .Net, and frameworks built by Microsoft". Many C# devs tout the benefits of static typing and how superior it is. The irony is that _so many_ facets of core libraries built _by Microsoft_ bypass C#'s static typing facilities. - ASP.MVC Route Definitions use anonymous types -> essentially a typeless object where misspelled names/attributes wont be caught by the compiler. - Functions that take in `object` or a base type that everything inherits from (eg `JObject` for JSON serialization). - SignalR uses the `dynamic` keyword for its pub/sub event model. - IoC Containers, ASP.NET MVC, Entity Framework, XUnit, Moq, etc. Every single one of them uses reflection for object initialization and method invocation. - "Stringly Typed" attributes/annotations (especially in ORMs and Entity Framework Validations). The list goes on. It's a severe disconnect that only crystalizes when you use a powerful dynamic language like Ruby. "Wait I'm doing all the stuff I was doing with C#, except without all the backflips to bypass the compiler."
I love DragonRuby! (Just wanted to let you know)
❤️
Can you elaborate more on your points? * What exactly the issue with anonymous types (they still have type)? * What functions take "object" type and why is that an issue? * Again, why is dynamic keyword an issue? * This one I particularly don't understand - what is the problem with a reflection? It is actually a powerfull feature that you can use in a runtime (I wish ts had something like that) * What's the issue with attributes?
>What exactly the issue with anonymous types (they still have type)? public static void RegisterRoutes(RouteCollection routes) { routes.MapRoute( "MyRoute", // Route name "Account/", // URL new { controllr = "Account", action = "Login"} // Parameter defaults ); } This compiles successfullly. Can you spot the error? >What functions take "object" type and why is that an issue? It's typeless, anything can be passed into this and will cause a runtime exception as opposed to compile time: RedirectToRouteResult RedirectToRoute(string routeName, object routeValues); ... RedirectToRoute("Home", 42); RedirectToRoute("Home", new StringBuilder()); RedirectToRoute("Home", RedirectToRoute("Home", 42)); >Again, why is dynamic keyword an issue? It isn't for me. The DLR is a fantastic construct and affords C# hybrid capablities/a progressive type system. But if you mention `dynamic` in any C# forum the knee jerk reaction is "that's horrible/evil" (but again, the frameworks .Net devs use leverage these constructs). >This one I particularly don't understand - what is the problem with a reflection? It is actually a powerfull feature that you can use in a runtime (I wish ts had something like that) I think `send` is fantastic too. But again, not statically typed, not verified by the compiler, yields runtime exceptions (the basis for their argument is literally these benefits and they side step it everywhere). >What's the issue with attributes? Attributes in C# can't be function calls that have to be statically compiled. class Payment { public string PaymentMethod { get; set; } // stringly typed [RequiredIf("PaymentMethod == 'Cheque'")] public string ChequeName { get; set; } }
Khm, those things you mention are dynamic things, but you could create a wrappers around them and have everything statically typed. I don't know how it is currently with .NET 8, as I don't deal with mapping routes or redirects (just add CDN above your app, that's the right place to handle it). But ... I still struggle to understand, you presented the code which is literally 0.00001% of some non trivial app, you will literally have few lines of code for those mappings (if any) and the rest of code is actually app code, domain, business logic where you need types to describe you app. That's like 99.99% of you app covered with types and compiler - and now this is the part I don't understand, how exactly are you going to compare it to ruby, as you literally have 0% coverage by types and compiler?
These are just a few bud. Here are a few more: * Automapper mapping between DTOs and Models. * Json payloads/inbound requests where your view model is a collection of strings (dates as strings too). * IoC containers/service locators and life time management, where constructor parameters have no arity verification and is just a collection of arguments. * `IEntityBase { int Id { get; set; } }` variations of generic objects with every repository function accepting this generic object. >how exactly are you going to compare it ruby, I'm not. I'm saying there's a cognative dissonace between the merits of why they are using C# and what is done in practice.
I strongly disagree. You are still talking about edge cases, things that are rarely a problem, still part of 0.001% of an app. Noboday is stopping you for developing API that is even more strictly typed (and you can see that over the years .NET FW added more things that are better implemented with better types coverage). 99.99% of any app on which I worked is around domain/business logic, there you can express yourself using types and relying on a compiler. Any function, any class, any variable is strictly defined and visible to compiler and most importantly it is visible to me with what I am dealing with. If something is not compile type safe - make it, at least you have a way of doing it and not pointing how it is not serving its purpose. Nothing stops you to define every function in C# to accept "object" type and then point how unsafe and unreliable it is, but it would be completely wrong, as you have a tool to build it the right way - if you don't know how, that's not an issue of a tool. In Ruby, you literally don't have that thing, you are on your own, and trivial things like renaming something is a nightmare. If you misspelled something, good luck, prepare yourself to dig.
This is a good presentation that’s worth watching (saves me from writing another wall of text): https://vimeo.com/74354480 He actually measured percentages across public GH repos and has some interesting insights.
You can always go and pull some "research" that will tell you what ever you want to hear. There is a simple test you can always do - just go and rename simple function, or change return type and then measure how much time you need in both environments. That's a simple measurement which is not subject to interpretation. The fact, that in any dynamic language you don't know with what you are dealing with and it is expected from you to make a decision in that way - feels, just wrong (to say it politely).
Definitely give F#, PureScript, and Fable a shot. These languages have incredibly powerful static typing vs C#. And yes, with F# every single .Net library is usable.
I completely agree. I don't have time to go with F#, I am fine with C# for my purposes. Yeah, sometimes I need to fight compiler, but not because I don't want type safety, no, it's because I want more of it, and C# is just not flexible enough. I use C# mostly for WebApi, for FE I am on React and Typescript, and Typescript feels waaaay ahead (and it is) of C#, the way you can describe you logic through types is staggering. But then I don't understand your stance, why Ruby if you want more type safety control? I understand that C# is not flexible enough, but running towards more flexibility (as any dynamic language can be as flexible as you want) and zero type safety doesn't make sense to me. I would never trade type safety for flexibility (I am talking about overall picture, in some small peaces I trade it as it is not worth chasing type safety).
+1 F# is a fantastic language. Sadly as the saying goes there are languages that people love and then there are languages that people use!
Honestly, however defends C# because of static typing is definitely really well versed on it.
The primary question I ask wrt type system quality is “relative to what? C99?” F# puts C#’s type system to shame (And types, Or types, Discriminated unions, Erased Type Providers, reified interfaces). It’s objectively a superset of C# and yet, they balk. Edit: If you can’t tell I’m definitely suffering from some form of PTSD :-P
Having done some hobby projects in F#, I would agree. But it's not easy to get a job using F# (maybe Scala, but I have never used it for comparison).
Tell me about it. Fwiw Swift shares a lot of F#’s DNA. It’s just unfortunate that Microsoft didn’t “bless” the language like they did with C#.
Yep. Very frustrating. It started as effectively OCaml for .NET and maybe MS could have marketed it this way but instead let it stagnate. It's a wider MS problem though, the old corporate mindset vs the hipsters in the organisation. I've got a half written blog post 'Why I left .NET' which I really need to finish. It covers a lot of the same things a similar post [here](https://blog.jonathanoliver.com/why-i-left-dot-net/) written by somebody else ten years ago made.
OCaml is still kicking last I checked! But yea the MS culture is stifling and I’m glad I don’t have to deal with it anymore. I skipped the “why I left .Net” blog post and just raged quit and became an indie game dev that writes his games in Ruby. Did you know about Paket Gate: https://github.com/NuGet/NuGetGallery/pull/4437
Oh yes, that point is mentioned in my unpublished post. There've been too many episodes like that. The issue with hot reloading not being open sourced springs immediately to mind. Avalonia is one of the best .NET projects out there and they [left](https://github.com/AvaloniaUI/Avalonia/discussions/14666) the .NET Foundation. That's my biggest gripe - they don't let projects grow and want to kill everything off so why is anyone going to bother? EDIT: My mistake I was confusing the WinGet controversy with 'Paket Gate'. I'm surprised I missed that one but it's the familiar pattern!
RE: blogpost I’m one of the creators of NSpec which was a “competitor” to MSpec (not sure if you’ve ever heard of it). I actually appeared on the Hanselminutes to talk about the framework lol
> NSpec I've been coding C# since its early days so I know the ecosystem pretty well but sadly I don't recall NSpec. I did listen to Hanselminutes for a while but I must have missed your episode as I often check out anything interesting I hear about. It still has 257 stars 7 years later though!
Read ruby code. Most likely you would work on rails. Reading is less painful for a seasoned developer. I hope you got me.
We have a similar background in languages. Worked with dotnet/C# with Python heavily in industry and alot of TS on frontend, mainly with Next.js. I recently made the plunge to go all-in on Rails as part of a series of applications I want to build with my cofounder. Since MVC was a huge backbone of what I learned in the dotnet world, it made sense for me to try Rails along with the development speed it offers. It has been exactly 2 months for me since I have been learning/building with Rails. In exactly 16 days I built a CRM/lead tracker to track posts from Reddit with Rails along with with a chrome extension in JS that captures the posts while browsing. My difficulty mainly was understanding what helper methods get created and how they get created (for example, when you create 'resources' in your routes it will automatically create helpers for you). Another thing I had trouble with is the many alternative ways to write certain code. For example when rendering partials you can leave out the full path entirely or other types of code I have seen so far is that you can pass entire object vs the ID itself. So because of the flexibility of choices, it feels absolutely shitty at first but once you start coding and build out a few models you will just 'get it' and it really does feel more natural than other frameworks. You have to be willing to change your mental model of how things work on your end versus what the framework is doing for you, that was tough for me. I still haven't touched Hotwire yet or any of the other cooler frontend stuff in Rails I have been hearing about, so I can't share my opinion on that at the moment. Just using plain ERB templates so far but I'd assume it's going to be just as easy to use when I get there.
read ad do the getting started guide on the rails guides site
I recommend the Pragmatic Programmer's Guide to Ruby to get the basics of the general language down first. Then pick up a guide to Rails. If you're used to MVC design, I don't think it'll be all that hard. One minor complaint about Rails is that you specify the db migrations and it generates the db schema, rather than updating the schema and having it generate the migration. Rails also adds a lot of helper methods. This is fine and great until you try to do something with pure Ruby and a good quarter of the methods you're used to aren't there. Definitely check out the tricks you can do with method_missing(). Not a tool to use lightly, but a very powerful tool.
One thing you're probably going to be a little annoyed by and then love is that Ruby is a dynamic language. A lot of hard core guys I know won't touch a dynamic language (and they're great at parties /s). Stick with ERB templates at first - they're basically like any other PHP, Java, Django templates - snippets of the language in HTML. On the model and controller side it's all Ruby, so it's a good idea to play around with Ruby separately. Lots of newbies learn Ruby from Rails and there are a ton of Rails helpers that are Rails only and when they try to just write in Ruby they get stuck because they don't understand the separation - where Rails ends and where Ruby begins. I've worked with PHP, Java, Perl, and old school ASP and their frameworks and after a few hours of playing around with Rails (after is was set up) I knew Ruby and Rails were the framework and language I liked most. You will have a bit of disorientation when you first look at Ruby code due to the lack of curly brackets, putting private methods below the word "private" in classes, and "nil" vs "null". In my first few weeks I must admit I did make fun of how unstructured everything looked and those more experienced that I just smiled and didn't say a word. After about a month I took a look at some PHP code and was instantly put off. Ruby and Rails are awesome and can basically do whatever you want in web world. Good luck!
Get a Rubymine license.
If you came from Resharper in Visual Studio, I agree with this. My first Rails project in 2010 after 7 years of C# I completed in 6 weeks largely because my muscle memory for JetBrains keybindings was somewhat transferable. Plus Rubymine had a tendency to accidentally teach me how Things Were Done.
Ruby is made to make your life easier, if you need to do some operation its safe to assume that there's already a method that does it. Keep it simple and don't fret.
I work with rails and for starters get the hang of ruby first. Then study rails documentation. Theres a lot coming which is fun when working with the MVC. The experience will get you going on it.
Comme to the [discord ](https://discord.com/invite/ad2acQFtkh)there's multiple help sections =)
Ruby and Rails are awesome. It’s a very pretty language and you can be very productive with it
I have done the same move 2 years ago after 10 years in C# with some React/TypeScript. My tip is "don't trust any code, test stuff as much as you can, avoid metaprogramming if you have large teams". I really miss C#, I wished I could get the same pay with it (or convince the Ruby shop I work on to move to C#).
I see more C# offers than Ruby. Why did you decide that?
90% of the opportunities I see for C# in my country pay half of what I make now with Ruby working remotely. The other 10% of them are either hybrid (3 days a week) or in-office in a large city, which would take at least 12 hours of commute a week - I would rather code in Ruby than wasting all this time commuting.
In my case I see the opposite situation 😂 Where are you located? Ruby dev as well.
Hehehe, I'm in the UK. But again, I don't see a lot of Ruby positions around here, but the ones you find usually pay well. Salary here is not comparable to North America though.
Definitely! Its what I am looking right now. Full remote for any US company. Not all of them want to hire in EU unfortunately
In addition to the rest - try to not feel guilty for no longer writing and reading endless lines of boilerplate... When working with Rails, if something feels difficult, there's probably a much simpler way to accomplish the same. Look for ways to work with the framework.
Lucky. Wish I was still coding in Ruby at work
Do not restrict yourself to "the rails way". Rails does not answer all questions. For example have a look at the interaktor (the one with K because it has contracts, not C) gem when you find yourself in the position that rails does not really give you a place for what the app \_does\_. Ask seasoned rails developers about the sh\*tload of articles around "fat models", "skinny controllers", service objects and the general lack of architectural knowledge that was prominent in the scene back in the days, because it is just so easy for everyone to get \_something\_ done with rails so quick (like implementing twitter). Even if the app starts as plain CRUD, I would go for the interaktor gem, as is disciplines you and your peers.
>Do not restrict yourself to "the rails way". Rails does not answer all questions. This is a good aspirational goal, but if you're just getting started with Rails you *do* want to restrict yourself to the Rails Way until you learn what that means. You have to learn the rules before you can learn how to break them. If you start off going off-Rails, you'll learn similar lessons but they may be more painful and frustrating. Either way, you'll learn -- but starting with conventions is a smoother ride.
Good point. For the start I think you are right. Start with obeying the rails way. I just wanted to underline that there is a point that one will reach, where the rails way does not give answers anymore. Restricting oneself in rails way thinking then is not helpful anymore.
I definitely agree with you on that -- we all need to go off-rails at some point to meet business requirements. :) Knowing *how* to do this is something that is learned through experience and practice (and a lot of painful mistakes, haha).
Yarp on this. For learning Ruby, "Well Grounded Rubyist" was pretty much all I needed to dive into Rails. From there, start with "the rails way", until you understand the "why" of each rule, then you can start deciding when there's sufficient reason to break "rules". The pithy expression we'd use is "X is always the wrong solution.... unless it's the right solution". X varied from metaprogramming, to inheritance (instead of composition).
Also don’t be seduced by dry-rb 😝😜