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

321–330 of 332 posts

Re: Building GitHub with Ruby on Rails

#321

Post by ZephyrBlu »

teaearlgraycold wrote: post #297
ZephyrBlu wrote: post #239

Earlier quoted context omitted.

My experience with Sorbet has been way better than mypy with Python. Sorbet is way more useful.

That’s good to hear. I only ever tried Sorbet years ago when it was pretty new.

Oh that's interesting. You mentioned that Sorbet is dramatically worse than TS, but working with a modern RoR/React stack I don't have that opinion.

TS is a bit more flexible and expressive than Sorbet, but I find Sorbet very ergonomic even with strict typing. I rarely have to use T.let or T.must.

Sorbet's typed data structures like T::Struct and T::Enum are also great.

Re: Building GitHub with Ruby on Rails

#322

Post by djur »

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, I haven't used GitHub Desktop, just the website. That sounds annoying!

Re: Building GitHub with Ruby on Rails

#323

Post by iudqnolq »

danielheath wrote: post #286
nicoburns wrote: post #88

Earlier quoted context omitted.

Create-react-app isn't really a fair comparison. Create-react-app has ridiculous dependency bloat compared to the norm in the JS ecosystem because it includes every possible option rather than just picking one option in each category. Most serious project using React aren't using create-react-app.

I’m not really familiar enough to contradict you, beyond saying that - as an outsider - it has by far the most visibility in its space.

Funnily it's now outdated.

The brand new react docs don't even mention it: https://react.dev/learn/start-a-new-react-project

> We are currently leaning towards Option 5 ("Turn Create React App into a launcher"). The original goal of Create React App was to provide the best way to start a new React web app for the majority of React users. We like that repurposing it as a launcher explicitly communicates a shift in what we think is best for most new web apps, while at the same time leaving an escape hatch for the older workflows. Unlike Option 3, it avoids the perception that "creating a React app" is somehow deprecated. It acknowledges the reality that a bit of choice is needed, but there are now really great options to choose from.

https://github.com/reactjs/react.dev/pull/5487#issuecomment-...

Re: Building GitHub with Ruby on Rails

#324

Post by kirso »

skeeter2020 wrote: post #161
AeroNotix wrote: post #76

Earlier quoted context omitted.

Building for scale from day 0 is a recipe for disaster. You should've seen that coming.

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.

I think the authors above just meant that you don't know if your product will even get there so instead of over-engineering your stack and prepping for every possible scenario you'd take Just-in-time approach and conquer the problems when they come at you.

Re: Building GitHub with Ruby on Rails

#325

Post by mrwnmonm »

rst wrote: post #98
mrwnmonm wrote: post #84

All the cool kids left Ruby for Go, why are they still in that land?

Because they care more about getting things done than whether clout-chasers think they're "cool".

I get things done just fine with Go. And all the code is very clear. With ruby it is not, and a lot of ruby programmers may have a feel about how things work, while they are not really. They just enjoy the syntax. The book "The Ruby Programming Language" which written by the creator or ruby (I forgot his name) is full of "unfortunately", unfortunately this works this way now, unfortunately that works that way now.

And people definitly chose ruby because it was cool. So what you said should be applied to Ruby, not Go.

Re: Building GitHub with Ruby on Rails

#326

Post by mrwnmonm »

elif wrote: post #127
mrwnmonm wrote: post #84

All the cool kids left Ruby for Go, why are they still in that land?

Since they left ruby (2.0) raw rails performance improved by 75% (3.0) https://www.fastruby.io/blog/assets/images/RRBPerfHistory_72... Then in 3.2, ruby released YJIT which improved median rails response time by about 100% https://raw.githubusercontent.com/easydatawarehousing/ruby_m... It's kind of a golden era for rubyists that stuck it out. Beautiful maintainable code that hits C performance for many tasks.

Didn't know that, thanks for the update. Actually, now I want to give it a try, remembering my old romantic days.

Re: Building GitHub with Ruby on Rails

#327

Post by 0xblinq »

mscccc wrote: post #287
doodlesdev wrote: post #268

Earlier quoted context omitted.

GitHub could've used Hotwire [0] but instead they decided to grow a buggy immature in-house solution. [0]: https://hotwired.dev/

Even with my kindest interpretation, I cannot find how this comment adds anything to the conversation. It’s also incorrect. Hotwire was released after GitHub’s internal UI framework (which is quite impressive!) was created. Attributing some UI bugs with their choice of framework is a massive oversimplification of the problem.

> Hotwire was released after GitHub’s internal UI framework

Any source for this?

My understanding is that it was extracted for building Hey from the use cases the 37signals people had on other products such as basecamp, etc.

Re: Building GitHub with Ruby on Rails

#328

Post by papito »

q845712 wrote: post #249
WirelessGigabit wrote: post #209

Earlier quoted context omitted.

You MUST have an insane amount of test coverage to trust something like this to Ruby. I'm new to Ruby, with 13 yoe as a SW engineer. Personally, I find it a very hard language to master. Writing tests often feels like I'm settings variables left and right without seeing them being used in the current context. But that then happens to be part of the let() way in rspec. Now you might say: why use rspec? I inherited thi…

I've written in python, C++, Ruby, and Go. I hear you on the compilers, and I do miss them at least a little whenever I don't have them. But my goodness, there's really something fun in Ruby. I think it shines in smaller codebases, situations where you can have some hope of understanding 90% of everything that's going on as a single developer (and honestly part of the sales pitch of microservices is that you know the…

How many environments are really out there where developers blissfully work in their microservices silo? There are a lot of happy promises and sunny-day theories, but in reality it's an awful mess, and you can't really get anything done without understanding the services hairball.

How are you supposed to fix a bug in your own service if you don't know how to set up a specific permutation of services locally in order to reproduce it?

Re: Building GitHub with Ruby on Rails

#329

Post by papito »

faeyanpiraat wrote: post #67
dagorenouf wrote: post #61

I built my startup 4 years ago with a combination of react + aws + gatsby + hasura. I thought this would be great for performance and scale. Fast forward to today, I spend at least 2x as much time to code a feature than if I had just stuck with a simple rails stack, and the scale I imagined never happened. Now rebuilding everything with rails so I can ship faster and focus on growing the product, not making engineeri…

Considering most of the times the startup at hand will fail anyway and the planned scale will not happen, building the initial architecture to be "web scale" is a perfect example of YAGNI. I had a similar experience, and it was a great lesson.

We used to write software for pretty high-traffic systems using what is now underpowered CPUs, less RAM, and antiquated databases. It should be easier now, NOT harder. Most of development I see today is resume-driven and not based in any pragmatism.

Re: Building GitHub with Ruby on Rails

#330

Post by mscccc »

0xblinq wrote: post #327
mscccc wrote: post #287

Earlier quoted context omitted.

Even with my kindest interpretation, I cannot find how this comment adds anything to the conversation. It’s also incorrect. Hotwire was released after GitHub’s internal UI framework (which is quite impressive!) was created. Attributing some UI bugs with their choice of framework is a massive oversimplification of the problem.

> Hotwire was released after GitHub’s internal UI framework Any source for this? My understanding is that it was extracted for building Hey from the use cases the 37signals people had on other products such as basecamp, etc.

Yes that’s correct.

I was saying it came after, meaning GitHub could not have used it since it didn’t exist. :)

Post reply on HN