14 ms·

The best Go framework: no framework?

205 points by roblaszczak 4y ago

pst 4y ago
It's funny, as someone proposing frameworks make sense in IaC (Terraform in my case), how the framework/no-framework topic apparently never gets old.
yevpats 4y ago
Yeah, I think it might be a good option for experienced devs and it can also turn into a rabbit hole for junior folks. No silver bullet and everything depends on what you are trying to build. But yeah this discussion never get's old :)
FpUser 4y ago
I do not use Go but I share the approach. I avoid using frameworks until I have no other reasonable option.
topicseed 4y ago
Been writing Go for my own pet projects and some production side projects for two years. Often resorted to "small libraries" like Chi, or SQL query builders. Since GitHub Copilot, I ditched SQL query builders as all the scanning and repetitive work is handled nearly immediately. I also ditched Chi and handle routing myself. Same for logging. The issue is spending time doing things that took one line before with a framework (e.g., parsing URL path params). But it's actually satisfying.
- heywire 4y ago
  What does a typical handler look like in this scenario (url path params). I usually end up using Gorilla mux for this, but standard library for everything else.
  - topicseed 4y ago
    I create a simple func for each handler to parse params. Most urls params are properly structured as /resources/{resourceID}/subresources/{subresourceID}. So I can essentially create a map[string]string by splitting slashes and going 0 = key, 1 = value, 2 = key, 3 = value, etc. If a handler uses a different structure like /resources/{resourceID}/{subresourceD}, I will have the func specifically handle that case. Some ways may work better but this works for me and it's not magical, and I tend to touch that code once and never again so it's then out of the way, all in a file.
greencheeses 4y ago
Go having a standard library that is so good for building simple services is what sets it aside from all the other languages that have come out in the last while in the same space. It has a great collection of community libraries but I so rarely need to fall back to them as I can usually cobble together whatever I need to pretty easily just using the standard library. It makes it easy to get started on a project as there is no time i need to spend thinking about the tools im going to use, its just provided all of them for me, in mostly high quality, relatively easy to use implementations of most basic things.
- euroderf 4y ago
  Agreed. But doesn't it seem sometimes as though some modest improvements here & there in the stdlib would have a big payoff in making it immensely more productive ?
  - greencheeses 4y ago
    I agree, there are some ergonomic improvements that could definitly be made, something like sqlx would be nice for example
    - majewsky 4y ago
      What's the value of having sqlx in the stdlib? The only reason I could see is a social one, not a technical one (discoverability). The Go devs did in the past include external libraries in the stdlib, the most significant one being "golang.org/x/context" moving to "context". This was a very important inclusion because it meant the stdlib could start offering context-aware APIs, and it was a signal to the rest of the ecosystem that the context API is stable forever and other packages can make their APIs context-aware without risk of future breakage. With sqlx, none of these issues arise: the main compatibility interfaces between different SQL libraries (particularly to the drivers providing support for different RDBMS) are already present in the stdlib.
- cbrogliato 4y ago
  Having such a large standard library to me smells like you can't build one as nice as that with the language. Since it missed generics until recently I can figure out why the STD library is that good and large and why there weren't that much framework. I've used Java before it had generics too.
ocdtrekkie 4y ago
I dislike frameworks and prefer to avoid any dependency but the standard library, but coming from PHP, learning to write web apps in Go feels like being expected to write your own web server. Not sure how I feel about it yet.
lloeki 4y ago
Echoes back to Three fallacies of dependencies by Blake Mizerany https://www.dotconferences.com/2014/10/blake-mizerany-three-fallacies-of-dependencies https://www.dotconferences.com/2014/10/blake-mizerany-three-... Of course the only absolute truth is that there are no absolute truths, so no point of being dogmatic to the extreme. Still, with experience I came to realise that dependencies carry their own weight, which has to be balanced with the weight of bespoke implementation (which can span the whole spectrum from "obviously" to "NIH")
lakomen 4y ago
Same old topic. I use gin. It's not perfect, especially streaming (EventSource) is broken. But the rest has actual hand on solutions. ctx.SecureJSON() Not a single one of the other packages has something like that. Keyword: JSON hijacking protection. Yes it's still a thing.
- trinovantes 4y ago
  Isn't it just prepending "while(1);" to your responses? If that's all you need, it seems like a dependency overkill
  - ansc 4y ago
    I think this is the thing with (web) frameworks. Are you really going to remember that? And actually do it? And work around and build those other gnarly things for CSRF, SSRF and XSS? If you only need to serve happy-case HTTP, for sure you're better of without a framework. At least my experience without using a framework is that it's a tad annoying when you need the extras. And requires a lot deeper understanding of things as you don't abstract it away which is good for learning, but might be cumbersome for actually shipping things.
    - trinovantes 4y ago
      For security/safety sensitive tasks, you should be using checklists e.g. [1] so you don't need to remember. Pilots use pre-takeoff checklists to reduce chances of human error. Likewise, you shouldn't assume the framework will give you proper defaults. [1] https://github.com/0xRadi/OWASP-Web-Checklist https://github.com/0xRadi/OWASP-Web-Checklist
- puika 4y ago
  Is broken streaming a thing? A quick search shows some issues with gin's own gzip middleware. Don't know if that's also the case behind a proxy with gzip middleware and gin's disabled. Looking at the newest code I also noticed you can exclude paths from gin's gzip middleware, if a proxy is not an option.
sidlls 4y ago
This is one of the better things about Go and its community: eschewing frameworks like this. Having an ecosystem of in-house libraries tailored to your products' use cases is not the same as developing an "ad-hoc framework". Where I work, we have several languages deployed in our fleet of microservices. A couple have frameworks, and these frameworks are "try to do it all" types, complete with dependency injection and layer upon layer of abstraction intended to help engineers avoid "needless" boilerplate or what have you. They're slow and difficult to debug/troubleshoot for any case that isn't anticipated by the frameworks, and even sometimes then. No, thank you. Microservice architecture has its own problems, but these problems tend to be easier to reason about than the services themselves that use the frameworks.
- sylens 4y ago
  I've spent the last year exploring different languages and ecosystems than the one I'm most comfortable in (Python) and what you said absolutely rings true. When you're picking up C#/.NET, there's this almost overwhelming amount of terminology you see getting tossed around that takes you a while to see how it all fits together. Now that I'm exploring Go, I'm surprised at how many books/learning materials are basically surveys of the features of the language, and then it's basically - "Start building!" "Introducing Go" is just 100 pages for example.
  - osigurdson 4y ago
    The number of times that the asp.net "startup" has changed is completely ridiculous. It all started from a very bad place with a startup class that is stupidly called by reflection, forcing the developer to use trial and error to discover what methods should be used. Thankfully, they have finally done away with this but it is sad that they ever allowed these horrible patterns in the first place. Another abysmal area is SignalR (clearly developed by children).
    - GiorgioG 4y ago
      Everyone makes mistakes, even framework/compiler teams. I mean look at how long it took Go to get generics. Huge mistake IMO. I still dislike what ASP.NET did with their startup, and I don't think it's improved much. The minimal startup is just a bunch of magic (where did the var 'args' come from? Just magic.) Framework folks are people, they try new things, it doesn't always stick.
nixpulvis 4y ago
Was that just nearly 2,000 words and not a single fragment of Go in a post about Go?
davidkell 4y ago
For junior developers reading this: frameworks are great, learn to love them, they will save you much time and stress when shipping real products.
- jpgvm 4y ago
  However maybe also learn to love a language that embraces them at the same time so you don't come away with a poor experience because of only trying a language that has poor frameworks (Go, JS/TS, etc). Definitely try something like Python + Django, Ruby + Rails, Java/Kotlin + Spring to get a feel for what a mature framework can really do. Then if you find you still don't like frameworks and the style of programming associated with them then sure, find a home in one of the ecosystems that are more inclined to roll it your own way. Frameworks certainly aren't for everyone but using bad frameworks and then pretending all frameworks are therefore bad is highly prevalent among more recent developers. Try the good ones and then make up your own mind.
  - davidkell 4y ago
    Agreed and well put. Lack of a decent Rails/Django option for JS/TS is part of the issue IMO, since that ecosystem is so popular atm. I also wonder if you have to get burned a few times rolling your own and that's just part of the journey :)
    - dopeboy 4y ago
      I’m really surprised there isn’t a solid batteries loaded framework in JS. There’s just no way I could use node + express over Rails / Django
      - za3faran 4y ago
        Could you elaborate on some of the things you find express lacking? Asking because the team is evaluating using it.
        4y ago
euroderf 4y ago
Tired: Framework stuff. Wired: Browser WASM (from Go source) that accepts commands over websockets to modify & render the DOM. (Is this "client hydration"?) Tight integration with htmlx (for pizazz + ruthless efficiency) and Javascript (for rich text editors + other advanced widgetry). This may require full Go, if tinygo continues to lack reflection support.
- dmitriid 4y ago
  > Wired: Browser WASM (from Go source) that accepts commands over websockets to modify & render the DOM. Why WASM? For what purpose? Just to do that? You don't need WASM for that: see Phoenix LiveView
shp0ngle 4y ago
A lot of people use go for microservices, and then you kind of need a framework. And all the proto + protoc + protoc-gen-go + grpc + swagger/openapi + json-grpc-gateway dance is… not easy to understand at first
- dottedmag 4y ago
  Well, maybe the problem is in gRPC and Protobuf?
bauerd 4y ago
You also get to implement stuff like CSRF protection, cookie signing, anti session fixation, etc. You also lose out on community contributions because you are your own community now. You also better have stellar internal documentation because onboarding developers is going to be a pain otherwise. 99% of cases people are better off using a boring conventional web framework and implementing their actual business logic on top of it.
- dinkleberg 4y ago
  I agree with you that not using a framework requires you to think more about these things, but if you’re using a routing library like chi or gin there are plenty of libraries adding such functionality to them.
  - bauerd 4y ago
    Yes you can put in the work and zip a bunch of libraries up into your own home-brew framework. But I doubt it's time worth spent for most teams.
    - valenterry 4y ago
      I think that actually depends on the programming language. With golang, such a task is much harder because integration is more errorprone and requires more plumbing, e.g. due to missing generics (until recently). For other languages that is different though.
  - nprateem 4y ago
    So then you have your own framework again, but with no coherent docs.
- infecto 4y ago
  This has always been the sticking point for me when I am wanting to try out new frameworks. When starting a new project I used to get excited on the idea of using a lean barebones framework, only to realize later on the boring bits that I had to figure out/implement or rely on some third-party library that may not stay up to date with best security practices in the future.
Spiwux 4y ago
I couldn't disagree with this any harder. I'm a Java BE Engineer who joined a Go shop, so I have a direct comparison. Both are microservice environments for products of similar complexity. It is insane to me how much less productive Go is for your average microservice enterprise environment. I'm sure it's great for systems programming or tool development. I like the simplicity. But the ecosystem is borderline useless for larger scale enterprise-y service landscapes. GRPC and Protobuf are overengineered and underdocumented, a lot of things are seemingly optimized for Google's specific needs. We are more people, we are more experienced and have a decent engineering culture. Yet we're definitely less productive than the last average, traditional Java Spring Enterprise team I've been in. "Circumventing" a framework restriction (which rarely happens if you stick to good practices) is MUCH less effort than building things yourself from scratch.
- zackkitzmiller 4y ago
  Then don't use GRPC and Protobufs. I've had exactly the opposite experience building enterprise software with Go.
  - deleted 4y ago
    [deleted]
- pleb_nz 4y ago
  That is my thoughts as well. It sounds like this would lead to more reinventing the wheel than I'd like to see in a product like a web app/service.
- asim 4y ago
  This 100%. I think the people largely arguing for no frameworks have no idea what real productivity looks like at large scale engineering orgs. This mostly means you are not handcrafting libraries. There is a dedicated team who manages platform tooling including the frameworks/SDKs you use. Product teams may contribute to that but they will mostly be consumers. I always equate this to car manufacturing. I am not buying a kit car, I am not buying a hobby car, I'm buying a well engineered product from a large scale manufacturer. Frameworks and platforms fall into this category, especially for enterprises. I think it's fine for small teams not to use frameworks, and maybe 200 person engineering orgs are made up of many small teams who just want to agree on a protocol rather than shared framework/platform but once the scale starts to increase you really need to start tightening up and implementing some better standards. People constantly talk about not being Google, well let me tell you the people scale is all the same, the amount of legacy infra is all the same. If you haven't peaked into the depths of the messy multi-decade enterprise you have no clue. Your 4 year old company that you joined 6 months ago is no comparison to something with a legacy of 3 decades with 2k+ engineeers scattered across a disparate org trying to modernise in the cloud or whatever comes next. Full disclosure: I work on https://micro.dev https://micro.dev - a framework for Go
osigurdson 4y ago
I can't tell if the article is recommending not using 3rd party packages or simple not to get caught up in an opinionated framework. I agree that opinionated frameworks don't can be problematic as they don't compose but can't agree that with the statement that 3rd party libraries are bad. This is basically build vs buy argument favouring the build side. A more measured approach would be to avoid 3rd party packages that aren't very popular or are not particularly active.
- dinkleberg 4y ago
  It is recommending the latter. Instead of using an opinionated framework like buffalo or revel, they are recommending either using the standard lib or single purpose libraries like Chi for routing.
deleted 4y ago
[deleted]
bsaul 4y ago
The graphic in OP summerize it pretty well. If all you need is something quick, and you don’t expect (or currently have the budget) to scale it a lot in the close future, then using a framework may very well be the best solution.
sneak 4y ago
I literally have a medium-sized repo full of boilerplate required for a normal go web service. It will be nice to one day factor it out into something I can import versus having to simply copy the template repo. The stdlib is great but it doesn't give you sessions, orm, csrf, sass/minification, good templating, embedding, etc out of the box. You have to paste in lots of boilerplate to get those working. https://git.eeqj.de/sneak/gohttpserver https://git.eeqj.de/sneak/gohttpserver It's WTFPL so feel free to cannibalize it in whole or part to save time. master is a bit outdated as I am moving it over to use uber/fx: https://git.eeqj.de/sneak/gohttpserver/pulls/17 https://git.eeqj.de/sneak/gohttpserver/pulls/17
can3p 4y ago
This article makes an assumption: you know how to build the application better than framework developers do, which is not the case in general. Django docs are tremendous and you probably do not need most of it but in reality many of them cover real-world cases and do it in a good way. Sure, it may be a question of minimal code to implement it in go, but you have to know that you need this specific feature and you need to know how to implement it. I've been doing small projects with go for a while and while I enjoy doing it in go (I like the predictability that types bring to me and the fact that I do not need to go through the tomes of docs to figure out something) I still feel every single time that I'm reinnventing the wheel. The task is simpler with SPAs since all you need from go is a json api, but if you want to build something complete with htmx you'll have to deal with many questions yourself. E.g. - orm / db access - Signup / login flow - Emails - Static assets versioning - template helpers - CSRF? - Routing and reverse routing - Page structures (you want to have the same field to look up page title, right? - Partials for your templates (how do you do form validation in a nice and generic way) There is a lot of stuff like this. None of this is impossible to solve, it's quite easy in most cases actually, but it adds up and as I said, you have to know how to do it write One thing for sure is that if you implement the concepts yourself you don't need to abstract them away too much (or maybe you do if you want to reuse all the nice things in your next project). For me the most compelling thing is types and the fact that I'm not dealing with django/laravel magic with long stacktraces that are meaningless to me, but I still return to thinking about doing next project with rails from time to time, just because I've implemented form validation hundred times already. One good point about frameworks is about limitations - they are there and this is something that's quite hard to overcome at times. Rails framework does things the certain way and if you want to do it differently you have to fight with the framwork or make an attempt to push things to upstream which I'm pretty sure is not the main goal of your project. (edit: made list a list)
- tyingq 4y ago
  I would also add things like http cache headers, http compression, retries + backoff, mapping to http response codes, etc.
GiorgioG 4y ago
The problem with not using established frameworks for building apps is that you'll wind up creating your own ad-hoc 'framework'. As your app (and the framework) evolves it becomes more feature-rich, it will be difficult for people to ramp up/understand. They won't be able to Google/Stackoverflow for problems they're having because nobody else on earth is using their 'framework'. Then people will want features you've not implemented or thought about, so now you need a framework committee to decide what's in, what's out. No thanks. Give me ASP.NET Core, Django, Spring Boot for a development organization with more than 1 developer.
deleted 4y ago
[deleted]
eternalban 4y ago
OP doesn't ask the question that would have saved a somewhat straw-man general position on frameworks: Why is it that Go lacks the familiar 'widely adopted framework'? OP could have written about the two different types of code reuse and why one lends itself better to Go: Libraries vs Frameworks. Java has magical frameworks because we have a magical JVM and first class (as in baked into the language) metadata utilities at the language level. Java can define & load new objects at runtime. Loose coupling? My god, this is as loose as it gets. In Go, you'll need composition of processes to accomplish the same thing. Code reuse at Go happens at the library and networked-but-loosely-coupled component levels. This covers a lot of territory but not things that are, in effect, 'containers of components'. If you are in component oriented code sharing territory, Go is the wrong language. With Go, a framework can't do all the magical stuff the other kids' FWs do, but you get most of the pain of using frameworks. It is a language issue. in general: Partially realized abstractions place greater demands on the language and its runtime capabilities than do partially realized composition (e.g. apis).
oxplot 4y ago
> The easiest way is to start by putting everything into one file. You can start simple, defer some decisions, and evolve your project with time. This is something that most even senior developers don’t grok. Default so called project starter scripts of the node world don’t help either. The more structure you build before you know wth you’re doing, the more difficult you’ll make life for yourself down the line when you inevitably have to refactor code.
PaulHoule 4y ago
There's something to say for getting in the habit of delivering microprojects with minimal dependencies and tooling. I do most of my Python work with PyCharm on a Windows machine, frequently with poetry as a dependency manager, but lately I was writing a script for burning DTS-audio CDs in a single step on my Linux server (has the optical drive) and made the decision to only use the Python standard library and do it all in a single file I edit with vim. The result is 150 lines of code that spin like a top. I went through a phase of doing all the problems on HackerRank and learned to love "single-file Java" and discovered that you can do almost anything in a single file except declare a public class (if it is all in one package, default access is all you need.) It's not the usual way I do things but I like Java a lot more knowing I can write simple programs without maven, an IDE and all of that.
- hu3 4y ago
  After years of working with arguably ever-engineered projects where everything is an interface and the actual implementation is hidden so far up the callstack that half the time was spent searching for the file that needed to be changed, I came to like down-to-earth, YAGNI (You aren't gonna need it) mentality. This includes sometimes keeping things in a single file when sensible. Sure your domains aren't so pure anymore because you've cut some layers of indirection and simplified things. But the cognitive load is so much smaller. Such a pleasant delight to work on "dumb" code. As always, it depends on the size of the project. But my threshold for keeping things simpler has certainly shifted towards trying to keep things simpler when possible.
- samsquire 4y ago
  Most of my code I write is small projects where all the code is in one or two files I don't enjoy working on enterprise codebase where there's thousands of files that do very little and the code is refactored so hard that you need to jump between 20 classes to understand how it all works and fits together. Leetcode solutions are usually single file solutions. My programming language and interpreter are more than one file though. A parser that lexes and creates an AST and an interpreter class and a class for each kind of AST node that do codegen. I could probably hast used a single file and inner classes.
Chirag 4y ago
Yeah, Having built a web application serving 100K+ users in Go. First 2/3 weeks were spent on making sure we were a framework. So new Modules could be added. New external calls were abstracted and also dealt with lot of circular dependency. This was all fun and learning, but wouldn't mind having a "Flask" or "Express" version of a Golang framework which took care of all the boilerplate out of the box. We did try some existing solution to no avail like Tiny etc. But ended up building a non-framework framework anyways especially to support new features/modules and new devs coming it.
- petepete 4y ago
  Would https://gofiber.io/ https://gofiber.io/ work for you?
  - Chirag 4y ago
    Will checkout thanks.
karxxm 4y ago
Having no framework comes with having no documentation. If you select a framework and work in the same scope as the framework intends to, then you can onboard new engineers much more easily by telling them: We are working as the framework defines, look into the documentation and you will understand the basic architecture of our software. Of cause, devs can maintain their own documentation, but I guess this usually is something that is not done very well. My personal experience: As soon as a company started their software without a framework, it became a huge mess. While onboarding, I observed very bad architectural decisions and even very severe security issues. I'd say, only go with no framework, if you are experienced enough to technically create an own (good) framework. From my observations, going without a framework was usually a decision done by young engineers.
deleted 4y ago
[deleted]
kokizzu2 4y ago
I like fiber the most, but can use anything like echo (and past companies use only httprouter, gin, httpkit, etc) as long as the codebase not overly layered, I guess any framework is fine only need to split to 3 kind of layer: 1. serialization/transport layer (codegenerated) -- framework goes here 2. business logic layer (one that unit tested), only input struct, transform/process, and output struct (DTOs) 3. persistence/3rd party layer (codegenerated too), add additional go source code file for things that wasteful to be codegenerated, only input struct, basic persistence methods or network calls, and output struct (DAOs) goes here if using gRPC layer 1 already codegenerated, so only need to fill layer 2 with business logic and codegenerating layer 3.
- mattgreenrocks 4y ago
  Your comment made me realize I'm not truly anti-framework, I'm anti-sell-your-architecture-to-the-framework, which most frameworks want you to do. Problem is, many MANY people do not have sufficient experience to know the perils of putting the framework in charge of the architecture, so they do just that, and decry any other approach as "Java-esque." (That label says an awful lot in and of itself.) The impact of this choice often doesn't become apparent until much farther down the road. Then you start getting into the weird cottage industry involving brittle hacks with DBs/frameworks in order to delay setting them up so that you can run unit tests in under ten minutes. It's ridiculous. Part of the blame lies with the devs: refusing to take responsibility for your architecture means you are at the whim of the framework. And the framework devs are also at fault for pushing the lie that you merely need to write the absolute bare minimum of code and everything else will be taken care of.
  - majewsky 4y ago
    I think you still are anti-framework by any reasonable definition of the word. Library = your code calls it, Framework = it calls your code.
    - mattgreenrocks 4y ago
      Limiting the scope of what is exposed to the framework keeps you in control of the architecture. This is probably why I find almost every framework deeply unsatisfying. Gin, in Golang, doesn't bother me much for whatever reason, but it doesn't seem to aspire to the same number of things as other frameworks.
mattpallissard 4y ago
The main beef I have with frameworks isn't actually with the framework. It's teams fork lifting / re-writing to the "next best thing" to fix a problem instead of polishing what they have. You wind up with a perpetual revolving door of immature implementations instead of incrementally improving something with known flaws.
bayesian_horse 4y ago
Go's standard library already provides functionality that is provided by "frameworks" in other languages. So "no framework" isn't actually a thing. Also what I like most about Django and Django Request Framework is that it saves me so much writing and reading in almost every case. Not sure how you're supposed to achieve that without something that looks like a framework or how writing ten times the amount of code is more sustainable and maintainable.
epolanski 4y ago
I love writing no framework/no lib backends in nothing but Node.js and TypeScript with some fp-ts and io-ts on top of that. Node's standard libraries (http, fs, etc) give you already enough to work with. Sure, you're going to have to re-implement plenty of things (e.g. file serving, which anyway isn't great in node), and many other things but there's plenty of pros: - you can always understand how things work and change them to suit your use cases. That's just not the case with external tools. Good luck figuring out the codebases or even be able to build them locally - it's much better for educational purposes to understand how things fit together and are supposed to work The biggest con: security. Libraries and frameworks likely patch many vulnerabilities you didn't even know existed. This alone pushes me off from this approach and instead I fall back to some bloated framework, but security is important. The second biggest con: performance. You're likely gonna do plenty of performance mistakes if you don't have a good knowledge of how Node really works.
jurschreuder 4y ago
Go without a framework and just the standard lib is already about equivalent to Python with FastAPI. All you need to do is add a logger of choice, which will be different based on your architecture (one / multiple servers) anyway. You might want to add user auth, which is often an external server anyway. Maybe you want some boilerplate / codegen tool to add/remove/select objects from a database. But I personally don't use that because it's hard to optimize performance with those tools and SQL is already a good tool for it imho, don't need an extra abstraction. In summary, all you need is the standard lib and maybe 3 external libs in Go, because it was made in a time when an api was already pretty standard. In other languages you need way more extra stuff to create an api, so the need for a framework is greater.
metaltyphoon 4y ago
This post embodies the majority of the Go community. “Let’s reinvent every single possible wheel”
SergeAx 4y ago
> Python has Django and Flask, Ruby has Rails, C# has ASP.NET, Node has Express, and PHP has Symfony and Laravel. Go is different: there is no default framework. And this is the root of most problems described by author. If I start project on Python - I know that I can take Django and use it for at least 4 next years, spending one sprint a year tops to migrate to next LTS version. In Go only standard library currently gives me that kind of reliability.
- majewsky 4y ago
  I'm maintaining about half a dozen microservices written in Go. In my experience, the Go community is very good about providing backwards compatibility. In fact, I'm very strict about keeping on top of my dependencies because "spend a sprint to upgrade to the next version" is a process smell to me, no matter how seldomly it occurs. I have my Renovate bot set up to send PRs every Friday. Most of them are on "automerge on test success" at this point, then they soak in QA for the weekend and I send them to prod on Monday. The only trouble I can recall is with updating Kubernetes libs (let's not open that can of worms right now) and in some cases I have to manually intervene when libs upgrade from `interface{}` to using generics, but that's a refactoring that I gladly do.
albertopv 4y ago
It seems to me too many don't know how big is Spring framework. You can do basically everything with OOTB starter. Enterprise projects are a breeze to develop with Spring Boot.

205 points by roblaszczak 4y ago

pst 4y ago

It's funny, as someone proposing frameworks make sense in IaC (Terraform in my case), how the framework/no-framework topic apparently never gets old.

yevpats 4y ago

Yeah, I think it might be a good option for experienced devs and it can also turn into a rabbit hole for junior folks. No silver bullet and everything depends on what you are trying to build. But yeah this discussion never get's old :)

FpUser 4y ago

I do not use Go but I share the approach. I avoid using frameworks until I have no other reasonable option.

topicseed 4y ago

Been writing Go for my own pet projects and some production side projects for two years. Often resorted to "small libraries" like Chi, or SQL query builders. Since GitHub Copilot, I ditched SQL query builders as all the scanning and repetitive work is handled nearly immediately. I also ditched Chi and handle routing myself. Same for logging. The issue is spending time doing things that took one line before with a framework (e.g., parsing URL path params). But it's actually satisfying.

heywire 4y ago
What does a typical handler look like in this scenario (url path params). I usually end up using Gorilla mux for this, but standard library for everything else.
- topicseed 4y ago
  I create a simple func for each handler to parse params. Most urls params are properly structured as /resources/{resourceID}/subresources/{subresourceID}. So I can essentially create a map[string]string by splitting slashes and going 0 = key, 1 = value, 2 = key, 3 = value, etc. If a handler uses a different structure like /resources/{resourceID}/{subresourceD}, I will have the func specifically handle that case. Some ways may work better but this works for me and it's not magical, and I tend to touch that code once and never again so it's then out of the way, all in a file.

greencheeses 4y ago

Go having a standard library that is so good for building simple services is what sets it aside from all the other languages that have come out in the last while in the same space. It has a great collection of community libraries but I so rarely need to fall back to them as I can usually cobble together whatever I need to pretty easily just using the standard library. It makes it easy to get started on a project as there is no time i need to spend thinking about the tools im going to use, its just provided all of them for me, in mostly high quality, relatively easy to use implementations of most basic things.

euroderf 4y ago
Agreed. But doesn't it seem sometimes as though some modest improvements here & there in the stdlib would have a big payoff in making it immensely more productive ?
- greencheeses 4y ago
  I agree, there are some ergonomic improvements that could definitly be made, something like sqlx would be nice for example
  - majewsky 4y ago
    What's the value of having sqlx in the stdlib? The only reason I could see is a social one, not a technical one (discoverability). The Go devs did in the past include external libraries in the stdlib, the most significant one being "golang.org/x/context" moving to "context". This was a very important inclusion because it meant the stdlib could start offering context-aware APIs, and it was a signal to the rest of the ecosystem that the context API is stable forever and other packages can make their APIs context-aware without risk of future breakage. With sqlx, none of these issues arise: the main compatibility interfaces between different SQL libraries (particularly to the drivers providing support for different RDBMS) are already present in the stdlib.
cbrogliato 4y ago
Having such a large standard library to me smells like you can't build one as nice as that with the language. Since it missed generics until recently I can figure out why the STD library is that good and large and why there weren't that much framework. I've used Java before it had generics too.

ocdtrekkie 4y ago

I dislike frameworks and prefer to avoid any dependency but the standard library, but coming from PHP, learning to write web apps in Go feels like being expected to write your own web server. Not sure how I feel about it yet.

lloeki 4y ago

Echoes back to Three fallacies of dependencies by Blake Mizerany https://www.dotconferences.com/2014/10/blake-mizerany-three-fallacies-of-dependencies https://www.dotconferences.com/2014/10/blake-mizerany-three-... Of course the only absolute truth is that there are no absolute truths, so no point of being dogmatic to the extreme. Still, with experience I came to realise that dependencies carry their own weight, which has to be balanced with the weight of bespoke implementation (which can span the whole spectrum from "obviously" to "NIH")

lakomen 4y ago

Same old topic. I use gin. It's not perfect, especially streaming (EventSource) is broken. But the rest has actual hand on solutions. ctx.SecureJSON() Not a single one of the other packages has something like that. Keyword: JSON hijacking protection. Yes it's still a thing.

trinovantes 4y ago
Isn't it just prepending "while(1);" to your responses? If that's all you need, it seems like a dependency overkill
- ansc 4y ago
  I think this is the thing with (web) frameworks. Are you really going to remember that? And actually do it? And work around and build those other gnarly things for CSRF, SSRF and XSS? If you only need to serve happy-case HTTP, for sure you're better of without a framework. At least my experience without using a framework is that it's a tad annoying when you need the extras. And requires a lot deeper understanding of things as you don't abstract it away which is good for learning, but might be cumbersome for actually shipping things.
  - trinovantes 4y ago
    For security/safety sensitive tasks, you should be using checklists e.g. [1] so you don't need to remember. Pilots use pre-takeoff checklists to reduce chances of human error. Likewise, you shouldn't assume the framework will give you proper defaults. [1] https://github.com/0xRadi/OWASP-Web-Checklist https://github.com/0xRadi/OWASP-Web-Checklist
puika 4y ago
Is broken streaming a thing? A quick search shows some issues with gin's own gzip middleware. Don't know if that's also the case behind a proxy with gzip middleware and gin's disabled. Looking at the newest code I also noticed you can exclude paths from gin's gzip middleware, if a proxy is not an option.

sidlls 4y ago

This is one of the better things about Go and its community: eschewing frameworks like this. Having an ecosystem of in-house libraries tailored to your products' use cases is not the same as developing an "ad-hoc framework". Where I work, we have several languages deployed in our fleet of microservices. A couple have frameworks, and these frameworks are "try to do it all" types, complete with dependency injection and layer upon layer of abstraction intended to help engineers avoid "needless" boilerplate or what have you. They're slow and difficult to debug/troubleshoot for any case that isn't anticipated by the frameworks, and even sometimes then. No, thank you. Microservice architecture has its own problems, but these problems tend to be easier to reason about than the services themselves that use the frameworks.

sylens 4y ago
I've spent the last year exploring different languages and ecosystems than the one I'm most comfortable in (Python) and what you said absolutely rings true. When you're picking up C#/.NET, there's this almost overwhelming amount of terminology you see getting tossed around that takes you a while to see how it all fits together. Now that I'm exploring Go, I'm surprised at how many books/learning materials are basically surveys of the features of the language, and then it's basically - "Start building!" "Introducing Go" is just 100 pages for example.
- osigurdson 4y ago
  The number of times that the asp.net "startup" has changed is completely ridiculous. It all started from a very bad place with a startup class that is stupidly called by reflection, forcing the developer to use trial and error to discover what methods should be used. Thankfully, they have finally done away with this but it is sad that they ever allowed these horrible patterns in the first place. Another abysmal area is SignalR (clearly developed by children).
  - GiorgioG 4y ago
    Everyone makes mistakes, even framework/compiler teams. I mean look at how long it took Go to get generics. Huge mistake IMO. I still dislike what ASP.NET did with their startup, and I don't think it's improved much. The minimal startup is just a bunch of magic (where did the var 'args' come from? Just magic.) Framework folks are people, they try new things, it doesn't always stick.

nixpulvis 4y ago

Was that just nearly 2,000 words and not a single fragment of Go in a post about Go?

davidkell 4y ago

For junior developers reading this: frameworks are great, learn to love them, they will save you much time and stress when shipping real products.

jpgvm 4y ago
However maybe also learn to love a language that embraces them at the same time so you don't come away with a poor experience because of only trying a language that has poor frameworks (Go, JS/TS, etc). Definitely try something like Python + Django, Ruby + Rails, Java/Kotlin + Spring to get a feel for what a mature framework can really do. Then if you find you still don't like frameworks and the style of programming associated with them then sure, find a home in one of the ecosystems that are more inclined to roll it your own way. Frameworks certainly aren't for everyone but using bad frameworks and then pretending all frameworks are therefore bad is highly prevalent among more recent developers. Try the good ones and then make up your own mind.
- davidkell 4y ago
  Agreed and well put. Lack of a decent Rails/Django option for JS/TS is part of the issue IMO, since that ecosystem is so popular atm. I also wonder if you have to get burned a few times rolling your own and that's just part of the journey :)
  - dopeboy 4y ago
    I’m really surprised there isn’t a solid batteries loaded framework in JS. There’s just no way I could use node + express over Rails / Django
    - za3faran 4y ago
      Could you elaborate on some of the things you find express lacking? Asking because the team is evaluating using it.
      - 4y ago

euroderf 4y ago

Tired: Framework stuff. Wired: Browser WASM (from Go source) that accepts commands over websockets to modify & render the DOM. (Is this "client hydration"?) Tight integration with htmlx (for pizazz + ruthless efficiency) and Javascript (for rich text editors + other advanced widgetry). This may require full Go, if tinygo continues to lack reflection support.

dmitriid 4y ago
> Wired: Browser WASM (from Go source) that accepts commands over websockets to modify & render the DOM. Why WASM? For what purpose? Just to do that? You don't need WASM for that: see Phoenix LiveView

shp0ngle 4y ago

A lot of people use go for microservices, and then you kind of need a framework. And all the proto + protoc + protoc-gen-go + grpc + swagger/openapi + json-grpc-gateway dance is… not easy to understand at first

dottedmag 4y ago
Well, maybe the problem is in gRPC and Protobuf?

bauerd 4y ago

You also get to implement stuff like CSRF protection, cookie signing, anti session fixation, etc. You also lose out on community contributions because you are your own community now. You also better have stellar internal documentation because onboarding developers is going to be a pain otherwise. 99% of cases people are better off using a boring conventional web framework and implementing their actual business logic on top of it.

dinkleberg 4y ago
I agree with you that not using a framework requires you to think more about these things, but if you’re using a routing library like chi or gin there are plenty of libraries adding such functionality to them.
- bauerd 4y ago
  Yes you can put in the work and zip a bunch of libraries up into your own home-brew framework. But I doubt it's time worth spent for most teams.
  - valenterry 4y ago
    I think that actually depends on the programming language. With golang, such a task is much harder because integration is more errorprone and requires more plumbing, e.g. due to missing generics (until recently). For other languages that is different though.
- nprateem 4y ago
  So then you have your own framework again, but with no coherent docs.
infecto 4y ago
This has always been the sticking point for me when I am wanting to try out new frameworks. When starting a new project I used to get excited on the idea of using a lean barebones framework, only to realize later on the boring bits that I had to figure out/implement or rely on some third-party library that may not stay up to date with best security practices in the future.

Spiwux 4y ago

I couldn't disagree with this any harder. I'm a Java BE Engineer who joined a Go shop, so I have a direct comparison. Both are microservice environments for products of similar complexity. It is insane to me how much less productive Go is for your average microservice enterprise environment. I'm sure it's great for systems programming or tool development. I like the simplicity. But the ecosystem is borderline useless for larger scale enterprise-y service landscapes. GRPC and Protobuf are overengineered and underdocumented, a lot of things are seemingly optimized for Google's specific needs. We are more people, we are more experienced and have a decent engineering culture. Yet we're definitely less productive than the last average, traditional Java Spring Enterprise team I've been in. "Circumventing" a framework restriction (which rarely happens if you stick to good practices) is MUCH less effort than building things yourself from scratch.

zackkitzmiller 4y ago
Then don't use GRPC and Protobufs. I've had exactly the opposite experience building enterprise software with Go.
- deleted 4y ago
  [deleted]
pleb_nz 4y ago
That is my thoughts as well. It sounds like this would lead to more reinventing the wheel than I'd like to see in a product like a web app/service.
asim 4y ago
This 100%. I think the people largely arguing for no frameworks have no idea what real productivity looks like at large scale engineering orgs. This mostly means you are not handcrafting libraries. There is a dedicated team who manages platform tooling including the frameworks/SDKs you use. Product teams may contribute to that but they will mostly be consumers. I always equate this to car manufacturing. I am not buying a kit car, I am not buying a hobby car, I'm buying a well engineered product from a large scale manufacturer. Frameworks and platforms fall into this category, especially for enterprises. I think it's fine for small teams not to use frameworks, and maybe 200 person engineering orgs are made up of many small teams who just want to agree on a protocol rather than shared framework/platform but once the scale starts to increase you really need to start tightening up and implementing some better standards. People constantly talk about not being Google, well let me tell you the people scale is all the same, the amount of legacy infra is all the same. If you haven't peaked into the depths of the messy multi-decade enterprise you have no clue. Your 4 year old company that you joined 6 months ago is no comparison to something with a legacy of 3 decades with 2k+ engineeers scattered across a disparate org trying to modernise in the cloud or whatever comes next. Full disclosure: I work on https://micro.dev https://micro.dev - a framework for Go

osigurdson 4y ago

I can't tell if the article is recommending not using 3rd party packages or simple not to get caught up in an opinionated framework. I agree that opinionated frameworks don't can be problematic as they don't compose but can't agree that with the statement that 3rd party libraries are bad. This is basically build vs buy argument favouring the build side. A more measured approach would be to avoid 3rd party packages that aren't very popular or are not particularly active.

dinkleberg 4y ago
It is recommending the latter. Instead of using an opinionated framework like buffalo or revel, they are recommending either using the standard lib or single purpose libraries like Chi for routing.

deleted 4y ago

[deleted]

bsaul 4y ago

The graphic in OP summerize it pretty well. If all you need is something quick, and you don’t expect (or currently have the budget) to scale it a lot in the close future, then using a framework may very well be the best solution.

sneak 4y ago

I literally have a medium-sized repo full of boilerplate required for a normal go web service. It will be nice to one day factor it out into something I can import versus having to simply copy the template repo. The stdlib is great but it doesn't give you sessions, orm, csrf, sass/minification, good templating, embedding, etc out of the box. You have to paste in lots of boilerplate to get those working. https://git.eeqj.de/sneak/gohttpserver https://git.eeqj.de/sneak/gohttpserver It's WTFPL so feel free to cannibalize it in whole or part to save time. master is a bit outdated as I am moving it over to use uber/fx: https://git.eeqj.de/sneak/gohttpserver/pulls/17 https://git.eeqj.de/sneak/gohttpserver/pulls/17

can3p 4y ago

This article makes an assumption: you know how to build the application better than framework developers do, which is not the case in general. Django docs are tremendous and you probably do not need most of it but in reality many of them cover real-world cases and do it in a good way. Sure, it may be a question of minimal code to implement it in go, but you have to know that you need this specific feature and you need to know how to implement it. I've been doing small projects with go for a while and while I enjoy doing it in go (I like the predictability that types bring to me and the fact that I do not need to go through the tomes of docs to figure out something) I still feel every single time that I'm reinnventing the wheel. The task is simpler with SPAs since all you need from go is a json api, but if you want to build something complete with htmx you'll have to deal with many questions yourself. E.g. - orm / db access - Signup / login flow - Emails - Static assets versioning - template helpers - CSRF? - Routing and reverse routing - Page structures (you want to have the same field to look up page title, right? - Partials for your templates (how do you do form validation in a nice and generic way) There is a lot of stuff like this. None of this is impossible to solve, it's quite easy in most cases actually, but it adds up and as I said, you have to know how to do it write One thing for sure is that if you implement the concepts yourself you don't need to abstract them away too much (or maybe you do if you want to reuse all the nice things in your next project). For me the most compelling thing is types and the fact that I'm not dealing with django/laravel magic with long stacktraces that are meaningless to me, but I still return to thinking about doing next project with rails from time to time, just because I've implemented form validation hundred times already. One good point about frameworks is about limitations - they are there and this is something that's quite hard to overcome at times. Rails framework does things the certain way and if you want to do it differently you have to fight with the framwork or make an attempt to push things to upstream which I'm pretty sure is not the main goal of your project. (edit: made list a list)

tyingq 4y ago
I would also add things like http cache headers, http compression, retries + backoff, mapping to http response codes, etc.

GiorgioG 4y ago

The problem with not using established frameworks for building apps is that you'll wind up creating your own ad-hoc 'framework'. As your app (and the framework) evolves it becomes more feature-rich, it will be difficult for people to ramp up/understand. They won't be able to Google/Stackoverflow for problems they're having because nobody else on earth is using their 'framework'. Then people will want features you've not implemented or thought about, so now you need a framework committee to decide what's in, what's out. No thanks. Give me ASP.NET Core, Django, Spring Boot for a development organization with more than 1 developer.

deleted 4y ago

[deleted]

eternalban 4y ago

OP doesn't ask the question that would have saved a somewhat straw-man general position on frameworks: Why is it that Go lacks the familiar 'widely adopted framework'? OP could have written about the two different types of code reuse and why one lends itself better to Go: Libraries vs Frameworks. Java has magical frameworks because we have a magical JVM and first class (as in baked into the language) metadata utilities at the language level. Java can define & load new objects at runtime. Loose coupling? My god, this is as loose as it gets. In Go, you'll need composition of processes to accomplish the same thing. Code reuse at Go happens at the library and networked-but-loosely-coupled component levels. This covers a lot of territory but not things that are, in effect, 'containers of components'. If you are in component oriented code sharing territory, Go is the wrong language. With Go, a framework can't do all the magical stuff the other kids' FWs do, but you get most of the pain of using frameworks. It is a language issue. in general: Partially realized abstractions place greater demands on the language and its runtime capabilities than do partially realized composition (e.g. apis).

oxplot 4y ago

> The easiest way is to start by putting everything into one file. You can start simple, defer some decisions, and evolve your project with time. This is something that most even senior developers don’t grok. Default so called project starter scripts of the node world don’t help either. The more structure you build before you know wth you’re doing, the more difficult you’ll make life for yourself down the line when you inevitably have to refactor code.

PaulHoule 4y ago

There's something to say for getting in the habit of delivering microprojects with minimal dependencies and tooling. I do most of my Python work with PyCharm on a Windows machine, frequently with poetry as a dependency manager, but lately I was writing a script for burning DTS-audio CDs in a single step on my Linux server (has the optical drive) and made the decision to only use the Python standard library and do it all in a single file I edit with vim. The result is 150 lines of code that spin like a top. I went through a phase of doing all the problems on HackerRank and learned to love "single-file Java" and discovered that you can do almost anything in a single file except declare a public class (if it is all in one package, default access is all you need.) It's not the usual way I do things but I like Java a lot more knowing I can write simple programs without maven, an IDE and all of that.

hu3 4y ago
After years of working with arguably ever-engineered projects where everything is an interface and the actual implementation is hidden so far up the callstack that half the time was spent searching for the file that needed to be changed, I came to like down-to-earth, YAGNI (You aren't gonna need it) mentality. This includes sometimes keeping things in a single file when sensible. Sure your domains aren't so pure anymore because you've cut some layers of indirection and simplified things. But the cognitive load is so much smaller. Such a pleasant delight to work on "dumb" code. As always, it depends on the size of the project. But my threshold for keeping things simpler has certainly shifted towards trying to keep things simpler when possible.
samsquire 4y ago
Most of my code I write is small projects where all the code is in one or two files I don't enjoy working on enterprise codebase where there's thousands of files that do very little and the code is refactored so hard that you need to jump between 20 classes to understand how it all works and fits together. Leetcode solutions are usually single file solutions. My programming language and interpreter are more than one file though. A parser that lexes and creates an AST and an interpreter class and a class for each kind of AST node that do codegen. I could probably hast used a single file and inner classes.

Chirag 4y ago

Yeah, Having built a web application serving 100K+ users in Go. First 2/3 weeks were spent on making sure we were a framework. So new Modules could be added. New external calls were abstracted and also dealt with lot of circular dependency. This was all fun and learning, but wouldn't mind having a "Flask" or "Express" version of a Golang framework which took care of all the boilerplate out of the box. We did try some existing solution to no avail like Tiny etc. But ended up building a non-framework framework anyways especially to support new features/modules and new devs coming it.

petepete 4y ago
Would https://gofiber.io/ https://gofiber.io/ work for you?
- Chirag 4y ago
  Will checkout thanks.

karxxm 4y ago

Having no framework comes with having no documentation. If you select a framework and work in the same scope as the framework intends to, then you can onboard new engineers much more easily by telling them: We are working as the framework defines, look into the documentation and you will understand the basic architecture of our software. Of cause, devs can maintain their own documentation, but I guess this usually is something that is not done very well. My personal experience: As soon as a company started their software without a framework, it became a huge mess. While onboarding, I observed very bad architectural decisions and even very severe security issues. I'd say, only go with no framework, if you are experienced enough to technically create an own (good) framework. From my observations, going without a framework was usually a decision done by young engineers.

deleted 4y ago

[deleted]

kokizzu2 4y ago

I like fiber the most, but can use anything like echo (and past companies use only httprouter, gin, httpkit, etc) as long as the codebase not overly layered, I guess any framework is fine only need to split to 3 kind of layer: 1. serialization/transport layer (codegenerated) -- framework goes here 2. business logic layer (one that unit tested), only input struct, transform/process, and output struct (DTOs) 3. persistence/3rd party layer (codegenerated too), add additional go source code file for things that wasteful to be codegenerated, only input struct, basic persistence methods or network calls, and output struct (DAOs) goes here if using gRPC layer 1 already codegenerated, so only need to fill layer 2 with business logic and codegenerating layer 3.

mattgreenrocks 4y ago
Your comment made me realize I'm not truly anti-framework, I'm anti-sell-your-architecture-to-the-framework, which most frameworks want you to do. Problem is, many MANY people do not have sufficient experience to know the perils of putting the framework in charge of the architecture, so they do just that, and decry any other approach as "Java-esque." (That label says an awful lot in and of itself.) The impact of this choice often doesn't become apparent until much farther down the road. Then you start getting into the weird cottage industry involving brittle hacks with DBs/frameworks in order to delay setting them up so that you can run unit tests in under ten minutes. It's ridiculous. Part of the blame lies with the devs: refusing to take responsibility for your architecture means you are at the whim of the framework. And the framework devs are also at fault for pushing the lie that you merely need to write the absolute bare minimum of code and everything else will be taken care of.
- majewsky 4y ago
  I think you still are anti-framework by any reasonable definition of the word. Library = your code calls it, Framework = it calls your code.
  - mattgreenrocks 4y ago
    Limiting the scope of what is exposed to the framework keeps you in control of the architecture. This is probably why I find almost every framework deeply unsatisfying. Gin, in Golang, doesn't bother me much for whatever reason, but it doesn't seem to aspire to the same number of things as other frameworks.

mattpallissard 4y ago

The main beef I have with frameworks isn't actually with the framework. It's teams fork lifting / re-writing to the "next best thing" to fix a problem instead of polishing what they have. You wind up with a perpetual revolving door of immature implementations instead of incrementally improving something with known flaws.

bayesian_horse 4y ago

Go's standard library already provides functionality that is provided by "frameworks" in other languages. So "no framework" isn't actually a thing. Also what I like most about Django and Django Request Framework is that it saves me so much writing and reading in almost every case. Not sure how you're supposed to achieve that without something that looks like a framework or how writing ten times the amount of code is more sustainable and maintainable.

epolanski 4y ago

I love writing no framework/no lib backends in nothing but Node.js and TypeScript with some fp-ts and io-ts on top of that. Node's standard libraries (http, fs, etc) give you already enough to work with. Sure, you're going to have to re-implement plenty of things (e.g. file serving, which anyway isn't great in node), and many other things but there's plenty of pros: - you can always understand how things work and change them to suit your use cases. That's just not the case with external tools. Good luck figuring out the codebases or even be able to build them locally - it's much better for educational purposes to understand how things fit together and are supposed to work The biggest con: security. Libraries and frameworks likely patch many vulnerabilities you didn't even know existed. This alone pushes me off from this approach and instead I fall back to some bloated framework, but security is important. The second biggest con: performance. You're likely gonna do plenty of performance mistakes if you don't have a good knowledge of how Node really works.

jurschreuder 4y ago

Go without a framework and just the standard lib is already about equivalent to Python with FastAPI. All you need to do is add a logger of choice, which will be different based on your architecture (one / multiple servers) anyway. You might want to add user auth, which is often an external server anyway. Maybe you want some boilerplate / codegen tool to add/remove/select objects from a database. But I personally don't use that because it's hard to optimize performance with those tools and SQL is already a good tool for it imho, don't need an extra abstraction. In summary, all you need is the standard lib and maybe 3 external libs in Go, because it was made in a time when an api was already pretty standard. In other languages you need way more extra stuff to create an api, so the need for a framework is greater.

metaltyphoon 4y ago

This post embodies the majority of the Go community. “Let’s reinvent every single possible wheel”

SergeAx 4y ago

> Python has Django and Flask, Ruby has Rails, C# has ASP.NET, Node has Express, and PHP has Symfony and Laravel. Go is different: there is no default framework. And this is the root of most problems described by author. If I start project on Python - I know that I can take Django and use it for at least 4 next years, spending one sprint a year tops to migrate to next LTS version. In Go only standard library currently gives me that kind of reliability.

majewsky 4y ago
I'm maintaining about half a dozen microservices written in Go. In my experience, the Go community is very good about providing backwards compatibility. In fact, I'm very strict about keeping on top of my dependencies because "spend a sprint to upgrade to the next version" is a process smell to me, no matter how seldomly it occurs. I have my Renovate bot set up to send PRs every Friday. Most of them are on "automerge on test success" at this point, then they soak in QA for the weekend and I send them to prod on Monday. The only trouble I can recall is with updating Kubernetes libs (let's not open that can of worms right now) and in some cases I have to manually intervene when libs upgrade from `interface{}` to using generics, but that's a refactoring that I gladly do.

albertopv 4y ago

It seems to me too many don't know how big is Spring framework. You can do basically everything with OOTB starter. Enterprise projects are a breeze to develop with Spring Boot.