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

Use Rails

jmduke.com

Post reply on HN
Print view View original

61–70 of 88 posts

Re: Use Rails

#61

Post by redblacktree »

alex_lav wrote: post #53
Geee wrote: post #46

For web apps maybe. What's the "boring" / productive stack for desktop apps? There's this weird paradox with programming languages which causes unproductive stacks to become more popular because programmers like "difficult" stuff and they also generate more online activity.

> What's the "boring" / productive stack for desktop apps? I've been trying to find it for years. I've started maybe 5ish desktop apps over the last decade and each time did the dance of "QT can't possibly be it...can it?" And then googled and tried everything I could find. In my experience it's all pretty bad. Unironically the best solutions I've found are either Unity/Godot or Electron.

It seems like you and parent are asking "What is the boring/productive stack for *cross-platform* desktop apps?" And the answer to that question is probably, as you say, something like Electron.

If you pick an OS, I think there are generally good answers. In Windows, it's .NET and C# with Visual Studio as your IDE. On OSX, it's Swift/ObjectiveC and AppKit, with XCode as your IDE. For Linux? idk, is it the year of the Linux desktop yet?

Re: Use Rails

#62

Post by neonsunset »

Geee wrote: post #46

For web apps maybe. What's the "boring" / productive stack for desktop apps? There's this weird paradox with programming languages which causes unproductive stacks to become more popular because programmers like "difficult" stuff and they also generate more online activity.

AvaloniaUI: https://www.avaloniaui.net/

Particularly so with https://github.com/AvaloniaUI/Avalonia.Markup.Declarative / https://github.com/wieslawsoltes/NXUI or https://github.com/fsprojects/Avalonia.FuncUI (F#) if you like declarative UI.

Re: Use Rails

#63

Post by spudlyo »

_heimdall wrote: post #57
spudlyo wrote: post #52

Earlier quoted context omitted.

> The specific data model was heavily relational and queries were very inefficient without foreign key support. I can't help but wonder if you're conflating the notion foreign keys (and the usefulness of having them be indexed) and foreign key constraints, which ensure data integrity at the expense of write performance. I have a narrow view of the performance of MySQL foreign key constraints and would be interested i…

I'm actually curious what the distinction is in your view. I've never really considered a column to be a foreign key when the constraint isn't used. Having a column that we give business logic context to is useful, and indexing a column that should contain values for another table is helpful for query speed, but at least in my opinion they really aren't foreign keys unless that constraint lives directly in the databa…

Excluding multi-column keys and joins, I'd describe a column as a foreign key in the context of a given query; i.e. when that query references a unique column in a JOIN condition on a related table. This differs from an explicit declaration of a foreign key constraint which provides all the useful referential integrity characteristics that you eluded to. If you said to me "Database Foo doesn't support foreign keys!" I'd take that to mean that you couldn't perform queries with joins.

In my experience, working on systems where foreign key constraints are liberally applied has been a net negative. Certain classes of DML statements (ON DELETE CASCADE I remember as being infamous) are certainly worse in performance than they otherwise might be. As an administrator I remember being repeatedly and painfully hamstrung by the inability to make arbitrary DB writes, which may momentarily violate strict data integrity, but are necessary for immediate practical reasons.

Obviously data integrity suffers without explicit constraints, but I'd rather work to backfill and/or clean up messy data than deal with a frustratingly rigid and poor performing system. I've worked on a number of large-scale MySQL database deployments at various tech companies, and I can't recall many, if any, that required or possessed pristine referential integrity. I can see why it's conceptually compelling, and I appreciate how automated tooling can generate very useful entity relationship diagrams if FK relationships are explicitly spelled out by constraints.

I think the "performance hit elsewhere" only happens given the assumption that strict referential integrity is a requirement, perhaps in a banking context or another where messy data simply cannot be tolerated.

Re: Use Rails

#64

Post by hakunin »

jupp0r wrote: post #59
hakunin wrote: post #56

Earlier quoted context omitted.

Http clients have pipelining for parallel requests that doesn't require threads. Database calls in Rails 7 now have `load_async`. You can still have other services, outside of Rails. Would that cover it? P.S. I'm a huge fan of Elixir/Phoenix, but didn't find the big need for concurrency in practice that Rails doesn't address somehow.

Yeah, there are small, niche solutions for solving concurrency for very specific use cases vs general support for this in the language. This doesn't help you when you are using the AWS SDK to make HTTP requests or when you want to hide latency of making a DB query and and HTTP request concurrently. I'm currently working on a large Rails App in my day job and lack of concurrency support is a major limiting factor for…

I understand your general point, but these solutions are not niche. They cover almost everything needed in web dev. The niche problems are the ones that arise at scale, which is when a business typically has the resources to solve them. (Hint: you don't have to solve them in Rails).

Large app / company challenges don't apply to new apps. Statements like "I wouldn't start a new app without a great concurrency story." or "I wouldn't start a new app without microservices." etc don't make sense, because new apps have different priorities (i.e. finding the fit, surviving, staying relevant).

I went through a phase of building Elixir/Phoenix apps for 3 years, thinking that I will switch permanently, but ended up coming back to Rails due to higher productivity in that stack. This was in 2015-2018, so maybe Elixir/Phoenix has gotten more ergonomic since. I'm not sure.

Re: Use Rails

#65

Post by axelthegerman »

omnimus wrote: post #41
axelthegerman wrote: post #24

Earlier quoted context omitted.

First time hearing of that, not sure it passes the "battle tested" sniff test here. No offense, might be a great framework but the gist of the blog post is A) what you know or B) Rails (if you don't know what to choose)

It might also mean that if you know JS then use AdonisJS. Which has become Rails of JS and is pretty old and mature too.

Wow I'm surprised I never heard of it - probably because it's boring and "old" for JS standards... And not backed by FAANG.

Thank you for sharing!

Though I couldn't find out any well known companies using it (re battle tested) but some might just not disclose which is fine.

Re: Use Rails

#66

Post by cushychicken »

sgeisenh wrote: post #45
cushychicken wrote: post #26

This article is just as valid if you ran :%s/Rails/Django/g. I use Django to run both www.fpgajobs.com and www.firmwarejobs.com and love it.

You may want to add some moderation features or otherwise increase friction for adding job postings for www.firmwarejobs.com because the very first listing that I see when I load the page is "Doing your mom".

HAH oh my god I hadn’t seen that yet.

Duly noted. Thanks for telling me.

Re: Use Rails

#67

Post by rco8786 »

jupp0r wrote: post #38
rco8786 wrote: post #30

Earlier quoted context omitted.

My company (large, well known tech co) actively instructs engineers to not use concurrency features, in a language that is known for having "great concurrency", unless they have a really, really good reason to. The vast, vast majority of workloads, especially at small startups, do not need a concurrency story outside of running N processes. Concurrency often gets in the way more than it helps unless you're actively t…

You never make outgoing HTTP calls, talk to a database or do any other IO? Genuinely curious.

Where did I say anything like that?

Re: Use Rails

#68

Post by _heimdall »

spudlyo wrote: post #63
_heimdall wrote: post #57

Earlier quoted context omitted.

I'm actually curious what the distinction is in your view. I've never really considered a column to be a foreign key when the constraint isn't used. Having a column that we give business logic context to is useful, and indexing a column that should contain values for another table is helpful for query speed, but at least in my opinion they really aren't foreign keys unless that constraint lives directly in the databa…

Excluding multi-column keys and joins, I'd describe a column as a foreign key in the context of a given query; i.e. when that query references a unique column in a JOIN condition on a related table. This differs from an explicit declaration of a foreign key constraint which provides all the useful referential integrity characteristics that you eluded to. If you said to me "Database Foo doesn't support foreign keys!"…

There's no perfect way to do anything in software, especially when it comes to a database. There are always tradeoffs.

There are times when I'd skip constraints and trust the application logic to handle it, sounds like you've run into those as well.

Personally I just have a really high bar when it comes to moving data integrity out of the db and into the app code. Stale data isn't usually my concern, I'm more concerned with how simply and clearly I can define the data contract with anything consuming the data.

When I can guarantee that a column marked as a foreign key will always be a valid foreign key, consumers aren't at risk of a whole class of errors when reading and writing data. Any one query may be marginally slower because the constraint is in the database and always executed, but I know for sure that I'll never have a frontend blowing up because they didn't realize the foreign key isn't really a foreign key, or a backend accidentally writing bad data because the foreign key value wasn't manually checked for validity before being written.

I can say that the larger the team I've been on the less I've seen issues with data integrity loving outside the database, assuming the project is architected well. When an entire team is dedicated to the database and another team, or teams, are dedicated to just the application logic that manages the db, it tends to be much better documented and tested.

Smaller teams have a tendency to along code around much faster and write fewer tests while still finding product-market fit. In those cases, database constraints are an absolute must in my opinion, app logic is just moving too quickly to have any faith in it maintaining data integrity and teams are often growing quickly enough that stuff falls through the cracks.

Honestly as long as someone on the project is seriously considering the tradeoffs, the team is in a pretty damn good spot regardless of what their needs and preferences end up being though!

Re: Use Rails

#69

Post by spudlyo »

_heimdall wrote: post #68
spudlyo wrote: post #63

Earlier quoted context omitted.

Excluding multi-column keys and joins, I'd describe a column as a foreign key in the context of a given query; i.e. when that query references a unique column in a JOIN condition on a related table. This differs from an explicit declaration of a foreign key constraint which provides all the useful referential integrity characteristics that you eluded to. If you said to me "Database Foo doesn't support foreign keys!"…

There's no perfect way to do anything in software, especially when it comes to a database. There are always tradeoffs. There are times when I'd skip constraints and trust the application logic to handle it, sounds like you've run into those as well. Personally I just have a really high bar when it comes to moving data integrity out of the db and into the app code. Stale data isn't usually my concern, I'm more concern…

Indeed, design is the art of balancing tradeoffs I think. I appreciate your argument for constraints being a guard rail for developers who are moving fast and occasionally breaking things. I think nowadays you can enable and disable the checking of constraints in MySQL dynamically without having to restart the database, which would have greatly reduced my past frustrations.

Nice to chat!

Re: Use Rails

#70

Post by alex_lav »

redblacktree wrote: post #61
alex_lav wrote: post #53

Earlier quoted context omitted.

> What's the "boring" / productive stack for desktop apps? I've been trying to find it for years. I've started maybe 5ish desktop apps over the last decade and each time did the dance of "QT can't possibly be it...can it?" And then googled and tried everything I could find. In my experience it's all pretty bad. Unironically the best solutions I've found are either Unity/Godot or Electron.

It seems like you and parent are asking "What is the boring/productive stack for *cross-platform* desktop apps?" And the answer to that question is probably, as you say, something like Electron. If you pick an OS, I think there are generally good answers. In Windows, it's .NET and C# with Visual Studio as your IDE. On OSX, it's Swift/ObjectiveC and AppKit, with XCode as your IDE. For Linux? idk, is it the year of the…

Yeah, I would categorize this response as

> In my experience it's all pretty bad.

Post reply on HN