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

An Ode to Ruby

blog.yboulkaid.com

Post reply on HN
Print view View original

171–180 of 204 posts

Re: An Ode to Ruby

#171

Post by pelasaco »

sam0x17 wrote: post #109
brigandish wrote: post #18

Earlier quoted context omitted.

I also took a while to get used to the typing in Crystal but once you do get it, it's worth the effort IMO. I occasionally still fire up Ruby but if I have anything more to do than a quick command-line command, I use Crystal, so many less problems.

Crystal is also my go-to for writing a quick script to do something.

The "you should be using Crystal" post is mandatory in any ruby thread. If everyone saying "yes, Crystal" were actually using Crystal, then:

a) they would see how far from "better ruby" is Crystal and

b) The Crystal community would be huge.

Re: An Ode to Ruby

#172

Post by jbverschoor »

jack_riminton wrote: post #170
midrus wrote: post #166

Earlier quoted context omitted.

I've already have had a good bunch of similar experiences at previous companies, where you hear all the time "we're moving away from the monolith". Problem is after you've been hearing for 5+ years, it probably means it will never go away. This particular company ended up with 100s of "microservices" around it, first in Elixir, then Elixir went out of favor so they started rewriting in Go, then came GraphQL so some m…

Sounds horrendously unproductive. Did they not measure the productivity?

You can’t unless you’re a decent programmer and only when you don’t think you’re 100x yourself

Otherwise it’s insanely hard to measure, bc people will come up with bs about how difficulty, complexity, test coverage, change management, dependencies.

People complain about car maintenance and the plumber, but programmers are worse.. you simply have to believe they’re working on magic… bc, we’ll, you wouldn’t understand right?

Re: An Ode to Ruby

#173

Post by midrus »

jack_riminton wrote: post #170
midrus wrote: post #166

Earlier quoted context omitted.

I've already have had a good bunch of similar experiences at previous companies, where you hear all the time "we're moving away from the monolith". Problem is after you've been hearing for 5+ years, it probably means it will never go away. This particular company ended up with 100s of "microservices" around it, first in Elixir, then Elixir went out of favor so they started rewriting in Go, then came GraphQL so some m…

Sounds horrendously unproductive. Did they not measure the productivity?

They measured it by the number of Jira tasks moved to "done".

The problem is, nobody is asking if those Jira tasks could have been avoided, or be a lot smaller if we were working on a more productive stack.

At the end of the day product managers get used to everything taking a lot of time and assume that's the only way (which, to be honest, in this context it is... as reached this point it is very difficult to go back).

And also, when productivity was discussed... there was always someone suggesting the problem was the current "legacy" stack (i.e. React, Elixir) and that we should instead move to this other new stack to be more productive (Go, Svelte) and there we go again...

Re: An Ode to Ruby

#174

Post by jack_riminton »

jbverschoor wrote: post #172
jack_riminton wrote: post #170

Earlier quoted context omitted.

Sounds horrendously unproductive. Did they not measure the productivity?

You can’t unless you’re a decent programmer and only when you don’t think you’re 100x yourself Otherwise it’s insanely hard to measure, bc people will come up with bs about how difficulty, complexity, test coverage, change management, dependencies. People complain about car maintenance and the plumber, but programmers are worse.. you simply have to believe they’re working on magic… bc, we’ll, you wouldn’t understand…

I hear what you're saying but surely it's a responsibility of the tech leadership (and even the non-technical leadership to some extent) i.e. simple questions such as 'surely it shouldn't take this long to ship a simple feature?' or 'why is everything so complex and ever-changing?'

Re: An Ode to Ruby

#175

Post by jbverschoor »

jack_riminton wrote: post #174
jbverschoor wrote: post #172

Earlier quoted context omitted.

You can’t unless you’re a decent programmer and only when you don’t think you’re 100x yourself Otherwise it’s insanely hard to measure, bc people will come up with bs about how difficulty, complexity, test coverage, change management, dependencies. People complain about car maintenance and the plumber, but programmers are worse.. you simply have to believe they’re working on magic… bc, we’ll, you wouldn’t understand…

I hear what you're saying but surely it's a responsibility of the tech leadership (and even the non-technical leadership to some extent) i.e. simple questions such as 'surely it shouldn't take this long to ship a simple feature?' or 'why is everything so complex and ever-changing?'

You don't understand, it's different today with all the micrososervices, packages, toolchain, kubernetes, docker, cloud, security, product management isn't clear, they change too often, it impacts all the code, we'll have to test everything again, this isn't php, compiling takes ages, we need faster machines with 128gb ram, it's complex because we need to be flexible, otherwise it will take ages when we want to add anything in the future, and we don't want to rewrite the whole codebase in the future, we spend all our time refactoring, the ops guys running the database aren't doing their job - that's why things are slow, not because we don't understand sql, the customer always makes user errors and we have to solve their problems, we need to do more peer programming,

bla bla bla bla bla.. It's just bs by incompetent and deceitful people

Re: An Ode to Ruby

#176

Post by midrus »

jbverschoor wrote: post #175
jack_riminton wrote: post #174

Earlier quoted context omitted.

I hear what you're saying but surely it's a responsibility of the tech leadership (and even the non-technical leadership to some extent) i.e. simple questions such as 'surely it shouldn't take this long to ship a simple feature?' or 'why is everything so complex and ever-changing?'

You don't understand, it's different today with all the micrososervices, packages, toolchain, kubernetes, docker, cloud, security, product management isn't clear, they change too often, it impacts all the code, we'll have to test everything again, this isn't php, compiling takes ages, we need faster machines with 128gb ram, it's complex because we need to be flexible, otherwise it will take ages when we want to add a…

Hahaha, you sound like my standup meetings XDD

Re: An Ode to Ruby

#177

Post by midrus »

jbverschoor wrote: post #172
jack_riminton wrote: post #170

Earlier quoted context omitted.

Sounds horrendously unproductive. Did they not measure the productivity?

You can’t unless you’re a decent programmer and only when you don’t think you’re 100x yourself Otherwise it’s insanely hard to measure, bc people will come up with bs about how difficulty, complexity, test coverage, change management, dependencies. People complain about car maintenance and the plumber, but programmers are worse.. you simply have to believe they’re working on magic… bc, we’ll, you wouldn’t understand…

I had a coworker which was the most useless developer ever, not able to do absolutely anything by himself and totally unsure about everything. But given it was a big company it was easy for him to "hide" and rely on just showing up for meetings, talking to everyone, etc.

Then he was the first one to ask for raises, despite he was earning way, way, way more than he should already.

Then one day he came complaining that the mechanic wanted to charge him X for fixing his car and that it was too much and how could that be possible, etc, etc.....I just couldn't believe it.

Re: An Ode to Ruby

#178

Post by brigandish »

pelasaco wrote: post #171
sam0x17 wrote: post #109

Earlier quoted context omitted.

Crystal is also my go-to for writing a quick script to do something.

The "you should be using Crystal" post is mandatory in any ruby thread. If everyone saying "yes, Crystal" were actually using Crystal, then: a) they would see how far from "better ruby" is Crystal and b) The Crystal community would be huge.

> they would see how far from "better ruby" is Crystal

Are you accusing us both of lying? How strange.

Re: An Ode to Ruby

#179

Post by ryanbrunner »

jack_riminton wrote: post #92
ryanbrunner wrote: post #78

Earlier quoted context omitted.

My latest job is at a place where we have an extremely 'old-school' Rails app. The vast majority of UI is server-rendered HTML, Javascript (at least that we wrote, we do use Turbo) is very, very minimal, and we're just one very large service. The previous place I was at was a microservice heavy (the count of services was almost on par with the number of developers) React and Node based application. I'm orders of magn…

I'm not surprised. I have a theory that there's a perverse incentive for startups to make their work more expensive and therefore more complicated. It's related to this quote by Paul Graham about funding: "VCs don't invest $x million because that's the amount you need, but because that's the amount the structure of their business requires them to invest. Like steroids, these sudden huge investments can do more harm t…

Yeah, I think it helps that we're very intentionally lean (we currently have just 2 engineers servicing about 100,000 paid subscribers, which is a bit too lean for comfort for me, but at least makes us think very hard about introducing complexity).

Re: An Ode to Ruby

#180

Post by jack_riminton »

ryanbrunner wrote: post #179
jack_riminton wrote: post #92

Earlier quoted context omitted.

I'm not surprised. I have a theory that there's a perverse incentive for startups to make their work more expensive and therefore more complicated. It's related to this quote by Paul Graham about funding: "VCs don't invest $x million because that's the amount you need, but because that's the amount the structure of their business requires them to invest. Like steroids, these sudden huge investments can do more harm t…

Yeah, I think it helps that we're very intentionally lean (we currently have just 2 engineers servicing about 100,000 paid subscribers, which is a bit too lean for comfort for me, but at least makes us think very hard about introducing complexity).

I’ve often thought that this would be a good constraint i.e instead of hiring a dev ops to migrate to a complicated AWS/k8 setup, it might be better to spend that wage on added Heroku costs to keep things simple
Post reply on HN