<p>I'm considering a few tech stacks at the moment for web development (Elixir, Clojure, TypeScript+Node, and .NET Core). I'm interested in hearing from folks who have used Go for a while. What has gone well? What hasn't? If you could start your project over, would you still use Go?</p>
<hr/>**评论：**<br/><br/>ar1819: <pre><p>Mostly positive. I've been using Go since 2012 and since 2015 I'm using it professionally.</p>
<p>I tend to miss some things. Most importantly - a good package manager. Proper debugging would be nice tho both delve and Go is getting there. From the language perspective: the slices are a bit tricky to properly explain and use. Same thing about interfaces - typed nil comes to mind. I don't miss generics that much, tho having them would be nice.</p>
<p>On the good side I really, really enjoy compile time and garbage collection time. Compile - because its so fast. Garbage collector - because it's predictable. Goroutines and channels are extremely addictive and I miss them when I work with other languages.</p>
<p>From the company standpoint - Go is extremely easy to pick up and learn. It compiles down to a single binary - which is very useful even with docker. Most of my job involves networking so I'm incredibly happy that I can focus at the task at hand, and not at the language features. And while the resulting code can be verbose from time to time, it very easy to read and understand. Which is really important when you are using third party libraries and something go wrong. People tend to forget that most of the time you work with another's people code. And that code is not perfect. </p>
<p>Go community is a colorful one . It has bad sides. It has good sides. Go is constantly attracting people. And when people don't like what they see, they start to explain why Go is bad. At best. At worst they start to explain why everyone who is writing soft using Go is wrong or dumb. That left some mark - one of them is that community is quite defensive and somewhat conservative. A bit too paranoid about trolls. But and the same time people tend to use Go is very different areas and this results in the good and innovative discussions. Even newcomers tend to bring a interesting ideas to the table, or reveal pain points. </p>
<p>Many libraries has sub-par quality, but at the same time are already written. I can improve and help solidify existing foundation rather than roll my own. This saves a lot of time when you work professionally with a young language, because we all have a limited amount of time and focus per day. </p>
<p>Overall: yeah, I enjoy working with Go. And with incoming improvements and recent announcements, I hope it will get even better. </p></pre>itachi_amaterasu: <pre><blockquote>
<p>Go community is a colorful one. It has bad sides. It has good sides. </p>
</blockquote>
<p>I have started contributing to Go recently. My experience has been wonderful.</p>
<p>The key point while doing open-source is to always be appreciative and humble. There is only a limited no. of people in the core team and there are only 24 hours in a day. Words can mean completely different to people from other cultural backgrounds, especially to those for whom English is not the first language. Going the extra mile in being extra-polite goes a long way IMO.</p>
<p>I always keep these factors in mind while contributing to open-source in general. Helps me appreciate the work we all are doing.</p></pre>Veonik: <pre><p>Spot on. My experience has largely been the same, though I've used it a little less. I think my first project was in 2014 and I've used Go at work since late-2015.</p>
<p>As far as package management, <a href="https://github.com/golang/dep" rel="nofollow">dep</a> is really starting to show promise. It still abides by all the standard Go rules ($GOPATH, <code>vendor/</code>'d dependencies) but manages to provide a neat interface for tracking your project's dependencies.</p>
<p>I'm betting the future is bright for Go.</p></pre>dewey4iv: <pre><p>I've been using it for 4 years now, 3 Of which where it has been my primary language of choice for backend development or tooling. I absolutely love how easy it is to cross-compile and how fast it runs. My experience is that I spend a little more time upfront writing more verbose code; but FAR less time in trying to understand/interpret it later. Go doesn't have a ton of magic (especially compared to something like Ruby) and I've come to really appreciate the lack of magic as a feature. I've really started to embrace code generation to speed things along where in other languages you might have generics. My wife (a relatively new developer) was able to pick it up in about 2-3 weeks and I think I had a working understanding of it in a few days. It's VERY easy to pick up. What hasn't gone well? Well, the community still has a bit of distance to cover before we have dependency management wrangled. This was probably my biggest disappointment with Go (though, not <em>really</em> a language feature). Go did incredibly well with so much of their tooling. I've been really impressed with almost all of it. And then you come to dependency management and there wasn't much there, <em>especially</em> because it's a problem that has been solved before with good results. Not only would I do projects again in Go, I'll probably end up porting some clients over to Go to help lower their server costs. I hope some of that helps :) -- if you have any more specific questions, feel free to ask.
<strong>EDIT</strong>
I'd also like to qualify the above by saying: Go is still very young and showing signs of continued growth; but it also has a relatively mature standard lib. HTTP routing seems to be one of the bigger things missing from the stdlib. In any case, there are quite a few HTTP routers out there to make up for it not being present and renders this issue moot. </p></pre>beekay24: <pre><p>+1 for ease of cross-compilation; SO easy...
+1 for dependency management as an issue</p></pre>caseynashvegas: <pre><p>dep is really close to being great. I'm hopeful that it will get stamped official soon. I've been able to download a ton of code then just run dep init and have everything vendored and building in about a minute.</p></pre>gnu-user: <pre><p>I would add for the dependency issues before dep became more official I used glide. I still am using glide at this moment and it's working out quite well, if you're doing a new project then dep will meet your needs.</p></pre>janderssen: <pre><p>I think it is absolutely aweseome, I have been writing a web application that is portable (windows, linux and MAC) and it just makes this task so easy in comparison to other technology stacks I have used.
I had to write a simple proxy server for out communications layer running on raspberry pi, and voila, easy peasy, write it on my desktop, test it, and then cross compile to the pi, and it really did simply work out of the box.
All my tooling that our customers will need are written in it too, this way they work anywhere.
The only thing I am really missing a lot is a great debugger, I am getting around it, and have been for the past 1-1.5 years, but really miss visual studios, or even XCodes debugger.
It is getting better however, and gogland seems to be making better strides in this area as time moves on, except I us VSCode.
And yes, it can be a bit more verbose, but as I read somewhere else, it pays off when you revisit the code, and you are able to understand it immediately.</p></pre>everdev: <pre><p>I've been programming since 95 and it's hands down the best language I've used. It's not perfect, but the language design, community and tooling is incredibly helpful imo.</p></pre>DeedleFake: <pre><p>I've been using Go since 2009. It became my main language of choice, barring project-specific constraints, pretty quickly. I've tried to switch to other languages, such as Rust, several times, but I always wind up back at Go.</p>
<p>In my opinion, the best part of Go is how much it manages to do with so little. This is really helped along by a good standard library. For example, the whole <code>io</code> package and how it's used is fantastic; every time I need to do stream processing in another language, especially Java or Rust, I just want to strangle someone.</p>
<p>Oddly, I'm not really a big fan of the whole channels thing. The <code>go</code> keyword is fantastic, but a lot of other concurrency features I usually find kind of lacking. If I had to pick a specific single feature as a favorite, I think it would have to be interfaces. Despite seeming kind of similar to Java interfaces, they're the secret to Go's managing to feel like a scripting language, a topic I mentioned in <a href="https://deedlefake.com/2017/07/the-problem-with-interfaces/">a blog post</a> I wrote recently, actually. I also like Go's error handling. It seems awkward at first, but try implementing fine-grained error handling in a <code>try/catch</code> model language and tell me that it's better with a straight face.</p>
<p>Along with that, there are a bunch of little tweaks to normal things from other languages that really help. Methods being decoupled from 'classes', making it much clearer that they're basically just syntactic sugar, minus interfaces. In a similar vein, being able to pass a <code>nil</code> pointer receiver is <em>really</em> nice. Go's switch is also the best one out there. Well, except maybe the one in <a href="https://deedlefake.com/2017/08/introducing-wdte/">my little scripting language</a>... <sup>For some odd reason, I like that one.</sup> Insanely easy cross-compilation and static binaries are also really nice.</p>
<p>The biggest problems I've had with Go projects usually comes from GUIs and other graphical components. Most libraries out there are just bindings for C libraries, which usually doesn't work so well. For example, trying to use SDL from Go is kind of painful thanks primarily to SDL's basically non-existent threading model. GTK+is a bit better, but it still feels like it could just randomly fail. Shiny's nice, but is so early in development that it's unusable for a lot of things.</p></pre>natefinch: <pre><p>Used it for almost 5 years, 4 of that working 40 hours a week in it, putting things into production. It's awesome. </p>
<p>Here's a blog post I wrote about it - <a href="https://npf.io/2017/03/3.5yrs-500k-lines-of-go/">https://npf.io/2017/03/3.5yrs-500k-lines-of-go/</a></p></pre>sh41: <pre><p>Love it. Using it for about 4 years now. It solves so many of my problems so well.</p></pre>iluminae: <pre><p>I have been an embedded programmer in college and a full stack developer ever since. I have used go for 3 years now for every project I can, and I am proud to say I was instrumental in bringing the language into my company as a new primary language.</p>
<p>I am so enamored with go's lack of special cases, low learning curve, and fantastic tooling. My favorite feature is the simplicity that comes from <em>not</em> having things like exceptions. My previous higher level language was C#, so this is an absolute dream to read and write.</p>
<p>Another excellent facet is the incredible developer/community response around problems like "compilation time has increased" or "GC pauses are too long" has been "let's fix it and make it stellar"</p>
<p>I would highly suggest making new programs in go. </p></pre>help_computar: <pre><p>Been using Elixir for 3 years and Go for 2 years.</p>
<p>Almost all of the points I make in this response are subjective.</p>
<p>Cons against Go vs Elixir:</p>
<ul>
<li>Boilerplate code</li>
<li>Programs can and do crash</li>
<li>No package manager (unless I missed something?)</li>
<li>Shared memory for data structure access can cause issues.</li>
<li>Use of interfaces can be a little hard to grasp if you've never seen it before.</li>
</ul>
<p>Cons against Elixir vs Go:</p>
<ul>
<li>Static analysis is not easy and not complete. Sorry, Dialyzer.</li>
<li>Computation can be much slower.</li>
<li>Functional programming can be a big paradigm shift.</li>
<li>Interop with Erlang can be a bit frustrating and Erlang's error messages can suck.</li>
</ul>
<p>Pros for Go vs Elixir:</p>
<ul>
<li>Static analysis and very short compile times make refactoring very quick and very solid.</li>
<li>Computationally very fast.</li>
<li>Cross-compilation and statically linked binaries can make deployments extremely easy.</li>
</ul>
<p>Pros for Elixir vs Go:</p>
<ul>
<li>One command-line tool to rule them all (mix).</li>
<li>Version controlled package manager.</li>
<li>Robust and easy-to-use web framework (phoenix).</li>
<li>Immutable code is extremely easy to reason about.</li>
</ul>
<p>I can't recommend one over the other. I tend to use my Elixir as a "central" server that coordinates my Go, Python, and other-languaged services. I tend to write small Golang projects as micro services.</p>
<p>Building a fully functional (no pun intended) web application for me is much quicker in Elixir. Websockets in Elixir/Phoenix are very straight forward compared to Go. </p>
<p>Deploying a binary built in Go tends to be a easier than deploying an Elixir app.</p>
<p>Go seems to be better supported as a main-stream language for companies that provide DevOps/Cloud services (there are official SDKs for Go more than for Elixir).</p></pre>VivaceNaaris: <pre><blockquote>
<p>No package manager (unless I missed something?)</p>
</blockquote>
<p>Nope still missing that... gopkg.in is my go-to personally for versioning, however.</p>
<blockquote>
<p>Shared memory for data structure access can cause issues.</p>
</blockquote>
<p>I'm a little confused on this bit. What do you mean by "shared memory"? When I see that term, I think two or more separate processes attempting to pass data between themselves or trying to communicate with each other.</p></pre>SeerUD: <pre><p>What about <a href="https://github.com/golang/dep">dep</a> (the dependency management tool from the Go team) and <a href="https://glide.sh">glide</a> (a widely-used third-party dependency management tool)?</p>
<p>Admittedly, dep isn't an "official" tool (yet), but it more than likely will be in the future, and it's at a point now where it's "safe for production use".</p></pre>help_computar: <pre><p>Ooooh. dep looks great. Thanks!</p></pre>help_computar: <pre><p>Sorry "shared memory for data structure access" is very poorly worded. What I meant was "concurrent access of a data structure by two or more goroutines can cause issues". An example of would be two goroutines accessing the same map structure at the same time. Concurrent access of a map can cause a panic. It's not something that is exclusive to Golang though. The way to prevent concurrent access for something like a map is to use a Mutex or put the map in a goroutine, pass messages to the goroutine via a channel, and await a message back from the goroutine via a channel.</p></pre>JHunz: <pre><p>Or you can use the new sync.Map type in go 1.9</p></pre>jzelinskie: <pre><p>Please don't recommend this as a general purpose concurrent-safe map. It has trade-offs and only really suited towards scenarios that are dominated by reads. It can even perform worse than just wrapping a map with a mutex, if you aren't aware of how it works.</p></pre>VivaceNaaris: <pre><p>It's all good my dude. Frankly even before 1.9, and knowing the map type was unsafe for concurrency, it felt pretty basic to just wrap it under a package or struct. I know it may sound patronizing to read that, but its not my intent. Every language has its quirks, Go particularly.</p>
<p>A hash map that is safe for concurrent use takes up a wee bit more of the stack. Its not much, but think from the side of the language designer. "Do I want to assume that a programmer will always want concurrent safety at a cost, or do I want to give them the tools to ensure it if they need it?"</p>
<p>Just a thought. Not saying x is better than y, just offering my opinion.</p></pre>Thaxll: <pre><p>You forgot that Erlang is a dynamic language, it's a huge difference that I would put in Cons.</p></pre>kromem: <pre><p>Been using for over three years now. Coming from primarily Python, with some C experience a long time before that.</p>
<p>I absolutely love the passive interface satisfaction instead of declared interfaces. For me, once this "clicked" programming in Go became an absolute joy.</p>
<p>For a web stack, CRUD is a pain with Go, but complicated stuff is really easy. In general that's been my experience actually. </p>
<p>Simple stuff takes a long time with a lot of boilerplate that's incredibly frustrating compared to other non-typed languages or typed languages with generics.</p>
<p>On the flip side, the language itself is such a great balance of simplicity and power that complicated tasks are so easy to build out. In a large part, it's because you never need to worry about inheritance and can isolate areas of your program elegantly with interfaces that describe what's "expected" instead of what's "provided."</p>
<p>This all can be accomplished in some other languages as well, but Go is so "dumb" that it's refreshingly easy to do things without thinking much about architecture beyond broad strokes.</p>
<p>I also happen to love Typescript, especially since await/async, but in general feel like JavaScript/Typescript are in such stages of constant alteration, iteration, and morphing best practices that I wouldn't personally want to use them for backend stuff.</p>
<p>No experience with Elixir, clojure, or .NET, so can't speak to those.</p>
<p>Would definitely use Go in the future whenever possible. Would really really like to see generics in Go 2, or at least a more codified approach to code generation.</p></pre>fakeNAcsgoPlayer: <pre><p>What I like? - tooling is top notch.</p>
<p>What I don't like? - primitive Compiler which cannot optimize seemingly trivial stuff, plus escape analysis is not very good.</p>
<p>Also, Google doesn't treat Go as first class citizen for it's projects like gRPC and protobuf.</p>
<p>Rant over</p></pre>ragefacesmirk: <pre><p>I've used it for 3 years and quickly felt it was optimized for readability. It doesn't have many frills and it compiles very quickly to allow quick iterations.</p></pre>rkulla: <pre><p>It really depends on what you're doing. If a project I'm using is already in Go, then it's great use and know Go and patch or extend those things in Go. Or if they're python, it's nice to still know python.</p>
<p>So Go is no silverbullet but I definitely tend to now think "Can I start with this project in Go?" because Go is generally a joy to program in, thanks to gofmt, its methods, stdlib, performance and standalone/portable binaries. No more having to deal with java style design patterns in java/php or dealing with callback hell in node. </p>
<p>I've had no issues with vendoring, sql migrartions, and the usual software engineering tasks.</p></pre>fazalmajid: <pre><p>3 years now. Mostly migrated my company's performance sensitive code from Python to Go. 80% of the productivity of Python, 80% the speed of C. Excellent community, very high code quality. Sane concurrency story, necessary in the post-Moore's law era.</p>
<p>The main thing I think missing is a proper debugger (delve is not available on my platform of choice), hopefully they will make progress on GDB compatibility.</p>
<p>Love the simplicity of the language, hope they hold the line on the kitchen-sink approach of, say, generics weenies.</p></pre>quiI: <pre><p>On and off for 3 years.</p>
<p>My overall feeling is it's one of the most solid and reliable tools in my toolbox. </p>
<p>I feel like a better developer for it, like if i need to make something that is robust, performant and hassle free then I have something to turn to.</p>
<p>That's not to say it's perfect. Go would be wonderful in my eyes if it had</p>
<ul>
<li>A canonical dependencies solution</li>
<li>Generics</li>
</ul>
<p>Type safety is important to me and while my background (Scala) will always find Go having short-comings I do feel like generics isn't too high a bar to set for a modern programming language.</p></pre>dvirsky: <pre><p>5 years here - about two of them where Go was my main language (currently it's C, but I'm still writing some Go). I love it <em>for some tasks</em> but I still code in Python for things where performance is not an issue but portability is (i.e. I don't want to distribute binaries for multiple platforms), and in C where Go's performance is not good enough. </p></pre>lazy_jones: <pre><p>Covers all practical needs. It's more verbose than Perl, but much less error-prone than Perl, C and less verbose/annoying and better to deploy than Java (my previously used languages). </p>
<p>Main drawback: its code generation/optimization is not SotA and probably never will be, but there's (somewhat limited(?) gccgo.</p>
<p>It's awesome that I can compile for my armv5tel NAS by just setting environment variables and deploy without any dependencies/extra installation, where the target box is a PITA to even find and install a working gcc for.</p>
<p>I'm slightly worried that Go might pile on some "popular" new features over the coming years and turn into something less pleasant to work with.</p></pre>rberenguel: <pre><p>Mixed, on the positive side. I like how easy to write and read go code is. Sometimes miss the flexibility of Python, or the over-the-top-power of Scala, especially when I'm working in something which would be easier in these languages. But overall, I like it being part of my stack and I like the language simplicity, even with its drawbacks</p></pre>lorneagle: <pre><p>I came from Java to Go because my company started doing docker based micro services and the JVM footprint was too big. Using it for about a year now ( a lot though)</p>
<p>I lile go a lot. It is easy to learn, yet I still learn new things every week. It makes me very productive, and writing concurrent logic has never been nearly as fun as it is with go.</p>
<p>Downsides are package management, although not as bad as in the early maven days. And it is getting better. Dep is almost ready.</p>
<p>Elixir: I recently ported an Elixir micro service to go. I have no programming experience with it. However the service ate 46gig of Ram occasionally. Doing some research on Elixir/Erlang gave me the impression that it is hard to master. And if you don't... Terrible things can happen. Erlang seems like an interesting VM though...if you have the time</p></pre>Kraigius: <pre><p>I've been educated in .NET and I'm a .NET dev. I think Go and .NET are both unsuitable if you are thinking of building dynamic websites. </p>
<p>.NET is hell when it comes to making web services while Go is very very good at it. I had experience with TypeScript+Node that made me write error and I far prefer dealing with them on compilation before a deploy than when something is being executed.</p>
<p>I can go into more detail if requested.</p></pre>kardianos: <pre><p>7 years.</p>
<ul>
<li>Stable, no surprise implementation of runtime, compilers, and standard libraries.</li>
<li>The vendor folder is exactly what my projects need, so no issue with dependency management.</li>
<li>No arch/os runtime behavior exceptions, few standard library exceptions.</li>
<li>No libc required, direct to OS.</li>
<li>Solid stability.</li>
<li>Cross compilation is trivial.</li>
</ul>
<p>The language is okay. The implementation is great.</p></pre>sacado: <pre><p>I'm mostly using go at work since the last four years. I use it for admin tasks on web servers (generating content for a static website, but also more traditional web server stuff), and for AI research prototypes. I don't regret my choices for the following reasons :</p>
<ul>
<li><p>the mix of static typing, dumb simple language and gofmt makes my code (and other people's I work with) incredibly readable and maintainable. Sure, go can seem lacking in a few departments when you write your code (not only the famous generics, but also basic functionalities on slices), but that's a blessing when you must maintain code (you never wonder "wow, you can do that in that language ? What does that mean ?"), since the meaning of any code is straightforward.</p></li>
<li><p>deployment on servers is dead easy. Cross-compile on your dev machine, scp to the target, you're done. No more "oh, wait, I have to install that lib, oh, but I can't it's not compatible with our version of PHP/Python". Distributing to coworkers is dead easy, too. Just mail the executable and you're done.</p></li>
<li><p>regarding execution speed, it's a sweet spot between dynamic languages, which tend to be too slow for the stuff I do, and C/C++, which tend to be too verbose and hard to debug for prototyping.</p></li>
</ul>
<p>EDIT :</p>
<ul>
<li>the language is so dead simple that anyone can learn in a few days enough of it to debug/maintain your code even if they don't know it. Counterintuitive but true story : I have cowerkers who know C++ and not go, but could not understand my C++ code (because everybody uses his own subset of the language) <em>and</em> could understand most of my Go code (not enough to maintain it, but enough to understand what is happening).</li>
</ul></pre>RevMen: <pre><p>I've been using Go for 3 years. I had a project that needed high concurrency so I decided to give Go a go. After one week I knew it was my favorite language.</p>
<p>I like it because it makes me a better programmer. It forces me to think through what I'm writing more, but not in a burdensome way. Instead of searching for the perfect library I often find myself just writing everything.</p>
<p>This is important for me because I am a self-taught programmer. I've never worked as a salaried developer, so I need all the learning I can get. I find that Go is easy to read, even for the most complicated applications, so my learning efficiency is much better than it is in something like Java.</p></pre>mayhempk1: <pre><blockquote>
<p>Instead of searching for the perfect library I often find myself just writing everything.</p>
</blockquote>
<p>That's not the best way of doing things, though... In programming, you ideally shouldn't reinvent the wheel.</p></pre>RevMen: <pre><p>It's not the best way to write production code, but it is the best way to learn.</p></pre>lostninja815: <pre><blockquote>
<p>Instead of searching for the perfect library I often find myself just writing everything.</p>
</blockquote>
<p>This should not be the case to develop effectively...you should rather focus on your core and rely on libraries provided by language. </p></pre>RevMen: <pre><p>Depends on what the goal is. If the goal is to write production code, then yes, libraries are the better option. But that's not what I'm doing.</p></pre>moose_cahoots: <pre><p>I've been using it on and off for a little over 2 years, and I am ambivalent. There are some very nice aspects, like cross compilation and a fast garbage collector that doesn't require tuning. The native support for concurrency is also very nice.</p>
<p>But there are a few things I miss too: I really like dependency injection using Spring Boot as it leads to much better code design and testing.</p>
<p>But the big weakness, in my mind, is the availability of SDKs for common services. Are you using AWS Dynamo DB? Have fun writing native queries instead of using the Java query builder. </p>
<p>I think this will change given another couple years, but right now, there are drawbacks to Go that force you to write a lot of your own libraries.</p>
<p>But the language is fun to use, so there is that.</p></pre>VivaceNaaris: <pre><p>AWS has an official repository for Go clients to their services. The root repository may be found <a href="https://github.com/aws/aws-sdk-go/" rel="nofollow">here</a>. The DynamoDB client is documented <a href="https://docs.aws.amazon.com/sdk-for-go/api/service/dynamodb/" rel="nofollow">here</a>.</p>
<p>If you are aware of these packages and use them, then I'm honestly not sure what you mean by "native" queries. In my opinion, the DynamoDB package is fairly comprehensive in how it does its job.</p></pre>moose_cahoots: <pre><p>I guess the Go client is still more bare bones than the Java client. For instance, in Java, you can <a href="http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/examples-dynamodb-items.html" rel="nofollow">create a get request with a builder</a> (setting the key and table). In the Go SDK, you have a <a href="http://docs.aws.amazon.com/sdk-for-go/api/service/dynamodb/#DynamoDB.GetItemRequest" rel="nofollow">GetItemRequest</a> that accepts a <a href="http://docs.aws.amazon.com/sdk-for-go/api/service/dynamodb/#GetItemInput" rel="nofollow">GetItemInput</a> structure that is just a collection of primitives and maps that you need to set manually. Yes, it works, but requires a lot more boilerplate for it to work.</p>
<p>When I was referring to the "raw query" I was talking about manually populating a structure that looks like <a href="http://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_GetItem.html" rel="nofollow">this</a>. I guess I just see the Go SDK as a lot closer to the "raw" query than the Java builder is.</p></pre>VivaceNaaris: <pre><p>To each his own. For me, I like having the extra control over what goes down. Having prior experience with EntityFramework and the lot, it's refreshing to be able to tweak small code behaviors in the database level to suit my needs.</p>
<p>No language is perfect, and I see where you're coming from. It's a good point these days in the area. It does take more time in Go to get where you're going sometimes, but you're in control, not some third party package. It feels easy enough (to me) to prototype something that fits my purpose. Go is sill super immature, so cleaning up the third party packages and pulling out the good ones will take a while.</p>
<p>Give it a try occasionally, you might like it more!</p></pre>
