Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building GitHub with Ruby on Rails

github.blog

Post reply on HN
Print view View original

301–310 of 332 posts

Re: Building GitHub with Ruby on Rails

#301

Post by weaksauce »

CoffeeOnWrite wrote: post #294
weaksauce wrote: post #289

Earlier quoted context omitted.

there are many ways to lookup if something is defined or not instance_variable_defined? defined? are two common ones but if you are using something before defining it you are going to crash so that's definitely one way of distinguishing it. using fetch is another way to provide a default value to something that may have a nil value as a meaningful value.

Thanks for correcting me (sincerely) > but if you are using something before defining it you are going to crash so that's definitely one way of distinguishing it. Would you clarify? Like that was my point, casually using something where `nil` is a possible assigned value, or maybe the variable hasn't been defined, makes possible the (sadly common) category of bugs where the program does not crash, but proceeds as tho…

> Do you disagree and actually love the behavior of Ruby instance variables

yeah I wouldn't say i love it and i'm not sure why they did that but i imagine they had a reason for it originally. i would say it should have crashed instead of return nil as a default. they did tend to try to make the programmer happier and maybe they did it to that end but i don't see a large upside to it... not too much we can do about not using instance variables though... at the end of the day you just have to be a little more careful.

tests are a pretty good thing to have though and can catch this kind of error.

Re: Building GitHub with Ruby on Rails

#302

Post by weatherlight »

Rapzid wrote: post #292
weatherlight wrote: post #169

Earlier quoted context omitted.

It's usually I/O and dDB calls that are the bottle neck, not the speed of the language. Although, Ruby and be a bit of a memory hog,Ii did hear though, that this got better with the new YJIT in Ruby 3.x.

> It's usually I/O and dDB calls that are the bottle neck Not in my experience.

In a Ruby on Rails app?

Re: Building GitHub with Ruby on Rails

#303

Post by jeremyjh »

int_19h wrote: post #290
jeremyjh wrote: post #95

Earlier quoted context omitted.

These problems are always more common in server-rendered apps though, because front-end state is always a patchwork. And the Rails developers and community have a strong preference for this architecture.

The upside is that you can link just about anything in GitHub, and those links work consistently and point at the exact right content. This is much less common with SPAs.

I agree its a valid criticism of parts of the ecosystem, but a lot of people these days are using next.js, nuxt.js or sveltkit and those give you easy patterns to follow so that all those things work, basically for free. SPAs are better now than they were just a few years ago.

Re: Building GitHub with Ruby on Rails

#304

Post by ddyevf635372 »

upmostly wrote: post #3

I absolutely love Rails. I'll always remember back in 2010 catching the train to Waterloo station in London and seeing a huge sign overlooking the train tracks that read something like "We Need Rails Developers". Rails was such a huge part of my professional career. Now, 13 years later and I'm deep in the JavaScript ecosystem and have been for 8 years. The most exciting thing to come out of this ecosystem recently is…

Ember.js is nicely adopted the bests from Ruby on Rails, and Ember.js is still one of the best JavaScript framework out there, IMHO.

Re: Building GitHub with Ruby on Rails

#305

Post by [deleted] »

Alacart wrote: post #300
benatkin wrote: post #266

I've been using Codeberg, which uses Forgejo which is written in Go and is fast and light. Fantastic that GitHub has managed to wrangle so many lines of code in a language I don't care very much for, but my Samsung A53's browser is snappier without it :) Edit: to be fair, GitHub's has a hamburger menu that morphs to an X that I dearly miss. JK :P

Codeberg runs go on the frontend?

[deleted]

Re: Building GitHub with Ruby on Rails

#306

Post by wlonkly »

uptownJimmy wrote: post #218
djur wrote: post #212

Earlier quoted context omitted.

What do you mean by the app not being properly responsive? I've never had any problems with it on mobile.

It takes a significant chunk of time for any approvals or change requests to show up in the desktop UI, if ever, without just manual refreshing. This is not a niche observation, fwiw. It's a common complaint.

Ah, responsive as in "responds quickly", not responsive as in "renders appropriately for different viewports". We need more words!

Re: Building GitHub with Ruby on Rails

#307

Post by UlisesAC4 »

amrocha wrote: post #250
VWWHFSfQ wrote: post #150

Earlier quoted context omitted.

I observe the exact opposite. Server rendered UIs are far more often times up to date than client rendered apps.

I can't think of a single website that's real time and server rendered

I do not have examples with me. But anything built with Elixir Liveview will be server rendered and will also be real time, with some gotchas though.

https://github.com/phoenixframework/phoenix_live_view

Re: Building GitHub with Ruby on Rails

#308

Post by throwaway445232 »

andrewmutz wrote: post #178
skeeter2020 wrote: post #161

Earlier quoted context omitted.

this absolute is a little ignorant. For some products the scalability is the core competitive advantage. He can't engineer it in after the fact.

It's literally Donald Knuth: “The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.”

[flagged]

Re: Building GitHub with Ruby on Rails

#309

Post by a-user-you-like »

Rafert wrote: post #288
a-user-you-like wrote: post #265

Earlier quoted context omitted.

It’s… not ready for prime time. I’m optimistic that it can get there but right now the tooling is quite immature and the type system flexibility is not there for such a dynamic language as ruby.

Have you tried Tapioca ( https://github.com/Shopify/tapioca ) with Sorbet? Typing in general has ways to go sure, but I find this combination quite usable in my day to day.

Yes, but in dealing with parsing JSON in a dynamic way, we took a bunch of time to try to get things working elegantly and it didn’t go so well. Same with trying to set up a base class for a service object that could return any number of things.

Maybe I’ll check back in 3 years? But it seems to be A pet toy of Shopify, and for their needs.

Post reply on HN