Show HN: A Full-Stack Web Framework for Go

Glad to see progress in this space.

I couldn't find anything describing the paradigm used for the JavaScript frontend. From the video, it looks like things are fully server side rendered, i.e. no client side routing as-in SvelteKit or Next.js? Are the Svelte components hydrated+interactive after page load? In my experience so far with SvelteKit and other SSR+SPA frameworks, there are too many tradeoffs with hydrating then opting to CSR for subsequent navigation. I like the browser's built-in implementation of navigating between pages because it preserves things like mutations to the document and scroll position out of the box, with no additional JavaScript. If you collapse a comment in this thread, navigate back to the home page, then use your browser's back button, the comment you collapsed should still be collapsed. In my experience with SPA CSR, you'll need to track and restore the JavaScript state driving that collapse on your own (a combination of the window.history object and CSR hooks), since navigating back to the page is a full client side re-render of the page.

I've found Svelte+React have good support for TypeScript, especially for guaranteeing the types of props passed to components, are there plans to support this? With controllers in Go and Views in Svelte/React, is there any way to help with correctness of data passed as props to the Svelte components?

I only browsed for a wee bit, so take this with some salt, but it _looks_ like the framework is running a JS VM isolate alongside the Go server struct[1], which gets called with whatever script file is being rendered. Since it looks like the render files are, at least in the case of Svelte, individually compiled JS files that are SSR rendered via the V8 isolate, I _believe_ you're correct that there is no CSR (though there might still be JS-hydrated code if the Svelte component included something involving an interactive component).

I think the idea is to ingest a JS "template" and spit out the rendered HTML+JS, kind of like traditional SSR templates, but it could be possible to shoe-horn in an entire client-side router that gets initialized as a DOM object somewhere.

EDIT: I could be wrong, please correct me if so.

[1] https://github.com/rogchap/v8go

Browsing the runtime/view/ssr source code it appears to use esbuild (over the VM?) for rendering the svelte views while injecting the relevant code etc.

Nice sleuthing! Bud heavily relies on https://github.com/rogchap/v8go

Hey, excellent question.

You're correct that Bud server-side renders the Svelte files, then hydrates them on the client.

This is similar to what most other JS frameworks do, it works like this:

1. Create two builds: one for server, one for browser. This is done using ESBuild. This is actually done lazily upon request, similar to how a CDN like esm.sh would build JS to be imported. This will hopefully allow the build system to scale for larger apps. Vite was my inspiration here, but it's all done in Go.

2. V8 and the Svelte compiler are baked into the bud binary. When a request comes in, V8 evaluates the compiler running the server-built page and returns HTML. That's a mouthful, hopefully that makes sense.

Happy to go into more depth here or via email hi@livebud.com.

I should add that lazy builds only happen in development. In production, it's all bundled at once.

People interested in this might also find my project Pagoda [0] interesting. It's a full-stack web dev starter kit for Go, rather than a framework with any strict patterns or lock-in. It leverages Echo (web) and Ent (ORM) but they can be easily swapped out, if desired.

It also has HTMX [1] integration to create slick/modern UI behavior without writing any JS.

[0] https://github.com/mikestefanello/pagoda [1] https://htmx.org

Thanks for sharing @mstef9! I somehow missed this one in my research. I'm a huge fan of all efforts to make Go a serious contender for building full-stack web applications.

Ent is a nice choice for the ORM. For models, I'm planning to go with a combo of sqlc + xo. I want to tie the DB schema to your application.

I am not a fan of ORMs. SQLc seems good but I think EdgeDB looks highly promising although it is relatively new. Thought you might want to take a look at it :)

https://www.edgedb.com/

relevant hn thread https://news.ycombinator.com/item?id=30290225

Nice, with generics, some things that were hard are easier to do when it comes to polymorphism thus code re-use.

Go community has been pretty "anti-framework" (AKA "just use net/http" when it clearly doesn't solve every problems..., "don't put request scoped variables in context" when it's the very purpose of that interface...) and there was a lot of drama around some framework creators, unlike any other web language community I have seen by the way (remember Martini and the insane backlash? Iris and the constant drama, was that Iris, I don't even remember the name...) so it will be pretty interesting to see the reception for that framework.

One advice to the author, congrats but don't call your framework "framework", it's like the go community hate that word, just say "a set of useful libraries to help web development", it seems like euphemisms are easier to swallow for some...

Thanks for the comment!

I haven't actually used generics in any serious way yet. I haven't needed them. That being said, I'm happy they're in the language now and I'm really looking forward to seeing what the Go community comes up with during this period of experimentation.

I'm aware of the "anti-framework" ethos in the Go ecosystem. I think it comes from a good place, but there's room for other approaches. Go was created to build large-scale networked applications. The Go community deserves tools that are specifically designed for building web applications. Tools that are just as productive as Laravel, Rails and Next.js.

If this puts me at odds with some Go developers, I'm okay with that. We're probably just focused on different areas. Go is a big tent with plenty of room for different perspectives.

One thing I like about the code generation approach that Bud is taking is that there's more flexibility in the API design.

Need to break out of Bud's Controller conventions? Just pass a http.ResponseWriter and *http.Request and Bud will generate the glue code to wire everything up. You can go high or low-level depending on the problem that's in front of you.

I don't think this will appease the "just use the standard library" faction, but these kind of escape hatches will at least put a dent in their argument.

Any plans to implement something like Phonenix LiveView? I've never used Go, but from what I've read I suppose it should work really well given Go's concurrency model. (The name "Livebud" gave some hope as well.)

There is https://github.com/jfyne/live which is probably what you're looking for.

Starred!

I haven't looked too closely at LiveView yet. I did flip back and forth between going with the Hotwire approach (I guess inspired by LiveView?).

It was a tough call, but I ultimately decided to server-render JS. This thought-experiment helped:

• If Ruby could natively render Javascript, would they still choose the Hotwire approach? I concluded no. I don't see the reason to have multiple approaches (HTML over wire, Stimulus), when one solution would suffice. The one solution also happens to be way more familiar to today's frontend developers. I definitely didn't want to make another templating language.

Bud will eventually ship with it's own JS evaluator. Either through https://github.com/dop251/goja or through porting https://github.com/bellard/quickjs to Go (~25kloc of C)

This looks cool. I know effectively nothing about Svelte so some of these questions may be coming from that ignorance....but can you talk more about the embedded V8 instance (what's it doing?) and also what gets sent across the wire? Is it the usual HTML and JS or is there any server-side rendering going on? How big is the binary for the HN demo? What's the story for static assets like video or images?

I've started using Go at work so definitely interested in using this for side-project web apps to keep me in the Go mindset.

Thanks for your comment @ehaughee!

Great questions. I answered some above, so I'll copy some and then answer your other questions below:

>> what's it doing?

Bud server-side renders Svelte files, then hydrates them on the client. This is similar to what most other JS frameworks do, it works like this:

1. Create two builds: one for server, one for browser. Both are built using ESBuild. In development, builds happen lazily upon request, similar to how a CDN like esm.sh would build JS to be imported. This will hopefully allow the build system to scale for larger apps. Vite was my inspiration here, but it's all done in Go.

2. V8 and the Svelte compiler are baked into the bud binary. When a request comes in, V8 evaluates the compiler running the server-built page and returns HTML. That's a mouthful, hopefully that makes sense.

>> what gets sent across the wire?

What gets sent over the wire is HTML. That HTML then has a script tag which requests the client-side version of the page that's used to hydrate the HTML and make the page interactive.

>> How big is the binary for the HN demo?

I just checked the binary size and it's 47.6 MB. It's mostly V8 right now, but will definitely get larger as you add more assets. I haven't tested it yet, but hopefully you'll be able to rsync just the diffs to a server.

>> What's the story for static assets like video or images

You can add them in the public/ directory. There's documentation here: https://denim-cub-301.notion.site/Hey-Bud-4d81622cc49942f991...

---

Let me know if you give Bud a go on your side-project! Happy to go into more depth here, over email hi@livebud.com or on twitter @mattmueller

If you ever ship an Airflow integration, consider this an official request to call it Air Bud.

Ahahaha. I watched this movie 100 times as a kid. I cycled between Air Bud and Flubber.

> Build a Minimal Hacker News Clone in 15 Minutes with Bud

I started my programming career after following the Rails how to make a blog in 15min youtube video. Always a good choice.

Samesies! I'll be recording a weblog demo in one of the upcoming releases. Need migrations and database access first!

Fun fact: It took DHH a year after he first introduced Rails to get that famous weblog demo up. This stuff takes time :)

Wow is this like Go version of SvelteKit? Except without SSR so it serves only static files? I just thought about the same thing recently and I'm glad somebody made it! IMO Go is better fit for server backend than Node.js, especially with I/O.

Yeah, I'm glad these projects are emerging. I love svelte but I am not entirely convinced about how they push you towards sveltekit, especially in the docs. (I know there are adapters that allow you to use another backend but everything in the docs and examples push you towards NodeJS and sveltekit). It is as if react docs were written in a way that pushes you towards NextJS (they're from different companies so this is not the case, but I still think it is a good analogy).

I just don't want a NodeJS backend, all our team wants is to use a Golang backend which saves us ton of resources, which means less instances required, which means less $$$ (and Golang is awesome - performant, easy to read and write, easy to code concurrency, type safe without the hassle, built-in test suites/formatter/etc).

I'd love something like Laravel but for Golang+Svelte.

You're exactly who I'm building Bud for! I fit squarely in your camp :)

Please hit me up when you give Bud a try over email hi@livebud.com or on twitter @mattmueller. I'd love to hear what you think!

Yes, exactly. Even the creator of Node says so:

"I think Node is not the best system to build a massive server web. I would use Go for that. And honestly, that’s the reason why I left Node. It was the realization that: oh, actually, this is not the best server-side system ever."

Heavy computation still ties up the event loop in Node.js. We're just not talking about it as much because most people deploy to serverless functions nowadays which can spin up compute upon request. I love serverless and use it with https://standupjack.com, but it comes with it's own tradeoffs!

"I think Node is not the best system to build a massive server web. I would use Go for that. And honestly, that’s the reason why I left Node. It was the realization that: oh, actually, this is not the best server-side system ever."

But then he created deno....

Oh wow someone finally went ahead with the server rendered js in Go ! Looks great. I have been experimenting various ways to build web apps in Go: https://github.com/adnaan/gomodest-template. I have landed on pursuing one approach more deeply: server rendered html templates over websockets. Don’t have a lot of documentation right now but here are some examples: https://github.com/goliveview/examples.

Love seeing people experimenting in this space with Go! One of my favorite things about this HN post is everyone is coming out of the woodworks to share their ideas.

What's the advantage of rendering HTML templates over websockets? Is this similar to Hotwire where it sends you HTML fragments over websockets when you, for example, click on a button?

Like you said in another thread, there are two choices here. I took the other choice because I wanted to: 1. not build a new templating language 2. not maintain a custom server side renderer(v8). 3. Keep javascript to the minimum 4. Build for developers who know Go and maybe a little html/css. 5. No special html attributes. It should be just standard html/template i.e easy to delete the websocket stuff if it doesn’t work for you 6. Offer a view library instead of a framework. Go users are likely to be more open to adopting a library.

The approach is similar to hotwire except I only use stimulusjs and not use turbojs. turbojs doesn’t integrate well with html/template. In my approach, you can simply reuse the html templates you have already written with standard html/template package.

Sorry for the rambling, I haven’t gotten around to writing down all of it in a more structured way.

Congratulations on shipping. The demo looks great.

I see views and controllers in the documentation, but the only mention of model is that "model" is a reserved directory. What are your plans for models and persistence?

Thanks for your comment and question @onionisfruit. Top-notch handle too!

>> What are your plans for models and persistence?

I haven't worked out all the details, but it's going to be some blend of https://github.com/xo/xo and https://sqlc.dev/.

Design goals:

1. High-level, type-safe "ORM" that's generated from your database schema.

2. sqlc as a fallback to cover the more complex SQL queries in a type-safe way.

The hard part is going to figuring out how to support extending the ORM with your own custom methods, hooks, computed fields etc.

What do you think?

Your design goals look good to me. I think this will be one of the hardest parts to get right, so it's probably wise to save it for later so you can learn from implementing the rest of your design first.

First steps can be to use git diff and select what’s changed. Bulk of the heavy lifting will still be responsibility of ORM (sqlc). Later on this experience can be streamlined.

First of all - great work, thanks. Will follow the progress.

I have been working with Go professionally since 2015 and quite often it makes me feel frustrated due to lack of full-stack web frameworks.

I was thinking to do something like your project, but with focus to full SSR/zero-js. Lucky me, you started it first . Maybe be in some things I will prefer different approach, however, your project already released (and it's excellent) while mine only in prototype. After I read the documentation in your project it feels like you really stepped on a lot of minefields. Great job!

One thing is still bothering me though (or maybe I missed it in docs): how is Bud dealing with relative links? Very often JS writers forgetting about the situation when the application could be served under different root locations. Does Bud have helpers to construct relative URLs without relying on user-provided server url? (I made PoC for that - don't use it in production https://github.com/reddec/gin-template-manager/blob/eb09f4e8...)

@reddec, thanks for chiming in.

Having path helpers absolutely needs to happen, something like: https://guides.rubyonrails.org/routing.html#creating-paths-a.... I'll probably get custom routing up before that though because I want to make sure the design covers changes to routes.

There's a whole layer of generated JS/TS that will eventually be built out here.

Your site's DNS is currently not resolving. Should provide alternate install instructions for cases like this.

https://www.whatsmydns.net/#A/livebud.com

Truth. Website coming soon! This post exploded way more than I expected. Can't complain!

This is a very ambitious project and from the looks of it, it makes a ton of good decisions.

Thanks for the kind words @dgb23!

Great work.

The last bit about single binary is quite interesting. I could easily deploy app to my raspberry Pi without worrying about bundling things. I know Go can do this but it's nice that framework aligns with Go philosophy.

Bud on a raspberry pi sounds like a fun weekend project! Let me know if you give it a shot!

Congratulations on the launch!

I've been using Kenny Grant's Fragmenta[1] for past 3 years and I haven't had need for anything else because I like SSR with Go and aim to keep JS as minimal as possible. I assume you're trying to address the need of those who want a Go back-end but with modern JS front-end?

I hope that you get to answer the queries in other comments regarding the design decisions reg CSR & V8 while using SSR.

[1] https://github.com/fragmenta

Thanks for sharing! I'm quite surprised I didn't come across this project in my research.

> I assume you're trying to address the need of those who want a Go back-end but with modern JS front-end?

Yes, that's a big reason. Half of it's preference, the other part is that most of the JS frameworks don't provide a cohesive solution for sending emails, queues, scheduling tasks, etc. The backend is a larger part of your web app than most JS frameworks give it credit for.

Their stance is to outsource the backend to third-party services, but then you're stuck piecing all these SaaS's together. I like the approach Laravel takes here: provide interfaces for Mailers, Queues, Scheduled Tasks, File Storage, etc. then provide implementations for SQS, S3, Mailgun, etc.

Just answered the question about SSR + V8 above!

See also: Buffalo

https://gobuffalo.io

Yep, Buffalo and Bud share a similar ethos, with completely different approaches.

Bud uses modern FE frameworks and leans heavily into making code generation work well to give you type-safety and higher-level APIs.

Buffalo is farther along in the journey with database migrations, mailers, etc.

Unfortunately, I think Buffalo is no longer in active development. The main author left his own #buffalo Slack channel in gophers.slack.com.

I started with golang as the basis for my SaaS I've been building now for 2 years, the first version that shipped (and is still in production) is based on Go.

I personally don't find the go ecosystem very good for people who want to goto market as fast as possible, the libraries are less developed and you're going to have to build your own stack.

Bud and Buffalo seem like great developments, but your comment about the Buffalo one no longer being in active development would just totally suck if you had invested your time into building your SaaS on this.

I'm now using Ruby on Rails in the next version, and I couldn't be happier - maybe it's not as fast, but it certainly helps me ship features faster to customers!

>> I personally don't find the go ecosystem very good for people who want to goto market as fast as possible, the libraries are less developed and you're going to have to build your own stack.

Agreed, though when I do find a library it tends to just work. The challenge is finding the right library. There's no real reason for this though and I think with Go modules finally maturing and hopefully more web frameworks written in Go we're going to see an explosion in this space. Fingers crossed.

>> I'm now using Ruby on Rails in the next version, and I couldn't be happier - maybe it's not as fast, but it certainly helps me ship features faster to customers!

This is the spirit I like to see!

As someone who uses (and loves) Laravel, this looks very promising! I've been looking for an alternative to Laravel in NodeJS but found nothing at the same level of it. Looking forward to using Bud in an upcoming project (will be a REST API backend in Go).

dude this looks awesome! can't wait to dive into this and learn a bit more.

i come from a ruby, js and python background using frameworks like: react, django, rails, etc. always wanted to excuse to use GO and this might be it!

Thanks for the kind words @jacktheturtle! I like your handle. As the author of https://standupjack.com, all Jacks have a special place in my heart <3

Let me know when you give Bud a go! Feel free to email me at hi@livebud.com or hit me up on Twitter @mattmueller.

Very interesting, and using all of the latest tech. I was literally dreaming about combining Remix + Cloudflare Workers + Golang the other day. The only problem is Go would need to be compiled into WASM for that [0]. But this would provide one of the best experiences both in terms of development and performance/latency.

[0] https://community.cloudflare.com/t/support-golang-natively-f...

Last time I checked, there was a limit of 1MB or so for deployment wasm in cloudfare workers. Is that limit raised? Go binaries easily run on tens of MB with the default http library.

AFAIK that is still the limit. You can try and use TinyGo to reduce binary size but it's an uphill battle: https://nicholas.cloud/blog/continuing-hijinks-with-cloudfla...

It seems like fly.io is the best option right now for edge-optimized Go apps. My dream would be that Bud becomes something that Cloudflare simply can't ignore :D

Their reliance on V8 Isolates will make it difficult, but if they add Docker support at some point, then we're good. I don't see how Bud would work with WASM at the moment, but if someone gets it working, that would be a very pleasant surprise!

I'm more focused on getting Bud working well for deployment targets like Fly.io, Heroku, Lambda, K8s, Fargate and EC2.

This is really cool! I tried building something more basic than this a few years back, but this looks a lot more mature. I'll definitely be following and testing it out on a few small projects.

Thanks @dougbarrett! Let me know when you give it a shot! I'd be curious if there's anything your implementation that you'd like to see in Bud. Hit me up at hi@livebud.com or on twitter @mattmueller.

I'm experimenting with something similar as well, I'm curious - how do you solve HTTPS support since it's a built-in web-server?

Something like https://github.com/caddyserver/certmagic perhaps?

Yes! This might be the one I add to Bud! Seems like a more mature version of: https://pkg.go.dev/golang.org/x/crypto/acme/autocert

Yes, definitely use CertMagic. Let me know if you have any questions!

Not available yet. I did write the docs though, digging them up...

Created an RFC: https://github.com/livebud/bud/discussions/33. Feedback very welcome!

Hit me up on Twitter @mattmueller or over email hi@livebud.com. I'd love to hear what you're working on!

People interested in this might also find my project interesting: https://docs.goplaid.dev, https://github.com/goplaid/

Thanks for sharing @sunfmin!

I perused the documentation and I can tell a lot of thought went into this. I appreciate the simplicity and applaud all efforts to make Go a serious contender in the full-stack web framework space!

I thought of building my own framework then I remembered dealing with http headers, ssl, and http2

That's the beauty of using Go. All of this stuff is provided by the standard libraries.

I think using Svelte was a mistake. That being said, I'm pretty impressed with the effort here. Looking forward to seeing how this framework evolves. Cheers.

In the video it says they are frontend agnostic and will be adding multiple frameworks soon. React was mentioned specifically as coming soon.

To me I think the approach of Hotwire, LiveView, Django-HTMX etc. is more interesting for a Go framework, since websockets/async are baked into the Go language.

In other words, render the HTML in Go and ship the diffs to a small blob of JS running in the client over a websocket, instead of baking a whole React build into your server-side app. Much simpler toolchain this way, much easier to reason about.

I appreciate that this is a fairly different solution; one of the author’s explicit goals is that it should “Feel like using a modern JS framework”. Personally I’d rather have it “feel like I’m using Django / Rails”, except with most of the superpowers that were historically FE-framework-only.

Where nextjs kicks ass is that coding front end interaction (sans back end interaction) and doing interaction in response to server feels almost identical.

There is no “ugh ok … better set up react now” feeling to make say an interactive chart because it was always there.

Similarly there is no “ugh ok … better set up a backend now” feeling you get using create-react-app as it was always there.

There is almost no mental gear switch as you switch from front to back to front.

The only small negative is you need to be careful what that first “server side” render produces and what it can access. But that is also part of the magic, as you can fine grain control the initial flash of content. For example include the layout/menus. Or include a cached view of a list that then updates on final render.

It just feels so well integrated more than any other framework I have tried (like aspnet mvc or RoR for example).

It will be hard to beat: If you want to beat it in Go you need at least a good Go->JS transpiler so you can use the same language. But even then anything other than JS/Typscript means I need a mental modal of what the transpiler is doing. I don’t get a free pass on understanding JS or the DOM.

I just want plain HTML and some of {{ .These }}

You wish will be my command https://github.com/livebud/bud/discussions/8 :D

How realistic do you think it is that you'll be able to complete all the what-abouts everyone is proposing to you before you get burned out? Genuine question.

as well as sister comment, there is hugo, jekyll, etc.

fucking no. I want plain html.

? those things are as close the plain html without, well just editing html files yourself (which is fine!)

Agreed. I love Next.js and used it religiously for the first couple years. I'm not trying to beat Next.js or any framework. There's plenty of space in the web ecosystem for alternative solutions.

I hope is that Go <=> JS/Svelte won't be too much of a context switch for folks.

I'm not planning on innovating as hard in the frontend space as Next.js. I'll probably just stick with SSR, add support for pre-rendering and build up the client-side runtime with features like prefetching and client-side routing. If something really cool comes along, we'll see.

I'll instead focus on the area where Next.js neglects: backends. DB workflows, mailers, queues, scheduling, pubsub are all coming to Bud.

> I think using Svelte was a mistake

Why do you think that?

Thanks for your comment @dimgl!

As @drewry mentioned, we're aiming to be frontend-agnostic. Changing the renderer should be as simple as creating files with different extensions:

- index.svelte for Svelte

- index.jsx for React

- index.html for HTML

- index.gohtml for go/template

There's more information in this discussion: https://github.com/livebud/bud/discussions/8

Interesting project, good luck with it!

Can you elaborate how you were spoiled by Go and don't want to go back to writing PHP?

Sure, it's actually been a long journey since PHP.

I switched from PHP to Node about 11 years ago. I was probably one of the first 100 Node.js developers. My biggest contribution there was creating https://github.com/cheeriojs/cheerio.

Go spoils me because it "just works". The best way I can explain it is when I'm stuck on something in Go, it's almost always my bad, not something that Go is doing poorly. This is in contrast to the Node.js ecosystem where it feels like half of the problems I run into shouldn't be my responsibility.

I strongly relate to this post by Kevin Burke: https://kevin.burke.dev/kevin/one-year-of-node-js/. A lot has improved since this was written. We're finally over the ES Module vs CommonJS hump, Typescript has become the defacto standard, Babel is less used now and Webpack is effectively abstracted away. I still run into way too many problems with the ecosystem and the transition to Rust will make the ecosystem more complicated, not less.

My transition from Node.js to Go happened because I was working solo on https://standupjack.com/ and I kept running into issues with the message broker. It was using the most popular RabbitMQ client for Node, yet it was still super flaky.

About 6 years ago, I was chatting with TJ Holowaychuk and he kept singing Go's praises. One holiday I decided to rewrite just the message broker in Go. I got it into production in 3 days and didn't have anymore problems with it. That set me on the Go journey :)

The install link doesnt work. I wanted to view what it did before I ran it `livebud.com/install`

Sorry about that, fixed the installation script in all the places:

curl -sf curl https://raw.githubusercontent.com/livebud/bud/main/install.s... | sh

Looks awesome. livebud.com isn't resolving though so I can't install.

Sorry about that – fixed the installation script in all the places!

curl -sf curl https://raw.githubusercontent.com/livebud/bud/main/install.s... | sh

Great project, which UIKit do you use? Is it Tailwind or something?

Psst... I'm using https://www.untitledui.com. Please don't use it though, I don't want the whole web to look like UntitledUI ;)

Great effort in a great lang.

Constructively speaking:

Hacker culture could benefit from less frameworks to more low code/no code platforms (which is a space with more fertile ground)

I worried about this, but it seems like there's enough "framework supportors" in the comments!

Whoa, this looks insane!

_shameless plug_

I kind of made an almost similar thing can generate custom boilerplate for backend servers a while ago -> https://github.com/tompston/gomarvin

Looks super cool. Starred @tompston!

Thanks!

Cool project but I think building a full stack web framework in a language without features like operator overloading is a fool's errand.

Yes, Go has nice standard templating and HTTP serving libraries, and nice dependency management. These are all important features for a web framework.

No, it will never be productive as its competitors in the web framework space, because you simply cannot write expressions like `order.customer.region` that intelligently hit the database, because you can't override the dot operator. Instead you have to write unreadable crap like `regionController.Show(userController.Show(order.customer).region)` which is infinitely less "productive" than the former, for obvious reasons. Oh, you can `go generate` the *.Show definitions from a simple struct definition (or with 1.18 generics)? Too bad the final product is still unusable!

Use Go where it excels and connect it to your Ruby/Python/Typescript web backend over gRPC or HTTPS.

I see where you're coming from, but tbh the more I work on web backend code the more I disagree with this. I really think database interactions should be made explicit, even early on, rather than hidden by ORMs (or overriding a dot operator).

That's fine, but you are making a trade off with productivity here.

You have to be careful because sometimes productivity is just an illusion caused by accruing technical debt that you have to then pay for in time later. With database abstractions you often pay back this debt once the app reaches even slight complexity and you need to spend a lot of time understanding, debugging and refactoring query flows.

Writing backend with raw SQL: $10

Writing backend with a rigid, verbose, mostly type-safe ORM: $5

Writing backend with a terse, expressive ORM: $2.50

Adding type annotations to the previous code: $1

Thanks for your comment @pphysch!

So for authoring an app, I tend to agree with you. Languages like Ruby/Python/Typescript are probably faster to get something working.

I try to consider productivity holistically though. With Go, there's a lot less fussing with the tooling. I've also found Go saves a lot of time when onboarding new teammates. This is because of Go's intentional decision to be conservative with syntax. After all, most developer time is spent reading, not writing.

I respectfully disagree with your preference to split your backend up over gRPC or HTTPS. I prefer the approach Shopify takes to break up it's monolith: https://shopify.engineering/deconstructing-monolith-designin...

Bud will support something like this in the future.

> I try to consider productivity holistically though. With Go, there's a lot less fussing with the tooling. I've also found Go saves a lot of time when onboarding new teammates. This is because of Go's intentional decision to be conservative with syntax. After all, most developer time is spent reading, not writing.

Ultimately you will be teaching the framework, not the language, when it comes to large frameworks like this. Both Go and Python are easy to learn, but frameworks always add a lot of complexity.

> I respectfully disagree with your preference to split your backend up over gRPC or HTTPS. I prefer the approach Shopify takes to break up it's monolith:

I'm not arguing for this or that architecture cargo cult. I prefer monoliths too, but sometimes you really need distributed microservices and Go+gRPC is one of the most maintainable ways to do that.

Agree with you on both accounts!