<p>A lot of people are making great libraries but they are making the same libraries over and over (eg. micro frameworks, logging etc.).</p>
<p>I would like to know what we are missing in terms of packages and what we actually need in Go to progress.</p>
<p>What packages would you like to see released tomorrow?</p>
<hr/>**评论：**<br/><br/>TheOnlyMrYeah: <pre><p>Anything GUI related which will stay alive.</p></pre>computesomething: <pre><p>Yes, I'd really like to see a 'native' go gui solution with a lot of development happening, I had great hopes for 'gxui' but development seems to have stalled somewhat: <a href="https://github.com/google/gxui">https://github.com/google/gxui</a></p>
<p>Then there's 'shiny' which is also interesting, : <a href="https://github.com/golang/exp/tree/master/shiny">https://github.com/golang/exp/tree/master/shiny</a></p></pre>peterhellberg: <pre><p>A full featured image/webp package (Encoder and Decoder)</p>
<p>Image compression libraries in pure Go (pngcrush, mozjpeg)</p></pre>computesomething: <pre><p>You probably know this, but there is a webp decoder atleast: <a href="https://godoc.org/golang.org/x/image/webp" rel="nofollow">https://godoc.org/golang.org/x/image/webp</a></p></pre>peterhellberg: <pre><p>Yes, which is why I specified that I wanted a full featured package :)</p>
<p>Thank you though.</p></pre>dre1080: <pre><p>are there webp encoders for other languages?</p></pre>peterhellberg: <pre><p>Well, there are the cwebp command line tool <a href="https://developers.google.com/speed/webp/docs/cwebp" rel="nofollow">https://developers.google.com/speed/webp/docs/cwebp</a> using libwebp <a href="https://developers.google.com/speed/webp/docs/api" rel="nofollow">https://developers.google.com/speed/webp/docs/api</a></p></pre>postman_: <pre><p>Go still lacks a high-class XMPP library.</p></pre>mohi666: <pre><p>I was trying to work on some side project that needs sentiment analysis using natural language processing. There are some small projects that do that, but they seemed nowhere near Python's NLTK in terms of maturity.</p>
<p>I see a lot of potential in Go when it comes to machine learning. It can easily take Python market share in that area in a few years.</p></pre>wmjbyatt: <pre><p>A lot of the pushback there will be because a bunch of that work is done by academics who, uh, can be a bit slow on the uptake for developments in software engineering (as opposed to developments in computer science, where they are necessarily fast).
<a href="/GNU%20Terry%20Pratchett"></a></p></pre>media_guru: <pre><p>Could use a decent SNMP library.</p></pre>wiiittttt: <pre><p>I've used <a href="https://github.com/cdevr/WapSNMP">https://github.com/cdevr/WapSNMP</a> for my simple use cases, but I agree that something more fully featured would be nice.</p></pre>pcj2bs: <pre><p>I started one a few months ago: <a href="https://github.com/Preetam/snmp" rel="nofollow">https://github.com/Preetam/snmp</a></p>
<p>It only supports SNMP v3.
I need some more time to clean it up, support more of the protocol, and test, but it's a good start.</p></pre>BESSEL_DYSFUNCTION: <pre><p>A fully-featured plotting library that allows for the creation of journal-quality plots. Plotinum and friends are nice, but they aren't on the same level as what you can get in other languages (because a good plotting library takes a massive amount of manpower to write). Probably the most sane thing to do would be a semi-comprehensive wrapper around pyplot via CPython.</p>
<p>gonum needs to be greatly expanded and certain existing parts should probably be aggressively audited, too. The current maintainers are awesome, but there are very few of them. Writing good numerical code takes a while and requires a lot of very specific background knowledge. I've been focusing on just writing B- and I-spline implementations for the past few months, and the amount of background reading you need to do just to keep yourself from making something harmful is significant.</p></pre>mwholt: <pre><p>Pure Go <a href="https://github.com/google/brotli">brotli</a> implementation.</p>
<p>Pure Go <a href="https://github.com/romain-jacotin/quic">QUIC</a> implementation -- the spec is still in some flux but still a huge win for Chrome users. I think I overheard one or two Go authors suggesting this will eventually be in std lib. There's a good start by <a href="https://github.com/romain-jacotin/quic">Romain Jacotin here</a>.</p>
<p><a href="http://flif.info/">FLIF</a> implementation, along the lines of image/jpeg or image/png.</p>
<p>I think it will be very advantageous for Go to have cutting edge technologies under its belt (doesn't have to be std lib, especially early on, for some things) to help it see wider adoption.</p></pre>TheMerovius: <pre><p>I would very much like to see a good QUIC package :) Not only for chrome users, but also because it gives huge wins over unreliable crappy networks (like mobile) for general non-HTTP usecases.</p>
<p>On the other hand, it's probably more likely that the wins of QUIC get incorporated into TCP, than that QUIC itself becomes widely adopted for non-chrome/non-HTTP usecases :)</p></pre>mwholt: <pre><p>There's nothing restricting QUIC to Chrome, but they're the only major client to implement it so far. Also, given that it's UDP-based I am not sure how implementing QUIC with TCP will work out. I'm pretty sure they're aiming to keep this UDP-based. See <a href="https://www.chromium.org/quic" rel="nofollow">https://www.chromium.org/quic</a>.</p></pre>TheMerovius: <pre><p>Well, the official plan (I can't give a source right now, but it was mentioned in a Tech-talk by one of the people working on it) is not necessarily to widely adopt QUIC, but instead use it as a platform to experiment with potential improvements to the TCP protocol. Just like QUIC gives a streaming abstraction with guaranteed delivery and congestion control on Top of UDP as a datagram Protocol so does TCP give you the same abstraction on Top of IP as a datagram Protocol. Thus you can take (some of) the improvements of QUIC and put them into TCP. i.e. Google really wants to improve TCP, but as TCP is far too slow-moving and hard to experiment with, they instead created a new protocol for experiments and because Routers in the wild don't handle non-TCP/UDP IP traffic well, they built it on top of UDP. But the goal always was to integrate the improvements into TCP.</p></pre>dmikalova: <pre><p>What are the differences between QUIC and HTTP2? I know they're UDP vs TCP based, but what are the implications of that?</p></pre>mwholt: <pre><p>QUIC is like TCP but over UDP, specialized for HTTP. It kind of combines TCP features with TLS so your TLS handshake only requires one round trip and since it isn't TCP-based, it does some clever things to improve perceived performance. Basically: faster page loads.</p>
<p>Go to google.com with Chrome and click the padlock icon, then the Connection tab, and you'll see it uses QUIC.</p></pre>TheMerovius: <pre><p>One implication is, that TCP has <a href="https://en.wikipedia.org/wiki/Head-of-line_blocking">head-of-line blocking</a> which QUIC mostly does away with and HTTP/2 can't. QUIC also implements its own specialized and improved <a href="https://en.wikipedia.org/wiki/Network_congestion#Congestion_control">congestion control</a> which gets rid of some <a href="https://www.youtube.com/watch?v=C8orjQLacTo">warming-up problems of HTTP over TCP</a> (<em>really</em> interesting talk. Go wath it) that are inherited by HTTP/2. QUIC also does some tricks to get rid of the <a href="https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment">Three-way-handshake</a> and all the <a href="http://www-01.ibm.com/support/knowledgecenter/api/content/nl/en-us/SSFKSJ_7.5.0/com.ibm.mq.sec.doc/q009930a.gif">TLS handshaking</a> that make TLS connections soooo slow to create and enables connections with the same guarantees as TCP+TLS with <em>zero</em> roundtrips in lots of cases, instead of the 6 or 7 we now have, meaning a client requesting a doc can just directly start sending encrypted data and everything just works. Even if there needs to be a handshake (for example for the first connection to a server), it uses considerably less roundtrips, as it doesn't need the three-way-handshake of TCP, which isn't possible for HTTP/2.</p>
<p>tl;dr: By basically dropping down a level you gain control over the connection, especially the setup, which makes one-shot requests <em>a lot</em> faster for high-latency connections like mobile.</p></pre>dmikalova: <pre><p>Cool, thanks for the detailed info!</p></pre>GoGoGadgetGopher: <pre><p>how about faster jpeg decoding? image/jpeg is still pretty slow compared to state of the art</p></pre>computesomething: <pre><blockquote>
<p>state of the art</p>
</blockquote>
<p>Isn't 'state of the art' jpeg decoding something like libjpegturbo which has a lot of hand-optimised assembly ? I can't see a pure Go solution ever getting close to that.</p></pre>gohacker: <pre><blockquote>
<p>image/jpeg is still pretty slow</p>
</blockquote>
<p>And doesn't support all the subsampling ratios at that.</p></pre>john10x: <pre><p>I would like to see a authorisation framework that could be used in a typical web application. Some sort of role / activity based permissions.</p></pre>dre1080: <pre><p>Have a look at these: <a href="https://github.com/gaego/auth">https://github.com/gaego/auth</a>, <a href="https://github.com/mikespook/gorbac">https://github.com/mikespook/gorbac</a>, <a href="https://github.com/markbates/goth">https://github.com/markbates/goth</a></p></pre>enneff: <pre><p>I'd like to see a nice wav and/or mp3 decoder. We need good audio base libraries first though. (Think <code>io</code> for audio.)</p></pre>akw2: <pre><p>there is nice support for flac that is pure golang and system calls.</p>
<p>goodluck getting a base lib past the farce that is go 1 compat. Maybe in /x/. But even /x/ is tightly controlled by those core devs.</p>
<p>Soon we will hear the deathcry of golang. Mark my words.</p></pre>enneff: <pre><p>Audio base libraries would have nothing to do with the standard library. At the moment there are no standard types for implementing audio streams. They could live anywhere.</p></pre>rcklmbr: <pre><p>Proper windows support for dynamically linked libraries</p></pre>lapingvino: <pre><p>Good and easy to use UI and game toolkits :).</p></pre>bonekeeper: <pre><p>I think Go would profit tremendously from having equally powerful equivalents to Wordpress and Drupal (Gopal!). These are basically the reason why PHP is still relevant today.</p>
<p>So I think this would give Go (the community and ecosystem) a great boost - lots of developers flocking from PHP to Go, lots of websites getting faster overnight, Go becoming the <a href="http://w3techs.com/technologies/overview/programming_language/all">standard for web development like PHP is</a> and a huge boost in job openings for Go. Win win all around.</p></pre>offensivetoothepaste: <pre><p>Something like Craft CMS in open-source Go could be huge. I would use it.</p></pre>dahlma: <pre><p>I'm actually working on a CMS. I have a basic version running in production and it works pretty well, but right now it pretty much just supports rendering markdown posts to HTML, themes and "includes" for themes which are reusable HTML template snippets.</p>
<p>The main fallback that I can see is to make sophisticated plugins isn't as easy as it is with Wordpress. My thought is that they would need to work over an HTTP level where there are REST end points that are hit and some template logic that would be able to communicate with these end points, but it's still something I'm working out.</p>
<p>My blog dougcodes.com is powered by the CMS, and I run it for free on a heroku instance and is cached by cloudflare and between both services I get free SSL so it's a nice setup.</p>
<p>My thought is to have it an open source project that people can self host if they want, but basically have a product that is hosted on Heroku or Digital Ocean with one click installers.</p></pre>bonekeeper: <pre><p>I think the best model would be to drop the plugins under a /plugins/ directory as source code and have them register themselves with the CMS in their init() - this would require recompiling stuff whenever a plugin is added, but shouldn't be a problem. I like how Drupal handles dispatching events to modules (plugins) through hooks (kinda like an Observer pattern, I think) and it would port well to Go.</p>
<p>Like, if your plugin needs to know when "users" are updated or created, you listen to events on users and your function will be called whenever something happens (and here you receive a pointer to a user object that you can modify for the next hook). On the core of the CMS it calls the hooks whenever it needs to act on something to give the plugins a chance to interact with what's happening on the core.</p></pre>dahlma: <pre><p>That could work, but you'd have to make sure the end user has the go library, knows how to run go get, knows how to build and assume they can copy. Most of the users that use PHP have it pre installed on their host for them and don't know the basics of SSH and are unwilling to learn. That's why Wordpress is where it's at today, and that's the problem to solve.</p></pre>bonekeeper: <pre><p>Plugin developers should know how to do these things and for the non-developers you can always have pre-packaged "distributions" that come with a lot of bundled plugins. It wouldn't even be hard to build a "distribution builder" where the user goes to the website, checks a list of plugins he's interested in and clicks "build and download" and a process in the background spawns a container, builds the CMS with the specified plugins and saves the built binary back for download (with some kind of caching in between so you don't have to rebuild the same thing everytime).</p></pre>headzoo: <pre><blockquote>
<p>These are basically the reason why PHP is still relevant today.</p>
</blockquote>
<p>Do you actually believe that?</p></pre>bonekeeper: <pre><p>I kinda do when I look at the open PHP positions and most of them are tied up to some CMS/framework, it's rarely people wanting developers to take care of their in-house custom thing... but the other comment is right, I guess the low barrier of entry on PHP is another reason - the reason they get into PHP at least, not necessarily the reason they stay (assuming that after a few years they are proficient enough to understand Go as a next step). Go also has a super low barrier for entry - you can learn it in a weekend and as a compiled language it is harder to shoot yourself in the foot (comparing with PHP where you can happily sum an integer with a string).</p></pre>dhdfdh: <pre><p>The reason for PHP's success is its low bar to entry. Most PHP coders wouldn't understand the first thing about Go. If they could, they wouldn't be using PHP in the first place. And to put Wordpress in there as wanting to be just like that, OMG! You've never used Wordpress have you!</p>
<p>Are you sure you want a bunch of PHP coders in here asking questions?</p></pre>robertmeta: <pre><blockquote>
<p>Are you sure you want a bunch of PHP coders in here asking questions?</p>
</blockquote>
<p>Yes, languages are tools, not religions. Using PHP doesn't make someone dumb. There are a lot of practical reasons for using it, and billion dollar companies depend on it. </p></pre>dhdfdh: <pre><blockquote>
<p>Using PHP doesn't make someone dumb.</p>
</blockquote>
<p>You're right. They were dumb in the first place to use PHP.</p></pre>fetaflop: <pre><p>I'm a PHP coder and feel I have a fairly good grasp of computers</p></pre>dhdfdh: <pre><p>Do dumb people know they're dumb?</p></pre>fetaflop: <pre><p>You're right, I can't tell. All I know is I'm alright when it comes to writing software</p></pre>bonekeeper: <pre><p>I don't know, do you?</p></pre>dhdfdh: <pre><p>I took the Mensa test. I'm not dumb.</p></pre>bonekeeper: <pre><p>Taking an astronaut test doesn't make me an astronaut. lol</p></pre>dhdfdh: <pre><p>Unless you become one. Yes, I passed.</p></pre>bonekeeper: <pre><blockquote>
<p>The reason for PHP's success is its low bar to entry.</p>
</blockquote>
<p>It's the reason people get into PHP in the first place, but not the reason they stay after many years (when they are proficient enough to understand Go - let's be honest, Go is not that complicated and PHP's standard library is much larger). I can see how someone that is smart and picks up PHP could easily get into Go after a couple years, even sooner.</p>
<blockquote>
<p>You've never used Wordpress have you!</p>
</blockquote>
<p>Not Wordpres but I've done a lot of work with Drupal and there's definitely nothing even remotely close to it in Go.</p>
<blockquote>
<p>Are you sure you want a bunch of PHP coders in here asking questions?</p>
</blockquote>
<p>It would be annoying at first, yes, assuming that you're refering to "PHP Developers" that do nothing but copy and paste code from StackOverflow and call it a day - but any good PHP developer would be more than capable to pick up Go and that's kinda what communities are for. If it becomes a problem we can always put together a "Go for PHP developers" document that would over time cover most of people's questions.</p></pre>nohoudini: <pre><p>I am coming from PHP, but once you learn Go you dont want to go back. Learning now c++ just for education purposes.</p></pre>akw2: <pre><p>support for sctp. Almost everything on the web communicates through tcp, nobody trusts udp traffic. so support for a more efficient stream based protocol is a must.</p></pre>turtil: <pre><p>A decent/maintained SOAP library :( We are dealing with some SOAP Api's at the moment, and its extremely painful to do all of this manually compared to other languages.</p></pre>Testiclese: <pre><p>Ugh. Please let SOAP die. Who's keeping its corpse alive besides MS? I doubt there's much interest in high-quality libs for it. I worked on a Java-based client-side proxy generator a long time ago; it was a sad state of affairs. The complexity is overwhelming and 90% unnecessary, much like any spec that MS/IBM ever touched. Maintaining this and dealing with the interop problems sounds like a nightmare.</p>
<p>If I were you, I'd run a Java server/client and do some kind of RPC (but not SOAP! Haha ) to Go-world. </p></pre>scottjbarr: <pre><p>Unfortunately there is still a lot of SOAP in the world. Ignoring it isn't an actual option in many cases.</p></pre>pm_me_a_pic_girl: <pre><p>MS= Morgan Stanley or Microsoft? </p></pre>koffiezet: <pre><blockquote>
<p>Who's keeping its corpse alive besides MS?</p>
</blockquote>
<p>Java.</p></pre>mwholt: <pre><p>Isn't SOAP dead yet?</p></pre>Zamicol: <pre><p>Sadly, no. </p></pre>psion1369: <pre><p>Kill it. Kill it until it's dead.</p></pre>lapingvino: <pre><p>gowsdl seems to be pretty decent...</p></pre>turtil: <pre><p>This <em>is</em> actually pretty decent, thank you!</p></pre>google_you: <pre><p>Video editor, audio editor/recorder. Music notation. </p></pre>dfab54: <pre><ul>
<li>A python interpreter built in Go that would have no dependencies on any installed Python</li>
<li>A GUI lib for CAD type apps</li>
</ul></pre>dre1080: <pre><p>why need a python interpreter?</p></pre>dfab54: <pre><p>It's holding me back from converting a CAD program from Java/Jython to Go with an equivalent to Jython. I can work without the GUI lib for now. User scripts are written in Jython and need to be kept the same.</p></pre>offensivetoothepaste: <pre><p>IMO Go ORMs don't quite stand up to those found in frameworks like Django and Laravel yet. Significant improvements in that area would would be nice, but also laborious.</p>
<p>Edit: why the down-votes? Have you guys even tried using those ORMs? Some impressive stuff.</p></pre>jmoiron: <pre><p>Having what I'd describe as a good amount of experience with both the Django ORM and the Go database/sql library, I'd say that:</p>
<ol>
<li>dynamic lang ORMs map well to dynamic lang facilities</li>
<li>it works poorly with Go because Go itself works against it</li>
<li>these reduce code but incur the cost of incredible complexity</li>
</ol>
<p>I do agree that there's still a lot of room for improvement in the way Go libraries often deal with sql, but I don't think those improvements will look like the Django/Laravel ORM.</p></pre>offensivetoothepaste: <pre><p>I agree that Go doesn't make this kind of abstraction easy. Something might be possible using a combination of AST walking generators and interfaces though. The result wouldn't be exactly the same as those ORMs of course, but still have the potential to be incredibly useful.</p></pre>j1436go: <pre><p>Instead of the ORM approach, I've built an unfinished and very limited tool that reads a postgres schema and creates model and database access code based on templates. So far good enough for a simple CRUD app.</p></pre>thesnowmancometh: <pre><p>Awesome! Do you have a link? :-)</p></pre>offensivetoothepaste: <pre><p>That sounds interesting. So like code generation? Would love to see what you made.</p></pre>dre1080: <pre><p>What about <a href="https://github.com/jinzhu/gorm" rel="nofollow">Gorm</a> and <a href="https://github.com/go-xorm/xorm" rel="nofollow">Xorm</a>?</p>
<p>Have a look at this list: <a href="http://awesome-go.com/#orm" rel="nofollow">http://awesome-go.com/#orm</a></p></pre>TheMerovius: <pre><p>Even though there are probably a lot of every useful packages one could write, I would still not focus on libraries to have an impact on the go community, but on tooling. Tooling is go's strength and we should build on that. A lot of the disadvantages named by PL-nerds about go can be counteracted with good tools. So writing better and more specific tools will slurp up good people from other languages that will then write better and more widely used libraries. It also <em>enables</em> people to write better libraries, by (for example) creating easier ways to do generic programming.</p>
<p>If you absolutely want to focus on libraries, I would say</p>
<ul>
<li>Write some real-word program in go, that serves an actual need of yours</li>
<li>Have your main package consist of only a couple of hundred LOC <em>at most</em></li>
<li>Everything you can't have in this couple of hundred LOC and doesn't exist as a FOSS package is a good candidate for something that should probably exist.</li>
</ul>
<p>All other examples of libraries named here are examples of this latter process for some real world problem people where trying to write. They aren't really useful in isolation, because the needs they serve are too specific and too hard to solve without keeping real-world usecases in mind. So you have to have <em>some</em> personal need for them to be good. But it would be great if they existed for people who have <em>other</em> usecases that still depend on them.</p></pre>geodel: <pre><p>Something equivalent to JAXP( Java API for XML processing).</p></pre>dre1080: <pre><p>why?</p></pre>geodel: <pre><p>I work on a few Java applications where I take a sample XML template and replace some nodes/ attributes values to generate new XML. I tried to implement those applications in Go but this seemingly straight forward task is somehow not possible in Go.
I can use Go xml libraries to write marshal structs to XML and unmarshal xml to structs but the way my application interacts with other applications. It would not work if some unused empty node / attribute are present in XML messages. I know it is strange that a valid xml from struct will fail but our applications are not using XML schema validation etc. So exact XML generated from a template seems to be the only solution.</p></pre>henderjon: <pre><p>I'd like to see official std libs for LDAP and Berkeley DB. Coming from PHP it's hard for me to suss out the quality of libs that have stagnated and then been forked 5 times over .... Also, being in the std lib, I'd be more confident that the API is idiomatic. $0.02.</p></pre>
