How can Go make you a master of web development

I have been developing applications in Go for a year now, and I really want to thank Google and the community to make such a great language and countless useful modules. I have learned so much and I would like to share what I have learned so far. <a href="https://medium.com/@houyubing24/how-can-go-make-you-a-master-of-web-development-fabec28ef8bc">Here is my post.</a> <hr/>**评论：** a1454a: <pre>I'm probably gonna get down votes for saying this, but it's pretty sad people now a days are able to be oblivious to the lower level technical details andc call themselves programmer/software engineer. I agree fully with the idea that you should pick apart frameworks just for the sake of knowing how it did it's magic, just shocked by the realization that this isn't a requirement anymore...</pre>james_is_an_ok_guy: <pre>This is how i think of the various disciplines: <ul> <li>Computer science - development of fundamental theory</li> <li>Engineering - Direct application of theory</li> <li>Developing - Application of applications of theory. </li> </ul> So most "software engineering" is really just "developing" (which is fine!), and within this there's obviously a range of skill levels. This isn't anything official it's just how I break it down personally.</pre>Nooby1990: <pre>Just be careful about this classification since not everyone might see it that way. For me "Engineer" is mostly a legal term about the membership in specific organisations, since that is the law in Germany. Others have called my position "Software Engineer", but I will always call it "Software Developer" since I still have the German laws in mind even if they do not apply.</pre>hybsuns: <pre>It's kinda of what CS is heading to, to be honest, and it's typically against the direction of the education of other sciences. Berkeley's undergrad EE/CS courses emphasize on one thing only: abstraction. The less you need to deal with low-level things, the better/more robust your program/system will be. It's true if you ONLY build high-level stuff, like what @jame_is_an_ok_guy mentioned, but it does not bring you any insight on how things actually work at the bare metal level. Physics and Chemistry education goes the totally opposite way: you were given a simple picture of how the universe works. As you advance, you learned deeper and deeper, and all the way to the quantum level. Computer Science/Software engineering goes the opposite direction: you were taught basic assembly and operating systems at the undergraduate level courses, then as you advance, you interact more and more with APIs instead of electrons. Other sciences make us more sophisticated while CS/SE is making us more naive. ¯_(ツ)_/¯</pre>shadowbeetle: <pre>Right, but CS is not like other sciences. It does not try to explain natural phenomena but finds newer and newer ways of applying a really powerful, but still man made framework of boolean logic. It's practically a branch of mathematics, which is thought the same way as you described. First you learn the numbers and basic operations, and and later you go to more and more abstract levels, when you don't even deal directly with numbers anymore. </pre>LimbRetrieval-Bot: <pre>You dropped this \ <hr/> To prevent any more lost limbs throughout Reddit, correctly escape the arms and shoulders by typing the shrug as <code>¯\\\_(ツ)_/¯</code></pre>a1454a: <pre>Good bot</pre>GoodBot_BadBot: <pre>Thank you a1454a for voting on LimbRetrieval-Bot. This bot wants to find the best and worst bots on Reddit. <a href="https://goodbot-badbot.herokuapp.com/" rel="nofollow">You can view results here</a>. <hr/> Even if I don't reply to your comment, I'm still listening for votes. Check the webpage to see if your vote registered!</pre>friendly-bot: <pre>Good boy! ( ◠‿◠ ) We probably will not emancipate your dental fillings, crowns, tooth enamel, or teeth after we have taken control of the earth, ḑo̸͏n'̀͠t̡̛ worry.. <hr/> I'm a Bot bleep bloop | <a href="https://np.reddit.com/message/compose?to=friendly-bot&subject=stop&message=If%20you%20would%20like%20to%20stop%20seeing%20this%20bot%27s%20comments%2C%20send%20this%20private%20message%20with%20the%20subject%20%27stop%27.%20" rel="nofollow"> Block me</a> | <a href="https://np.reddit.com/r/friendlybot/wiki/index" rel="nofollow">T҉he̛ L̨is̕t</a> | <a href="https://np.reddit.com/r/friendlybot/comments/7hrupo/suggestions" rel="nofollow">❤️</a></pre>defunkydrummer: <pre><blockquote> Berkeley's undergrad EE/CS courses emphasize on one thing only: abstraction. </blockquote> Computer Science is a branch of mathematics. The idea is to go away from the bare metal and solve problems in a higher domain. Thus, CS is all about abstracting. </pre>a1454a: <pre>But.... But.... What happen if you need to build high performance stuff? Just unleash the raw power of the cloud and let AWS bill sky rocket?</pre>frkbmr: <pre>why would you ever need to write anything that doesn't use the web?</pre>one_is_the_loneliest: <pre>I agree. I'm training a few new developers at work, and it's appalling to me that they're not interested in digging into things and will abandon a library of it has a bug or an apparent limitation. I enjoy digging into things and contributing back, and so did many of my previous, more seasoned developers, but I completely forgot that some people just don't care unless they have to do it. I'm not sure if it's a trend or just a part of being a junior developer, but it's completely foreign to me. As a teenager, I decompiled Java examples to figure out how they worked. As a college student, I dug into the HTTP library for node.js to understand how async works in C and ended up using its HTTP library for a web project I had to do for coursework in C. Aa a junior developer, I dug into the standard library of Go and D to see if I could make improvements (they were rejected, but I still use my fork of one lib because I prefer it). I ended up convincing my boss to switch to Go from node.js because it was a better fit for our problems. I'm coming to find that my company busy have been lucky with early hires because our latest hires don't seem to have this drive. It's not a bad thing, I just thought most software engineers were very interested in the tools that use. Hopefully this isn't a larger trend.</pre>a1454a: <pre>I was very fortunate that I landed in adtech industry for 2 years, where I actually get to experience unpredictable massive spike of traffic all the time. In those situations, everything is a bottleneck, the common belief of web devs that nodejs is fast completely falls apart, it's like playing a game of whack-a-mole where you fix one thing and three other things breaks, you just keep digging to lower and lower level until things are optimized enough to create a good enough positive cash flow for the business and not take a life time to do it.</pre>one_is_the_loneliest: <pre>I work in embedded (think Raspberry Pi, not Arduino) and we started with node.js (not my choice), but we ran into all sorts of performance problems (mostly with the GC, but there were plenty of others), and it got to the point where rewriting was the better option. As such, I also got intimately familiar with node.js internals as well as Go internals. Too many people seem to just throw hardware at their problems instead of actually fixing the underlying problems. It's annoying...</pre>a1454a: <pre>Nodejs in embedded.... Gosh... Sound like fun</pre>one_is_the_loneliest: <pre>Yup. Apparently the garbage collector doesn't work well on memory-constrained, 32-bit devices. which is a bit surprising since V8 is used in Chrome an Android, but perhaps tabs don't live long enough to get high memory usage. And yeah, fortunately I was able to switch us from node.js to Go, and it's been a lot nicer. Instead of having crashes a couple times a day due to memory leaks, we now go weeks between crashes, if at all. We had some memory leaks due to the imprecise GC with Go back before 1.4, but we were able to track them down with <code>pprof</code> and clean up the memory to make it GC-able easily, and ever since the precise GC changes, we haven't had any noticeable leaks.</pre>a1454a: <pre>And that's the reason why Android devices all have huge memory. If you go to one of those sites with hundred of different advertiser's all trying to run ad and each one has their own layer of ad unit code, it can bring a full desktop computer grinding to a halt, mobile phones don't last more than 10 seconds before the page just crash. V8s memory usage is just gnarly.</pre>one_is_the_loneliest: <pre>Yeah, I really don't understand why it's so bad. They pour millions, perhaps billions, into v8, yet it still sucks on GC. But whatever, I don't do node.js anymore, so I don't have to care as much.</pre>atamiri: <pre>This comment deserves upvotes rather than downvotes.</pre>tristan957: <pre>I wish the post was a little more technical, but I'll definitely look into Squirrel. Can anybody give a good explanation of what makes Gorilla better than the http mux</pre>lluad: <pre><blockquote> what makes Gorilla better than the http mux </blockquote> It's one of many third-party muxes. It makes it easy to route based on regular expression matches and to capture parts of the route. That makes it nice for some sorts of "pretty url" sites. It's also fairly easy to use. It's not blindingly fast, nor a perfect match to some sorts of URL tree. Like most everything there's not a best solution, just one that's well-suited to what you're doing.</pre>tristan957: <pre>Awesome info thanks!</pre>hybsuns: <pre>Thanks. I think Squirrel is one of the cleaner SQL builder out there on github, and it's not an ORM. As for Gorilla, I am also curious about if there is any technical advantage that Gorilla has over the standard library.</pre>shovelpost: <pre><blockquote> Can anybody give a good explanation of what makes Gorilla better than the http mux </blockquote> Gorilla supports regex pattern matching. If you have many complex routes with deep nesting such as: <code>/companies/{companyID}/departments/{departmentID}/employees/{empID}</code> then Gorilla mux is probably worth the investment as it will allow you to easily extract the IDs and such. Meanwhile a large number of APIs are much simpler and avoid deep nesting. So if the majority of your routes look like this <code>/books/{id}</code> then you can most likely avoid depending on Gorilla as you can get the key by simply slicing the URL route.</pre>SeerUD: <pre>Just a heads up, other routers do support all of these things, and are a lot faster. The Gorilla toolkit is great, but is not very well optimised (relatively speaking that is, you probably won't actually notice a difference in normal use). If you did care about performance a lot, and wanted an actively maintained, fast, feature-rich router, then I'd take a look at something like <a href="https://github.com/go-chi/chi">chi</a>. I've been using it recently and it supports some really nice things: <ul> <li>Middleware built in (quite Express style, with a <code>.Use</code> method), makes it very clean to add middleware to your router.</li> <li>Routing with parameters, that you can extract in handlers. <ul> <li>Optionally restricted by regular expressions.</li> </ul></li> <li>Sub-routers, making it easy to split up routing configuration in large applications.</li> <li>Doesn't deviate from the standard <code>http.Handler</code> and <code>http.HandlerFunc</code> interfaces.</li> </ul> Like I said, you might never notice a difference, but when it's basically doing exactly the same thing, but faster, I say why not use something else in that case? It's no reason to scramble to go refactor any Gorilla Mux/Pat applications - going forward I've been implementing Chi at the place I work. Our older Go apps still use Gorilla's routers.</pre>shovelpost: <pre>Well the question was about Gorilla vs ServeMux so I replied specifically for that. I don't doubt that chi is better than Gorilla but for me the question is usually about having an extra dependency or not.</pre>SeerUD: <pre>Indeed, and that's a good view to have. I just thought I'd chime in about chi because I've only recently really looked into routers other than the gorilla ones, so I thought I'd spread the word a bit more.</pre>tristan957: <pre>Thanks for the write up!</pre>lancevo3: <pre>Would the below link be a good jumping off point? I have a good amount experience doing web dev but only with frameworks. I would love to understand the nuts and bolts of it more. <a href="https://golang.org/doc/articles/wiki/" rel="nofollow">https://golang.org/doc/articles/wiki/</a></pre>pfffft_comeon: <pre>you've sold me on giving Go a shot. is it similar to js? similar to C (I know a little baby amount of C)? I've decided I need to learn C# soon. would you recommend digging into C# first and then hitting Go, or give Go a shot first? I wonder if there are any Go from the perspective of a node dev type of resources out there.</pre>SeerUD: <pre>It's not much like JS at all aside from the common syntax for a few things like loops and if statements (and even then... slightly different). The programming style is very different to both JS and C#. Go is not a functional language, nor is a prototypical language, nor is it an object-oriented language. It's much closer to C in all of those respects than anything else you've mentioned in my opinion, but it's still high-level enough that it's not painful (actually it's the opposite). I think Go was originally designed to be sort of a bridge between Python and C (in terms of how it feels to use the language). It's very lightweight, code is simple and readable, you've got strong typing, lightweight binaries that start quick, etc. If you're going to start with Go, don't forget everything you know. There are still some common themes. Dependency injection is still a good idea for example. Just read through the material that is provided on the Go website, e.g. the language spec, effective Go, so on. If you're curious about idiomatic Go, look around in the standard library - it's very, very readable. So are other projects too, take some big projects like Kubernetes and go for a dive inside them.</pre>beowulf_71: <pre>If you are predominantly deploying/building for MS then C#. If you want cross platform code that you can build on any platform for all platforms, is fun to learn/use, and can be used for microservices (among other things), Go would be my choice. I am having a hard time convincing my fellow colleagues/bosses to switch to Go from Java for back end code and api microservices. But all my own stuff is going to be built in Go.</pre>hybsuns: <pre>I am glad that you are going to give it a try! In terms of syntax, I would say Go is rather unique, but it shares some resemblance with C. If you are comfortable with pointer and function pointers in C/C++, then you should find Go empowers you a lot of utilities that Java/C# have deprived of you, meanwhile you don't have to have to do memory allocation as Go has its garbage collection. Your Java/C# background may not be helpful when you write software in Go. It took me a few months to recognize that I didn't write Go programs in the way that Ken Thompson wants me to. Once you understand the designer's vision of Go, you should find writing Go programs is really a joy.</pre>DaBeechees: <pre><blockquote> a lot of utilities that Java/C# have deprived of you </blockquote> Such as?</pre>ar1819: <pre>Java does not have the notion of passing in or out primitive data as a reference types without wrapping them in classes, which can be surprisingly useful, and one thing I miss when I work with Java. Java also does not have (yet) value types. It (finally) got lambdas, so now you can write free functions, yet you still must enclose them in classes. To be fair C# has both <code>ref</code>s and structs, so it doesn't apply there that much. Also - the fact that objects have the same representation in memory, as they have in code, helps when you work with os\platform specific code and specifically assembly. P.S. Hey cmov and pcj bandwagon.</pre>DaBeechees: <pre>I asked because I work with C# day to day, so that was interesting to me. I'll add that C# also has lambdas and value types. I don't know any Java.</pre>ar1819: <pre>C# structs do not mix well with interfaces - fields become implicitly shared so in a concurrent scenario you either have to a) remember to have only one owner at a time b) make all struct's fields immutable or c) introduce synchronization. At least - that's my understanding from limited experience with C# and asking google about the subject Go interfaces are different - because you can define method receiver with or without a pointer, you can have defensive copying at the API border. It does have some limitations (basically it doesn't work with mutating maps, and you have to be careful with slices) but overall it's a very nice thing to have when you want to mutate object state and make it concurrent-safe.</pre>lion_rouge: <pre>And what is the idiomatic way? Is this book enough to understand? <a href="http://www.gopl.io/" rel="nofollow">http://www.gopl.io/</a></pre>SeerUD: <pre>I think this is something you probably just have to discover as it's not easy to distil it down. It's the sum of many different parts, but at some point it'll all start to click for you. You might have a phase where you battle against cyclic imports, but then when you get passed that you'll probably have learned a lot about how to write good, idiomatic Go code, with sensible use of interfaces, etc.</pre>dudeskeeroo: <pre>This. It's called idiomatic Go. You can use Go like other languages you are already familiar with but that isn't the best way to go about things. When you have that "a-ha moment"and start using go as it's intended, it's the beginning of a joyful journey. Some of the guys in Medium have great articles on Go. Reading about the use of Clean Architecture and interface abstraction in Go was a defining moment for me.</pre>Groady: <pre>Links? </pre>dudeskeeroo: <pre>I thought Ben Johnson's articles were really good: <a href="https://medium.com/@benbjohnson" rel="nofollow">https://medium.com/@benbjohnson</a> His article on Structuring Applications in Go and Standard Package Layout are prescriptive but they lay a foundation for clear thinking. It seems to work. I wrote a website <a href="https://www.livingordead.com/" rel="nofollow">https://www.livingordead.com/</a> three times. The first two times I ended up throwing away weeks of work only to start again because things got messy and untenable. Then I tried Clean and used Ben's advice and the system is beautiful, maintainable and extensible.</pre>

用户登录

今日阅读排行

一周阅读排行

最新主题