undefined | Better HN

0 pointsmarcus_holmes3y ago0 comments

Go & Postgres on the backend, running on a baremetal server.

Because this is actually capable of handling a decent workload for really cheap compared to cloud.

There's a few tricky bits to do with logs and reporting, but the benefits outweigh the pain.

Vue on the frontend.

Last time I used BootstrapVue and it worked well. I'd want to re-evaluate that decision next time, have a look at some of the newcomers. I'm aware Bootstrap is now considered to be passe.

I really like the Vue philosophy and it pairs with Go nicely. Last time I ended up using ESBuild to actually build the Vue bundles from inside the Go server, which was interesting but I'm not sure I'd do that again.

0 comments

7 comments · 2 top-level

caeril3y ago· 4 in thread

This is the correct answer. It's quite shocking how many Django and Laravel answers there are in this thread. Performance and type safety appear to be completely irrelevant to HN.

You should take a look at Vite (https://vitejs.dev/) for a Vue development environment, if you haven't already.

lelanthran3y ago

> This is the correct answer. It's quite shocking how many Django and Laravel answers there are in this thread. Performance and type safety appear to be completely irrelevant to HN.

I was wondering about that actually.

Writing code in Python, Rails, etc is painful. A stupidly high percentage of the "unit tests" aren't testing logic at all, they're simply ensuring that incorrect types are handled properly.

And then I see comments like "well, my MVP can run very cheaply, a $100/m DO droplet" and wonder what on earth they are talking about - I had a $5/m DO droplet handling around 50k-60k concurrent TCP (not HTTP) connections, all serving data without any of the connecting devices timing out.

The devspeed differential between things like C#/Java/Go and Python/PHP/Ruby is large only at the very beginning of your project. When you're adding new features in every day, six months into the project, you're almost definitely going to be faster in some statically typed compiled language.

Seriously, using Django is likely to shave a week or so off the time; if that week matters so much then your expected lifetime for the product is what? Two weeks? Three?

I get it, in that if your MVP is timeboxed to (say) two weeks to alpha, then, yeah, those things that shave a week off make sense. But if your MVP is timeboxed to two weeks:

a) Tt's unlikely to be of much value to the consumer, b) Your competitors will appear two weeks after you first launch anyway.

I want to do a new product, and when judging each product idea I have, the largest issue is always finding the largest amount of value I can create/deliver in a particular timeframe (say, 3 months f/time).

If the value the product is providing can be done in a week with Rails, then there's not much motivation for me to develop that product - everyone with a week of leave or a month of weekends is going to have a clone out before I can even learn marketing.

If it's going to take 3 months regardless of the language, I have at least 3 months to build up a userbase, and do product refinement and fit.

RangerScience3y ago

> The devspeed differential between things like C#/Java/Go and Python/PHP/Ruby is large only at the very beginning of your project.

That's a massive hard-no for me. I generally only get faster the longer I get to work with a Ruby codebase, as I get to make it more and more into a DSL for the business situation. I never saw that happen with compiled languages; my speed tended to remain constant after the initial boot.

I know what you're talking about tho - it's the sharp knives + large team problem. The language doesn't maintain a standard of code for you, you (and your team) have to do that yourselves, and if you don't, things can very much get bad. If you're programming in a loosely typed language such that you're effectively having an explosion of types, you're suffering one of the more common downsides to typed languages and you're not using the common upsides to loose typing.

That said - when I'm working, the main difference I've seen with Ruby (and, to a lesser extent Python and JS) vs compiled is the iteration loop, particularly due to having a REPL console. Static languages have definitely made some gains there (looking at you, Scala REPL). Being able to drop into both any debug point in the program, as well as a console loaded with your code, makes certain explorative processes substantially faster.

1 more reply

0xblinq3y ago

No, it’s not, because we’re talking about an mvp and not about building an ultra high performance micro service.

And btw, there is no “correct answer” despite how much you like it.

There are many “correct answers” and a lot more wrong ones. Like using assembly code for building a CLI app or Go for an MVP.

marcus_holmesOP3y ago

thanks for the tip, I'll check it out :)

jamal-kumar3y ago· 1 in thread

I'm of a similar philosophy, but also because I'm not beholden to rushing a minimally viable product to the feet of some angel investors (Super allergic to that after a few experiences). I mean it's kind a a premature optimization if you just need to get a working example out there for people who like to see fast results, but if you've got the funding to start your own company just writing it properly for performance from the get go is the obvious thing to do.

I also choose a stack like that because it's what I've been mostly working in for a long while now and it's really productive (For me).

marcus_holmesOP3y ago

yeah, I get the same - I'm probably not going to get something up as fast as I would if I used Rails (though it's probably close - I've built so many sites on this stack that I know all the pitfalls and have a lot of the boilerplate down to copypasta now).

But this backbone can take a lot of experimenting with features easily, and is fast enough to forgive a lot of sins - I generally just don't have to worry/think about performance at all.

j / k navigate · click thread line to collapse

0 comments

7 comments · 2 top-level

caeril3y ago· 4 in thread

This is the correct answer. It's quite shocking how many Django and Laravel answers there are in this thread. Performance and type safety appear to be completely irrelevant to HN.

You should take a look at Vite (https://vitejs.dev/) for a Vue development environment, if you haven't already.

lelanthran3y ago

> This is the correct answer. It's quite shocking how many Django and Laravel answers there are in this thread. Performance and type safety appear to be completely irrelevant to HN.

I was wondering about that actually.

Writing code in Python, Rails, etc is painful. A stupidly high percentage of the "unit tests" aren't testing logic at all, they're simply ensuring that incorrect types are handled properly.

Seriously, using Django is likely to shave a week or so off the time; if that week matters so much then your expected lifetime for the product is what? Two weeks? Three?

I get it, in that if your MVP is timeboxed to (say) two weeks to alpha, then, yeah, those things that shave a week off make sense. But if your MVP is timeboxed to two weeks:

a) Tt's unlikely to be of much value to the consumer, b) Your competitors will appear two weeks after you first launch anyway.

If it's going to take 3 months regardless of the language, I have at least 3 months to build up a userbase, and do product refinement and fit.

RangerScience3y ago

> The devspeed differential between things like C#/Java/Go and Python/PHP/Ruby is large only at the very beginning of your project.

1 more reply

0xblinq3y ago

No, it’s not, because we’re talking about an mvp and not about building an ultra high performance micro service.

And btw, there is no “correct answer” despite how much you like it.

There are many “correct answers” and a lot more wrong ones. Like using assembly code for building a CLI app or Go for an MVP.

marcus_holmesOP3y ago

thanks for the tip, I'll check it out :)

jamal-kumar3y ago· 1 in thread

I also choose a stack like that because it's what I've been mostly working in for a long while now and it's really productive (For me).

marcus_holmesOP3y ago

But this backbone can take a lot of experimenting with features easily, and is fast enough to forgive a lot of sins - I generally just don't have to worry/think about performance at all.

j / k navigate · click thread line to collapse