Vbuild: "Compile" Vue components to standalone HTML/JS/CSS - <AUTHOR> https://github.com/manatlan/vbuild Its main purpose is to let you use components (.vue files) in your vuejs app, without a full nodejs stack. Just use python2 or python3. BTW, it provides a method to minimize your js scripts (es2015 compliant).
(It provides methods to help you to build your vuejs app without nodejs)
Available on https://github.com/manatlan/vbuild (MIT licence)
Available on pypi : https://pypi.org/project/vbuild/ <comment><USER2> The title of this submission is a bit misleading. This script parses the .vue file and extracts the three sections into x-template script, Vue.component script and a style. These are not standalone in the sense that they cannot exist without vue and vue-template on the page (the later is large and unnecessary when compiling with webpack). Essentially this does what the vue webpack plugin does naïvely and without many of the features like support for different template / JS / style language compilation (e.g. Babel and sass).

<comment><USER3> Gosh,there is so much half assed redundancy in js world that no wonder that so many beginners feel lost.

This does seem a bit too experimental to actually be useful. Some vue based projects are actually nice and easy for beginners to be productive (like Nuxt), but the whole vue ecosystem has never clicked with me even after I toyed with it for at least 2 or 3 times.

<comment><USER4> > Gosh,there is so much half assed redundancy in js world that no wonder that > so many beginners feel lost.

Beginners feel lost because the JavaScript world has learned nothing from Java's ant. These insane build/asset pipelines that take forever to run are the bane of the JS world.

It's like nobody remembers you can just write a JavaScript,then link it to an HTML without 35 compilation steps.

<comment><USER5> We are no longer just trying to toggle a modal or show a popup.

The requirement for frontend has changed dramatically and now we need to handle entire UI flow, interactivity, data synchronization, and even some business logic like filtering and validations with JS, HTML and CSS.

There's no web app for air traffic controller yet, but pretty much everything else has a web app with a huge set of feature and non-feature requirements.

<comment><USER4> > We are no longer just trying to toggle a modal or show a popup.

> The requirement for frontend has changed dramatically and now we need to > handle entire UI flow, interactivity, data synchronization, and even some > business logic like filtering and validations with JS, HTML and CSS.

What does it have to do with using Babel/Webpack and what not? it hasn't.

The DOM is plenty and enough to implement MVC on top of it without requiring 200 libraries from NPM. Developers have been writing complex GUI apps for more than 4 decades without the need for a specific framework, how did they manage to do so yet everybody needs some complex framework in the browser? no they don't. Most of these web apps are forms.

Now I'm not saying don't use react and whatever pipeline you are using. But downloading node and all these stuff isn't what a beginner should be exposed to. Beginners should learn basic principles of front-end development which includes the DOM.

<comment><USER5> > Do you think an app like Photoshop or 3DSMax uses a react like framework on > top of whatever C++ GUI they are using?

Yes I think so. Why else would they require 1GB of space to install them and specific hardware to run them efficiently? As a matter of fact, they require rendering libraries from graphics card companies. The difference is that they use their own proprietary frameworks instead of open sourcing them.

> How many apps can boast about being as complex on the web? most of these web > apps are forms.

Not a lot, but quite significant nontheless. For example google docs, office 365, Facebook, Amazon, and many cloud solutions for enterprise. I agree most of web apps out there are just fancy forms and don't really need any frameworks, but there are legitimate use cases for them.

Edit for your updated comment:

Yes, I fully agree that web developers should start from basics, not frameworks and libraries. Cheers.

<comment><USER6> All of the above, you could implement in vanilla javascript and HTML 5 just fine. People are just getting crazy these days.

<comment><USER7> I can tell you've never actually tried doing that, especially not with a team of 4-5 developers and constantly changing requirements.

If it doesn't sound incredibly painful your webapp isn't complicated enough to warrant a framework anyways.

<comment><USER6> I'm literally in charge of a team of 3 devs that does that. React complicated our stack, slowed things down both development wise and in terms of inefficient asset management, so we reverted to vanilla JS and never looked back.

<comment><USER7> What kind of app is it? Is it an SPA or a mostly-HTML website with some bells and whistles?

I've been through the whole gamut -- pure JS, jQuery, Backbone, Angular1, and React. I love React because it's by far the most pleasant experience for my work. You would not get me to go back to pure JS over pain of death, it's just a non-starter for the types of apps we're building.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> Just as a side note: there is already a way to consume vue components in a server agnostic way - build a web component, which vue cli3 supports. I think bowsers compatibly aside, that's the right approach.

<comment><USER9> Vue cli3 is such a good tool I'm not sure why you'd need this python tool to essentially do what the cli does in a much more convenient way.

</comment></comment><comment><USER10> I personally don't like SFC, because it involves build tasks that are better left to specialised tools IMO.An alternative is to use the vue template compiler directly, without SFC, by making a simple wrapper around it. An example of this: [https://github.com/wearespindle/fuet](https://github.com/wearespindle/fuet)

</comment><comment><USER11> This could be very useful for django/vue stacks, to limit what's needed server side...

</comment><comment><USER12> Sounds like Vueify

</comment><comment><USER13> Somebody please tell OP about lxml or BeautifulSoup.</comment>


MIT Researchers Fire Up the Ionic Thrusters - <AUTHOR> http://www.businessweek.com/articles/2013-04-08/mit-researchers-fire-up-the-ionic-thrusters

<comment><USER2> Original press <http://web.mit.edu/newsoffice/2013/ionic-thrusters-0403.html>

Additionally there is no working <del>model</del>craft, just theory at the moment. The science news cycle failing again.

Edit: Model works, but it's not a flying self propelled craft yet.

<comment><USER3> People have been building working models of these for over 50 years.. the theory is pretty well understood (Electrohydrodynamic (EHD) wind)

</comment></comment><comment><USER4> I remember first reading about these 'lifters' as a kid, and being overly fascinated with them: <http://jnaudin.free.fr/lifters/main.htm>

</comment><comment><USER5> Is this any different from the ionic wind fans you can buy?

<comment><USER6> As far as I know, there's no such thing as an "ionic wind fan" on the market. If you're referring to "bladeless" Dyson fans, those actually still have blades in the base. And then there are fans with negative ion generators, but those still require blades to move the ionized air.

<comment><USER7> There's nothing marleted as a _fan_ that I know of, but there are "ionic breeze" air purifiers that use the ionic wind effect to move air through the filter with no moving parts: [http://www.amazon.com/Sharper-Image-Compact- Purifier-SI397/d...](http://www.amazon.com/Sharper-Image-Compact-Purifier- SI397/dp/B00007J5WC)

They tend to make weird buzzing noises when they get dirty and make the room smell faintly of ozone.</comment></comment></comment>


Ousted RadiumOne CEO Gurbaksh Chahal Promises To Sue His Board - <AUTHOR> http://techcrunch.com/2014/05/29/ousted-radiumone-ceo-gurbaksh-chahal-promises-to-sue-his-board/ <comment><USER2> > You were well aware that if I had gone to trial I would have gotten full > exoneration. Instead, I sacrificed full exoneration for the sake of the > Company's IPO, and – more importantly – for you and for our shareholders.

So basically, here's a guy who is more than happy to be publicly branded as someone who assaults women in order to get a few more dollars.

Whether he's lying about the above or not, he sounds like an incredibly unpleasant and amoral person.

<comment><USER3> Yeah, I've never heard of this company or this guy, but he sounds like a real piece of work.

</comment></comment><comment><USER4> A negotiated guilty plea in California is required to be supported by an inquiry into the factual basis by the court of the defendant; Chahal's argument here would seem to necessarily be that he lied to the court out of a profit motive, and, _on top of that_ , that the board somehow had certain knowledge of what the outcome of a criminal jury trial would have been.

Good luck with that...

</comment><comment><USER5> Whatever happens in the courtroom, Chahal has lost already.

</comment><comment><USER6> Boy, when it rains, it pours.

The thing that gives me pause when considering this story is that in many (most?) countries of this world, this guy's career would have been unscathed after a domestic abuse claim. More likely, he would never have been prosecuted to begin with.

</comment><comment><USER7> I try not to let stuff like this get me upset, because you can never fix people. Now I just need to keep working on having a positive outlook while realizing that there are a ton of terrible people out there.

Of course, Chahal (and most terrible people) probably considers himself a good person. Raises the question as to how I can objectively make sure I'm a good person.

I'll start with not abusing women (or anybody) and treating people how I want to be treated.</comment>


Imdb uses adapted movie quotes for 404 error codes - <AUTHOR> http://www.imdb.com/:%20the%20prestige Most of them are very funny. Examples include:<p>- This is not the wepage you're looking for. (Star Wars)<p>- Well, what if there is no webpage? There wasn't one today. (Groundhog Day) <comment><USER2> The refresh button on this page is surprisingly entertaining... For way longer than should be allowed.

</comment><comment><USER3> Innovative and nice. I think currently they are using a subset of quotes with the word "page"(or something similar like webpage) in it. It showed up only 4-5 quotes for me and then kept on repeating themselves. It looks like a hard code as of now.

</comment><comment><USER4> I want to work with the guy that game up with this idea.

</comment><comment><USER5> Made me want to watch office space again :P</comment>


What the Heck is OAuth? - <AUTHOR> https://stormpath.com/blog/what-the-heck-is-oauth <comment><USER2> Stormpath was recently acquired by Okta and the Stormpath API is being shut down in August.</comment>


Questions that Investors Should Ask Funding Platforms - <AUTHOR> http://blog.thefundersclub.com/post/62738846875/6-critical-questions-that-investors-should-ask-funding

<comment><USER2> 10% of invested funds for admin? Isn't that 5x the industry standard?</comment>


"Even your dreams should be in SSA form" - <AUTHOR> http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-April/030991.html

<comment><USER2> Same reason why Ycombinator is Ycombinator. Here, sony knows who they want to work with.</comment>


Show HN: Collective.Energy – Crowdsource climate solutions as a community - <AUTHOR> https://collective.energy <comment><AUTHOR> Hi HN!

It's easy to feel overwhelmed by the global climate crisis. I made this as a response to the problem, "I don't know what I can do to help".

[https://collective.energy](https://collective.energy) is a community for crowdsourcing climate solutions & actions. The platform empowers individuals by providing inspiration, feedback, and an audience. Turn climate ideas into plans into reality - all in one place.

Feel free to make an account and post. It's far from perfect but let me know what you think. I'd love helpful feedback.

Thanks, Eric (Collective.Energy maker)

<comment><USER2> Great initiative! You should have a look at [https://www.tmrow.com](https://www.tmrow.com), they are building tools which allow anyone to understand the climate impact of their decisions. The "pragmatic guide" they wrote about climate change ([https://www.tmrow.com/climatechange](https://www.tmrow.com/climatechange)) is one of the best I've read on the topic, as it is very well documented and provide actionable insights.

<comment><AUTHOR> This is awesome. The focus on climate pragmatism is exactly what we'd like to channel. I'll post about it on Collective.Energy - if you're involved with tmrow, get in touch!

<comment><USER3> I'm involved! Feel free to reach out at email@example.com

</comment></comment></comment></comment><comment><USER4> Looks cool. A related project is MIT's ClimateColab:

[https://www.climatecolab.org/](https://www.climatecolab.org/)

They run annual contests for climate solutions. For several years they had a conference at MIT for all the winning proposals, with VCs attending. In the first couple years the winners presented their ideas to small groups at Congress and the U.N.

But neither of those entities was interested in the ideas anyone presented. Now they've scaled down to a few tightly focused contests sponsored by people who actually want to implement something.

<comment><AUTHOR> I think Climate Colab is great. They are coming at it from a slightly different angle, which isn't necessarily any better or worse. It is very contest oriented, with highly structured judging processes. Our objective is to include as many people in the discussion as possible, opening up the dialogue beyond a judged format (which can feel exclusive and prevent some people who might otherwise contribute their voice). Their approach has more of an academic focus (which is natural being a product of MIT). To me Colab feels more like Kaggle than HN/Reddit. Awesome work though!

</comment></comment><comment><USER5> An example thing to do that you might be able to replicate in your city: [https://www.edinburghsolar.coop/](https://www.edinburghsolar.coop/)

Co-op and mutual solutions have interesting potential, although this one does rather rely on government subsidies.

<comment><AUTHOR> Amazing idea! Please post about this on Collective.Energy, I think you could inspire similar projects all over

</comment></comment><comment><USER6> The solution seems pretty simple based on current technology:

* Nuclear for base load generation

* Wind/Solar for peak times during the day

* Pumped hydroelectric storage to help offset excess capacity

* Maintain existing hydroelectric dams

It's pretty much that simple, but the politic blocks against using nuclear are massively damaging to our ability to put in place any real solutions.

<comment><USER7> Why is this being downvoted?

<comment><USER8> Because nuclear takes too long to spin up - we don't have time.

<comment><USER9> Well then we just keep burning gas/coal for base load. Congrats on wrecking the planet.

<comment><USER8> We have 10 years to cut 50% of emissions. We literally can't build enough nuclear plants in that time, it's very slow. It's also really expensive. We have to use other renewables.

<comment><USER10> We should a) build renewable; and b) build nuclear reactors with the idea that you will insert rods, to decrease power output when the winds are blowing strong, and restore power when the winds have dampened. Outcome, lowered nuclear waste from the plant, fewer expensive battery storage (or pumped hydro).

<comment><AUTHOR> Hey powerbroker, would love to have your opinions over at [https://collective.energy](https://collective.energy)

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> I don't care what you made was good, I upvoted you one intention alone. More techies should work on this, myself included. It may be interesting to hear my and other people their objections as to why they're not working on it.

I'm already dreading asking the question to myself, but a part of me really believes this should be done.

<comment><AUTHOR> Thank you! I was facing that dilemma myself for quite some time. The intention here is that you don't need to start huge - writing just one valuable comment on Collective.Energy can have a downstream impact that motivates/inspires others and creates positive effects. The ability to do good from your couch is really empowering I think. It makes it easy to get involved. Have you added your voice yet? There could be others that want to hear what you have to say

<comment><USER11> Oh boy, I don't feel qualified to give an opinion about this. But I'll do the best I can.

<comment><AUTHOR> You can take part in ongoing discussions with no judgement or qualification required. If you can help even one person, it will be worth it!

</comment></comment></comment></comment><comment><USER12> Has anyone looked into mutual corps or coops that allow individual (accredited or not) investors to crowdsource solar or wind production facilities? Does it not work out financially or logistically?

edit: Never mind, it would make a lot more sense for me to post that on this collective.energy. I will do that instead.

<comment><USER13> I've wondered if we could crowdsource synthetic fuel production to compete with fossil fuels.

It would be very attractive to drive the oil companies out of business with a frontal assault.

Of course it would depend on having enough consumers prepared to pay more for their fuel.

<comment> semi-extrinsic I hate to be the rain on parade guy, but... you are talking about chemical engineering that will involve working with gases like hydrogen, carbon monoxide and methane at a large scale. You're simply not going to be allowed to even purchase the raw materials you need in the quantities you need unless you are running a proper chemical company, complete with all the certifications and HSE work. The investment cost is huge, and requires a lot of specialized engineering plus the purchase of a suitable industrial estate that is large and has a wide safety zone against all surrounding neighbours.

If you're serious about this, I'd recommend reading Max Gergel's book "Excuse me sir, would you like to buy a kilo of isopropyl bromide", and then imagine what you would need to go through in order to start an operation 10x to 100x bigger than Gergel's in todays regulatory regime.

<comment><USER14> I beg to differ. Based on IPs from Columbia Uni, NYC, we are a startup working on technology to produce green hydrogen from sea water and renewable energy. We received a NYSERDA validation grant and are on our way to pilot in the Port of Rotterdam in 2020. We are currently looking into the possibility to crowdfund some of our work.

<comment> semi-extrinsic Cool stuff! Is it different from electrolysis?

The way I see it, you're somewhat in a different ballgame since you're not buying explosive/toxic gases from anyone else. You're producing an explosive gas from seawater. Still, I imagine you need some pretty big safety zones if you're operating at scale, no?

<comment><AUTHOR> Hey semi-extrinsic, cjbenedikt posted more about this on the platform. If you'd like, you can engage them there and drive the conversation forward!

</comment></comment></comment></comment></comment></comment><comment><USER15> This looks like really interesting & useful. Couple questions:

What copyright is assigned to the posts from contributors? Creative Commons?

Could there be a way to allow users to accumulate a local copy of the discussion threads? This is something I appreciate about mailing lists and Usenet -- being widely distributed & redundant minimizes the chance of important content getting lost to the sands of time. Also allows for reading offline in situations where internet access might not always be available.

I see there are RSS feeds for individual discussions, but on a quick look through a few of those it wasn't clear to me how well this would capture threaded conversations, if it would require continually adding additional feeds for newly spawning discussions, etc. Maybe db dumps could be utilized similar to how Kiwix creates an offline Wikipedia?

Anyhow, great idea, I hope to be able to contribute.

<comment><AUTHOR> linguaz these are fantastic questions. It would be super helpful if you could post them in the Meta category on the site so that they can be opened up to the community for discussion. I'd like to obtain community input on these types of decisions. You're thinking about this at an advanced level in any case which I appreciate.

</comment></comment><comment><USER16> I love this project and have started to participate on the platform, thanks @ericvanular!

If anyone lives in New York and would like a real-life community extension of this idea, you're welcome to join us in getting this meetup group off the ground.

[https://www.meetup.com/New-York-Climate-Change-Meetup- Group/](https://www.meetup.com/New-York-Climate-Change-Meetup-Group/)

<comment><AUTHOR> Thank you! In fact, there's a thread going on Collective.Energy to detail local meetups for everyone's reference. You can find it at [https://collective.energy/topic/23/add-your-local-meetup- gro...](https://collective.energy/topic/23/add-your-local-meetup-groups- here/7)

</comment></comment><comment><USER17> Great, I like the idea.

Something that you may find useful that I came across recently is Climateaction.tech [0], which may have some overlap that you could take advantage of.

[0] [https://climateaction.tech/](https://climateaction.tech/)

<comment><AUTHOR> Absolutely! The more people that are working together on climate solutions the better as far as we're concerned.

It looks like that initiative is working together through a Google doc for now? Perhaps they might be interested in also leveraging a forum-type environment to foster ongoing discussion in addition to their document! Love what they're doing though. If you're involved with that, get in touch!

</comment></comment><comment><USER18> It strikes me that we know much of what to do, we just aren't doing it. We also know what we shouldn't be doing, but we refuse to stop doing it.

<comment><AUTHOR> Hi gaze, founder of Collective.Energy here. We would love to have your voice as part of our community if you're open to it!

<comment><USER18> Your forum seems overwhelmingly focused on individual action. I would be interested if your focus shifted to organizing collective action. Organized boycotts, for instance.

</comment></comment></comment><comment><USER19> Nice project. Can't fault your intentions.

The name seems odd to me however, as I read it from the perspective of electrical energy. Most countries already have extensive electrical infrastructure (i.e. collective energy) so the name evoked in me the horrible idea of taking communities off grid to run on their own micro-grid.

This is fine in a few edge cases, but is generally suboptimal from a socio- economic perspective.

<comment><AUTHOR> Thanks for your feedback. I wanted to evoke the idea of harnessing the energy that we collectively have towards solving the climate crisis.

Also it seems like you have great knowledge about electrical infrastructure. Maybe you could contribute that knowledge on the platform. We've discussed ideas like local micro-grids and many would love to learn more about why you think they are a bad idea. We'd be happy to have you bolstering our ranks!

</comment></comment><comment><USER20> This looks very cool - I can dig it.

</comment><comment><USER21> Why can't I register without giving my email address?

<comment><AUTHOR> Please feel free to put in a placeholder email if you're not comfortable with it. It helps me to recover lost passwords and prevent spam

</comment></comment><comment><USER21> Do you plan any moderation to combat climate deniers?

<comment><AUTHOR> We have baked-in anti spam moderation to the community. In regards to climate deniers coming on and brigading the community, I felt that it would be better to let moderators & the community treat those on a case by case basis with counter arguments and voting as necessary

What do you think? I'm open to suggestion but I feel like suppressing free speech goes against the ideals of the community

<comment><USER22> Absolutely agree with that, but the problem might be people not having the time to follow up on long discussions, and source information to disprove climate denier arguments. In fact my experience is that many climate activists are not that familiar with the science & economics themselves: [https://www.youtube.com/watch?v=8qaJKM77j00](https://www.youtube.com/watch?v=8qaJKM77j00) (she should have quoted Martin Weitzman's work on the fat tails of the climate sensitivity distribution).

I would suggest having a repository of clear arguments and counter arguments with links to reputable scientific sources, that we can refer any climate deniers to. For example: [http://www.realclimate.org/index.php/archives/2018/06/will-c...](http://www.realclimate.org/index.php/archives/2018/06/will- climate-change-bring-benefits-from-reduced-cold-related-mortality-insights- from-the-latest-epidemiological-research/)

<comment><AUTHOR> I'm hearing you loud and clear. That's a great idea to keep the conversation focused. If you're willing, we would love to have you put forward this idea on the platform itself!</comment></comment></comment></comment>


We are not edging up to a mass extinction - <AUTHOR> https://aeon.co/essays/we-are-not-edging-up-to-a-mass-extinction <comment><USER2> Well, there's almost no fish left in the second largest river in Europe, the Danube. I mean, there is some still left, so you could say that the species are not extinct by definition, but we are at best at 5% numbers in terms of body mass compared to 40-50 years ago and more. Source: me, whose parents live in a village on the lower Danube. I'm sure similar stories can be told about countless other ecosystems which are not island-based, like those mentioned in the article.

</comment><comment><USER3> I though we are not so much edging up to mass extinction as we we are squarely in the mass extinction with both feet. We changed environment so much that it's unavoidable.

<comment><USER4> The article points out that most extinctions happen on islands which are tiny compared to the world, and that it's mostly over because we've finished importing rats/etc to those islands and started protecting them. It might be a large number of species recently gone extinct but it's a small number of individuals and they're the least important ones because they're not part of the global ecosystem so nothing in the rest of the world depends on them.

<comment><USER5> I _guess_ you could consider North and South America, together, an island.

Eliminating all the megafauna there (leaving only bears and, depending on how you count, moose and bison) should count for something.

The article is correct that these extinctions and near-extinctions are not themselves a disaster for the natural world, which after a million years would hardly differ, so much as indicators of criminal mismanagement of our own behavior.

</comment></comment></comment><comment><USER6> It seems to me the author is arguing against a point nobody is making, and conflating numbers that are not the concern. I've never heard the arguments that the author is trying to refute, and I consider myself at least mildly educated in the area.

I understand the author is using 'currently threatened species' which are well-counted and well-understood, at least to the best of our ability. But that is not the concern.

The concern is that runaway climate change, precipitated by corrupt governments and corporations worldwide via cheating emissions, lying to the public about CO2 effects, etc. The concern is the radical _future uncertainty_ about how quick changes in _future climate_ may alter ecosystems in a cataclysmic way from which they may not be able to adapt in time.

That this has happened on a small scale already is a telling sign that things could escalate quickly if the world does not get a handle on climate change. The author points to optimistic evidence on local scales but ignores the larger unknowns of _backwards progress_ on climate change, such as trying to bring coal back to US production at scale, etc.

Edit: The author has this to say on the topic, which is unsourced and I believe so wildly optimistic without reason that it discredits most of the work:

> My own prediction is that climate change will be deemed intolerable for > humans long before it speeds up extinction rates, and even if radical steps > have to be taken to head it off, they will be taken.

The steps have _not_ been taken, nor is there visible evidence they will be taken soon. In fact much evidence supports that steps are being taken to _speed up_ climate change.

<comment><USER4> I agree that it's uncertainty of what the climate will do that's why it's serious. But alarmists don't say that. They're somehow certain there will be a disaster. There might not, and we're not sure, but they're don't dare express that uncertainty because either they're fooled themselves or they're afraid the common people who believe and vote for whatever the media tells them might use it as an excuse to not worry. That's perhaps reasonable for their goal because people generally can't handle uncertainty and convert it to a simple yes or no instead. But it's also wrong.

As for people taking radical steps, of course we will - when it affects us. We'll move our cities and farms, build sea walls for the most valuable locations, etc. That's not a big challenge because almost every building on earth was built within the last century and most of them won't last another century regardless of the climate. So even if we somehow have to rebuild all of them, that's what we would have already done anyway. Infrastructure of cities is mobile on a time scale of 100 years. The CBD of my hometown was under water in the 1800s but now it's the capital city, all dry and well functioning because of massive civil works.

As for nobody making those extinction arguments. Myley Cyrus said she wouldn't have children "until I feel like my kid would live on an earth with fish in the water".

<comment><USER7> There _will_ be a disaster, we just don't know what kind.

Will it be mass starvation, desertification, warfare, migrations, lack of water? Monsoons and tornados, or other inclement weather? People dying from heat?

We don't know. There will be a disaster.

Moving farms? Laughable and does not scale. Do you want to invite a few million Spanish into your backyard? I bet you won't and you would shoot the immigrants instead as is the trend. People will _try_ to move and there will be a lot of misery involved.

If you ever worked with refugees, you'd know.

</comment></comment></comment><comment><USER8> I would love to reflect back on this article in the year 2119 after we have broken through 3-4C of warming and see how accurate it was.

</comment><comment><USER9> I'm a bit skeptical about this article. If you graph estimated species extinctions during the past 200 years instead of the estimated numbers of species for the past millions of years, then the current species extinction event _does_ look troubling.

So it depends a bit on the perspective and what numbers you choose. Of course, nature is robust. However, as we know from dead lakes, ecosystems have a tipping point. I would be especially worried about the oceans, because they seem to play an important role in earth's ecosystem as a whole.

The connection to climate change in the article also seems a bit sensationalist. I always thought that the current species extinction has been caused by industrialization in general, not by global warming in particular, which is just one of many effects of world-wide industrialization.

</comment><comment><USER10> > The fossil record shows that biodiversity in the world has been increasing > dramatically for 200 million years and is likely to continue. The two mass > extinctions in that period (at 201 million and 66 million years ago) slowed > the trend only temporarily. Genera are the next taxonomic level up from > species and are easier to detect in fossils. The Phanerozoic is the > 540-million-year period in which animal life has proliferated. Chart > courtesy of Wikimedia.

The fossil record is incomplete, of course. We keep finding new fossils, of new species, many of which are very incomplete. It can be hard to determine if two fossils are the same species or not, depending on what you find. Plus, not all organisms leave fossils, like animals with soft bodies (no bones) or hard shells.

If anything, that first graph looks pretty fishy to me, just with the rapid explosion of growth in the last 200 million years. Of course, those are the fossils that are also on top.

When stamp collecting (or fossil finding) you're at the mercy of luck and statistics.

<comment><USER11> Do you really think that plot is complete bs though? Sure it cant be 100% accurate, but it seems to me if the "stamp collecting" effect were so strong you wouldn't see such clear trends. Also, wouldn't you think that such macroscopic analysis would account for the records incompleteness without necessarily destroying the truth of the trend? I tried to see how they derived that plot from the original article but I cant say for certain yet I know. Here's the link though [https://muller.lbl.gov/papers/Rohde-Muller- Nature.pdf](https://muller.lbl.gov/papers/Rohde-Muller-Nature.pdf)

</comment></comment><comment><USER12> I guess it's not to the point of an asteroid impact, but humans seem to be destroying habitats, introducing species invasions, changing climate, and reducing wild lands much faster than I would think the processes of adaptation could possibly handle. And impavtors are a couple years of bad winters... We are a hammer that keeps striking

I just think the disruption and extinctions are a game of Russian roulette. Did the elimination of that species collapse our ecological balance? No? How about that one? No?

Guess we'll just keep trying

</comment><comment><USER13> I used to respect the author, not anymore. This is a very weak argument when you consider the rate of species loss is much, much greater than 'normal'.

Yes, 99.99% of all species to ever exist are extinct but we are pulling species out that would have continued if not for us. Denying this will only make it worse in our soundbite culture.

</comment><comment><USER14> Just moving things around the world introduced plants and animals better adapted to their surroundings than their native species (as the article mentions). I'll write about the very noticeable effect on just my small area of the world.

I walk around the grounds I live at, it's a small mixed-use farm in western NJ surrounded by a nature preserve that's left to go wild. My landlord holds a PHD in ag science, so we have some unusual trees (stuff like __metasequoia __, which was thought to be extinct until getting discovered in one valley in China) and plants that grow here. When I get stressed out, I walk around and forage and note the types of plants.

One of the more remarkable trees that grows along the back is a lone American chestnut, it's actually large enough to produce chestnuts. I tell people, this is a tree that made up something like 25% of the trees in the Appalachian region, they numbered in the billions up until the time of our great- grandparents. Now there's just a few hundred, that's it! A fungal blight that gets carried by oak trees will prevent survival of 99.9%+ American chestnuts. There's also a Chinese chestnut here, they are resistant to the blight. However, I've heard they don't taste the same, so I'll do battle this year against the squirrels in hopes of collecting a harvest of the chestnuts the world forgot.

A short walk away a prickly vine with triangular leaves covers around an acre of forest undergrowth. It produces brilliantly blue berries. I learned about it a week ago when I spotted it for the first time at a place I used to frequent as a child. I searched for it since it has such a distinct look. It's a tearthumb. Edible, but highly invasive from China. I could never hope to pull all of it out since it's so fibrous and named after what it does to your hands if you grab it. Where it doesn't spread by growing, birds and rivers carry the berries miles away. Freshwater boaters seem to have been highly efficient at moving them around the region (I theorize the vines grow onto boat trailers, then the boaters drop them in lakes... and the berries float off to take root on a nearby shore)

I think of the place I saw the tearthumb for the first time, it was covering a forest clearing that had been created in 2012 by Hurricane Sandy. There had been ash trees there, but the emerald ash borer and the invasive undergrowth have ruled out replanting ash and made it tough to plant new native trees. So no more ash in the future, going the same way as the chestnut.

Coyotes couldn't cut it in NJ, but they evolved/adapted into something else that could take down larger prey and live closer to people. A large coywolf was gulping down peaches a few weeks back just a few hundred yards from my house. I ask the landlord (he's 88 with 84 years spent here)... "Should we think about shooting it?". The answer is pragmatic, "So long as they don't linger around people, they are good to have to regulate the deer population." I'm OK with this, the whitetail population is out of control here and there simply are not enough predators (or hunters).

I drove out to Pennsylvania today to go to a viewing. A spotted lanternfly landed by my feet in the parking lot. Girlfriend stomped it with her boot and we end up killing 5 or 6 before realizing this is a futile battle. These hitched a ride somehow and live on another invasive tree called the Tree of Heaven (or Hell, or ghetto palm). They have ruining the vinyards in the region but haven't made it out to where I live yet. I begin to wonder if Pennsylvania brought China any such comparable natural calamity, or if it's just the tear gas they send to HK causing enough misery.

Fall will come soon, and with it a new round of camel crickets will emerge from basements and wells. The brown marmorated stinkbug will try to force its way into my house to overwinter, and by Halloween numerous asian ladybugs will suddenly appear one day. It's a new, unbalanced reality we live in that the native species haven't fully adapted to.

But it doesn't mean the native species won't adapt. I mentioned that our landlord is very old, but just the other day he speaks of a black walnut tree that he planted years back. Now it must be understood, we have legions of squirrels that live here: from grey to red and even flying. Apparently, they wouldn't touch this tree for over a decade. We're at the edge of its natural range, so maybe they didn't consider it food? At some point, they changed behavior and now eat it. I've thought the same about the stinkbugs: The first years we were inundated with thousands entering households (I want to say it was 2013 or 2014 that were the particularly bad years). I've wondered if birds and other animals figured out it was food since there's maybe only a dozen that will make it in the whole season now where it had been hundreds before. I even trained my parent's dog to eat them by pointing them out!

</comment><comment><USER15> That money chart might say that a) we're not currently in the middle of an extension event on geological time scales, but also that b) having another one at _some_ point, is also inevitable.</comment>


A Rust Contributor Tries Their Hand at Go - <AUTHOR> http://www.polyglotweekly.com/2015/04/24/thoughts-of-a-rustacean-learning-go.html <comment><USER2> I really enjoyed this review. You can tell the author spent some time trying to spot the good and bad things about Go. Too many Go reviews turn out to be: Watch me trying to use Go as a functional programming language and fail miserably because it lacks generics.

Anyway, just like the author I found myself fighting the forced directory structure at first, but it's something I started to like about Go: Go doesn't come with a complicated package management. All packages lie in a directory and you can edit everything with normal shell commands. This keeps things refreshingly simple.

<comment><USER3> >Watch me trying to use Go as a functional programming language and fail miserably because it lacks generics.

Go's lack of generics and its incapacity for functional programming are mostly unrelated.

<comment><USER4> Except for the tiny fact that you don't get higher-kinded types, which is huge for functional programming.

<comment><USER3> HKTs aren't even remotely necessary for basic functional programming.

HKTs are very useful for e.g. typeclasses (used for Monad, Functor, etc. definitions) but you don't need them. Strictly speaking, you don't even need types at all (even though they're great).

<comment><USER4> That's totally right which is why I never said anything to the contrary.

You're crazy if you do FP without HKT though.

<comment><USER5> Higher-kinded types can definitely be overused. One has to be careful with higher-order anything, since it complicates reasoning about programs. (First- order is simple if you can get away with it)

</comment></comment></comment></comment></comment></comment><comment><USER6> There is one minor syntactical convenience available to make the message example slightly more concise: switch msg := msg.(type) would make msg a message of the specific type inside each case. (So msg would be a DrawLine between 'case DrawLine:' and the next case.) Author might have just wanted different names in the different cases, which is a perfectly defensible reason for doing it the way he did instead.

He says "Go seems to advocate runtime over compile time checking." I think it's less that folks _prefer_ run-time checks on principle than that they simply don't yet have in hand great ways to strengthen compile-time safety while meeting their other goals (meeting backcompat promises, not complicating spec/impl too much, other work like shorter GC pauses or new platform support). As an example of a team member not being a fan of all the runtime checks, bradfitz complains about the occasional gross interface{} here: [http://talks.golang.org/2014/gocon- tokyo.slide#50](http://talks.golang.org/2014/gocon-tokyo.slide#50) . And there is active work from the team and community on static checking, though most of that right now is in the form of heuristic checks in external tools, e.g., go vet and errcheck.

All in I love this--I tire a bit of posts that are like "I wrote a toy program [or not even that]; here's Why Everyone Else Is Wrong" (because _anyone_ could give an opinion that informed given a day or two, and hot takes are getting old). But it's cool to see someone who, by virtue of working on Rust (and seeing it evolve) has unusual perspective on tradeoffs and seems to have written, you know, pretty thoughtfully and maturely about them.

<comment><AUTHOR> That's pretty sweet, I'll remember that trick. The `range` trick was another one that took me some time to realize, there are lots of neat sugary things in Go like this :)

> I think it's less that folks prefer run-time checks on principle than that > they simply don't yet have in hand great ways to strengthen compile-time > safety while meeting their other goals

Agreed, that sentence was a bit unclear from me. I did mean that they're okay with losing compile time safety over other benefits.

> All in I love this--I tire a bit of posts that are like "I wrote a toy > program [or not even that]; here's Why Everyone Else Is Wrong" (because > anyone could give an opinion that informed given a day or two, and hot takes > are getting old). But it's cool to see someone who, by virtue of working on > Rust (and seeing it evolve) has unusual perspective on tradeoffs and seems > to have written, you know, pretty thoughtfully and maturely about them.

Aww, thanks :D

</comment></comment><comment><USER7> I've written a fair amount of Go and his view is pretty consistent with my experience. Go has a good culture of doing things the simplest correct way and only that way. Rust is really interesting because of the stronger compile-time assurances and lighter footprint (looks like it'll be a good candidate for embedding into mobile apps), I'm learning it in the hopes that I'll be able to use it as an alternative to C for portable library code.

<comment><USER8> Sorry for asking off topic question. What is good resource you suggest for understanding go memory management. For someone I am unable to understand from golang docs

<comment><AUTHOR> The nice thing about Go is that you rarely have to think about memory management. Can you access the object? Then it exists! (even across threads)

You should use locks for thread safety though.

That being said from a Rust background I like to be able to know what's going on at the lower level and Go makes that harder, but that's not a major issue whilst programming.

<comment><AUTHOR> FWIW in Rust "Can you access the object? Then it exists!" is true too, however you have to wait for the compiler to reach a certain point to know that you indeed were allowed to access it[1], whereas in Go you can figure this out by looking at the code :)

[1]Or internalize the borrow checker, which is something which eventually, automatically happens to all Rust programmers AFAICT. It actually spills out into other programming languages too so you get a nice involuntary mental tool to ensure safety in C++ :)

</comment></comment></comment></comment><comment><USER9> > Having interfaces be autoimplemented [...] it's just not what I'm used to > and it restricts me from writing certain types of code without using dummy > methods like so to get static type safety.

There's a Go idiom for that. If you have

      type Doer interface {
        Do()
      }

and a

      type thing struct {
      }

and you want to make sure that `thing`s implement `Doer`, just add this line:

      var _ Doer = thing{}

_ is a special value that can be redefined at will, so the pattern can be used as many times as needed. From there, the meaning should be straightforward: _ is a `thing` that implements `Doer`, so the compiler will check it. You get to keep implicit interfaces, that you can make explicit as you need.

Apart from that, this post is really great; as someone "used" to Go and not at all to Rust this kind of impressions is always enlightening.

<comment><USER10> There's still no solution for the cowboy/shape problem (where you want to have a single object that can implement Cowboy::draw() and Shape::draw()) though, presumably.

<comment><USER11> You can use object composition: [http://play.golang.org/p/jyS38luYjM](http://play.golang.org/p/jyS38luYjM)

Then make a Draw() method on the single object default to what you expect. The simple inline explanation is:

        type SingleObject struct {
            Cowboy
            Shape
        }

Access is as follows to be unambiguous:

         Woody.Cowboy.Draw()
         Woody.Shape.Draw()

<comment><USER12> The problem is that you can't differentiate SingleObject from CowboyObject and ShapeObject.

They all are the same interface and can be passed into each other's methods, leading to a logical error.

</comment></comment></comment></comment><comment><USER13> > Visibility (public/private) is done via the capitalization of the field, > method, or type name. This sort of restriction doesn't hinder usability, but > it's quite annoying.

While the capitalization of identifiers may be surprising, in practice it is one of the best features of go in my experience because no additional context is needed to know whether an identifier is exported. In rust, as far as I can tell, it is not possible without referring to the declaration.

As far as globally changing whether an identifier is exported, it is easy with the gorename tool, no search and replace necessary. Gorename also updates any references to the identifier in other packages in $GOPATH. [https://godoc.org/golang.org/x/tools/cmd/gorename](https://godoc.org/golang.org/x/tools/cmd/gorename)

<comment><USER14> _no additional context is needed to know whether an identifier is exported_

Isn't this the same as the argument for Hungarian Notation? And isn't it a bit of a slippery slope? Why not add an 'i' for integers, so that no additional context is needed to know whether a variable is an integer. Etc.

There is _a lot_ of information about a particular identifier that it would be nice to know at any given time, and in my opinion it's arbitrary to pick just one and make it a language rule. A much better solution is for to use IDEs or text editor plugins to visually show (using color, formatting, bits of UI) that information in a user-configurable and context-dependent way.

<comment><USER15> In defence of hungarian notation, the way Joel tells it makes a lot of sense [0]:

 _" Simonyi's original concept for Hungarian notation was called, inside Microsoft, Apps Hungarian, because it was used in the Applications Division, to wit, Word and Excel. In Excel's source code you see a lot of rw and col and when you see those you know that they refer to rows and columns. Yep, they're both integers, but it never makes sense to assign between them. In Word, I'm told, you see a lot of xl and xw, where xl means "horizontal coordinates relative to the layout" and xw means "horizontal coordinates relative to the window." Both ints. Not interchangeable. In both apps you see a lot of cb meaning "count of bytes." Yep, it's an int again, but you know so much more about it just by looking at the variable name. It's a count of bytes: a buffer size. And if you see xl = cb, well, blow the Bad Code Whistle, that is obviously wrong code, because even though xl and cb are both integers, it's completely crazy to set a horizontal offset in pixels to a count of bytes."_

It's actually a practice I now use myself in certain contexts.

[0] [http://www.joelonsoftware.com/articles/Wrong.html](http://www.joelonsoftware.com/articles/Wrong.html)

<comment><USER16> This is so exactly the argument for a decent type system that seeing it used to argue for a _naming convention_ is downright surreal.

<comment><USER15> Yes, a good type system would help with these issues, but that's not the only way to crack this egg. I mostly work in Python, so it's not an option, but even if it were, using types for this stuff is probably a pretty heavy solution in some cases. Obviously, that depends on your type system, but for most of them having to define new types for different types of array indexes would bre _really_ clumsy.

As soon as you open the types basket you have quite a lot of overhead that you didn't have before (it's a tradeoff, as ever). Not only that, but types won't help you on the readability front - not without an IDE. Spolskey's argument is that a naming convention can make the code look obviously wrong, and there's nothing wrong with that.

Hungarian notation has its place. I've used it before, and I'll do it again. Used correctly it can make the code safer and clearer. Types give you that too, but a naming convention is as simple as it gets, and it's free!

<comment><USER16> Why do you need the code to look obviously wrong when you have a compiler capable of _telling_ you that it's wrong? It doesn't require a full-blown IDE to get fast feedback; I use a fairly lightweight vim config that gives me type-checking every time I save a file.

I also disagree about overhead. Defining new types is an O(1) cost, and decent modern languages should have type inference so that there isn't a recurring annotation cost either. Even accounting for the cost, if the benefit is 10 units and the cost is 1 unit, saying only that "it's a tradeoff" is a bit absurd. When there are tradeoffs, engineers don't throw up their hands and flip a coin, they calculate the costs and benefits and use the best solution. Types _easily_ win in that calculation.

I don't disagree with using notation to fill the gaps when you must work in a weaker language, but we shouldn't pretend that it isn't a weakness.

<comment><USER15> I think maybe my comment sounded like I was advocating notation over types. I'm not, and I agree with everything you're saying.

I stand by my assertion that there are situations where a little notation is a good thing.

A better argument for notation is the readability of the code (which I place a high value on). That's a place where the types don't help as much, but the notation does.

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> pretty even-handed.

> The other day I had to make a bunch of fields public to satisfy Go's > encoding package, and code needed to be updated everywhere with a manual > find/replace (the same string was used in other contexts too so it couldn't > be done automatically)

gofmt has syntax-level replacements. So you could do:

`gofmt -w -r 'unexportedName -> ExportedName' *.go`

or something similar, and it would do the correct thing, ignoring the string matches where it appears in other contexts.

<comment><USER18> This is why we need an IDE or Neovim + some epic plugins. Who's working on one?

<comment><USER19> As far as vim goes, [https://github.com/fatih/vim- go](https://github.com/fatih/vim-go) is the best all-in-one plugin. Really a pleasure to use and easy to install. Should work with neovim too.

</comment></comment></comment><comment><USER20> > _Despite the performance costs, having a GC at your disposal after using > Rust for very long is quite liberating. For a while my internalized borrow > checker would throw red flags on me tossing around data indiscriminately, > but I learned to ignore it as far as Go code goes. I was able to quickly > share state via pointers without worrying about safety, which was quite > useful._

I haven't gotten very far into the article yet, but this paragraph sent up a huge red flag for me. GC does not make the code safe. All it does is ensure that values don't get destroyed while they're still referenced. But you still run the risk of data races. If you're writing single-threaded code then this is fine (because single-threaded code doesn't have data-races), but the program being written here is a concurrent program.

Obviously you can write safe programs in this fashion. But you still have to think about safety. The difference is the compiler doesn't verify safety for you, which means you can write code fast without worrying about the compiler yelling at you, but your program may have race conditions in it.

Anecdotally, a few years ago when I was active with Go, a program of mine would segfault about once a _month_. It was a command-line utility that I ran maybe a few times a day. The segfault was so sporadic that I could never figure out what was going on. Then Go 1.1 introduced the data race detector. Using that, I was able to discover that the Go runtime was actually spinning up two goroutines when I thought it was only using one (servicing the stdout and stderr of a child process), and the one buffer object I was writing to turned out to be written to from two separate threads. This usually worked, but on that rare occasion it would lose the race and overrun the buffer. This is a bug that plagued me for half a year, and I'm really glad that the Go team created that data race detector because I never would have figured out what was going on without it. But it's a bug that simply cannot happen with Rust.

<comment><USER21> > Using that, I was able to discover that the Go runtime was actually spinning > up two goroutines when I thought it was only using one (servicing the stdout > and stderr of a child process), and the one buffer object I was writing to > turned out to be written to from two separate threads

Wait, does it mean that go makes your code running in more threads without you knowing? When can that happen? Sounds scary if true.

<comment><USER20> It means that there's nothing in the API that tells you whether the function might spawn a goroutine. It has to document it.

I don't remember the precise details anymore, but my recollection is I was spawning a child process and passing Writers to use for stdout and stderr (looking at os.exec, I don't immediately see anything that matches my recollection, so I'm wondering if maybe I was using a different package). I expected that it would internally do something like select over stdout and stderr in one goroutine, therefore making it safe for me to pass the same buffer object for both (because I wanted to combine writes). But instead it was spawning 2 goroutines, not 1. And there was no evidence in the API that what I was doing was wrong, the only way to know was for the data race detector to flag it.

</comment></comment></comment><comment><USER22> Not bad, at least a fair look!

One thing that immediately set off my radar (as a Go programmer) is the paintingLoop switch on type.

Yes, sometimes a switch on type is necessary. However, this is not one of those cases.

You want to have a Triangle and Line with a Draw() method and a "Drawable" interface... and then just call into it. The signature of the loop in question then is paintingLoop(ch chan Drawable).

An abuse of naming, but a Quit.Draw() could actually quit, for example. This is just offhand though.

In short, good article, but the Go examples are written with a Rust intuition. Which, I mean, fair enough; I started writing Go with a C++ intuition, with different questionable practices ;)

<comment><USER23> Glad you pointed this out. Hopefully the original author will make a note of that on his blog because when people run across it they will be given the wrong impression about how this would be handled in Go.

I love how "opinionated" and slim Go's design is. The less variation in code, the better, in my opinion. It might not be as "fun", but frankly I have a lot more fun programming when I don't have to deal with esoteric solutions to problems.

<comment><AUTHOR> I'm not so fond of editing an already published post, but I'll ask bcoe if we can/should do that and add some clarifications.

</comment></comment></comment><comment><USER24> The unused imports thing seems to be a common complaint, however I just use go-imports, and imports are added/removed automatically when I save the file.

I never ever have to even touch imports, except sometimes when two different packages have the same name.

<comment><USER25> This doesn't help with unused variables, which comes up just as often when doing the same thing (coding piecemeal, testing if it compiles, etc.)

<comment><USER26>
      var x int
      _ = x

Mildly annoying, but it avoids unused variables in any code which compiles, and is a helpful reminder of "I was going to do something with this value".

<comment><USER27> It seems like a warning only lint would be less annoying and a better reminder.

<comment><USER28> It is an established fact that humans cannot be trusted to handle warnings responsibly.

<comment><USER29> Judging from this thread Go users are regularly using various tricks and hacks to avoid the compiler errors. So evidently Go programmers can't be trusted to handle compiler errors responsibly and not use hacks to hide them. In which case, what is the point of making in an error? It just makes things more difficult for the responsible programmers who don't ignore warnings (instead of a warning that they will notice they have to find and remove an obscure line of code).

It was an interesting experiment to make these things errors only, but it's clear that it has failed.

</comment></comment></comment></comment></comment></comment><comment><AUTHOR> Note: this was originally posted at [http://inpursuitoflaziness.blogspot.in/2015/02/thoughts- of-r...](http://inpursuitoflaziness.blogspot.in/2015/02/thoughts-of-rustacean- learning-go.html) , however I thought it would be nice to go through the Polyglot Weekly editorial process and come up with a better version of it :)

</comment><comment><USER30> Having next to no Go experience, and zero Rust experience, I found this article a really fun read. Coming from a Node.js background, it was neat to see the concurrency approaches used in both languages compared -- quite different from a single-event-loop :)

<comment><USER31> I'm sure it just comes down to personal preference, but as a node developer myself (perhaps former), i found it so freeing to switch to Go. Mainly for two reasons (which i assume are less common reasons):

1\. Synchronous by default 2\. Interfaces

Point 1 to me feels silly to admit. But man, i still do a fair bit of JavaScript/Node for work (our frontend, mainly) and it is just so.. tiresome to me, to constantly feel on the edge of bugs because some functions are expected to be synchronous (return values) and others are intended to callback.

I'm not even talking "nested-hell", i'm simply referring to the mental overhead that i apparently use when using any JavaScript function. It's not difficult.. it's just not enjoyable. It's.. tiresome for me.

Point 2 is simply because i really like interfaces. Back from my Python days, a few libraries had invented ways to support interfaces and i really really liked them, but not the overhead they required. Being able to expect the behavior of an object with certainty is the main part of duck-typing to me, and seeing that from a more static language (when compared to python/js) is really enjoyable.

I know you didn't ask for a writeup, i just had to agree with you and felt the need to share my experience from a similar standpoint. :)

<comment><USER32> But that's the issue, duck typing really leads to many situations with uncertain situations. It's like the + operator in JS: depending on context, you can have appending, addition, or vector addition.

<comment><USER31> Are you referring to duck typing in general? Or specifically Go's interfaces (which i referred to as duck typing)?

They seem rather harmless to me, so i'm curious on your perspective. I see them as no more dangerous than an explicit type (or any function, for that matter).

You're asking for a specific behavior, and you _know_ that what you get will have that specific behavior. A Reader or Writer is a simple example of that. Sure, you don't know what it's writing to, but that's outside your scope and likely the scope of the function - right?

Perhaps i misunderstand you, i'd love further explanation/examples _(pertaining to Go's interfaces)_ :)

<comment><USER32> Imagine I get an object, I don't know it's type – I can't even check if it implements the VectorAddition, Addition, or Appendable trait, I only see it has a .+ method.

How am I supposed to switch between types being able to do either of these, without listing all types that might occur – as this might not be possible

(I'm thinking about Haskell's type classes as a solution to this, btw)

<comment><USER33> Plus is a bad example because you can't do that in Go, but I understand the question.

Basically, you don't do that in Go. Go has interfaces, but they're implemented implicitly. So rather than "I get an object", you say, "I get an object that implements interface X", and you use whatever methods X has.

That just means its up to you to name interfaces in a reasonable way. Which is one down side - if you have an "Add" method, it's back to your question about what it means to add, depending on the implementation.

Nothing does this as well as Haskell as far as I can tell.

</comment></comment></comment></comment></comment></comment><comment><USER34> My biggest problem with Go is this one [1]

In short, assign nil to a variable, and it ends up not being equal to nil (?!?) Really, how does something like this get approved?

[1] [https://golang.org/doc/faq#nil_error](https://golang.org/doc/faq#nil_error)

<comment><USER35> A nil pointer is a perfectly valid value that can satisfy interfaces.

[http://npf.io/2014/05/intro-to-go- interfaces/#toc_4](http://npf.io/2014/05/intro-to-go-interfaces/#toc_4)

</comment></comment><comment><USER36> > _Eventually I was able to learn the proper style by watching my code get > corrected._

Funny thing: I actually benefit from _not_ typing idiomatically! GoSublime runs gofmt whenever you save a file. It's a free check for syntax errors, as it won't fix the formatting if you made a mistake. And because the mistake must be in the non-idiomatic formatting, it's easier to spot too.

> _I 'd love to see a rustfmt, however!_

Seriously, I miss gofmt in any language that doesn't have a similar feature. I'm so surprised it hasn't been copied more!

<comment><USER37> Reminded me of the old Visual Basic, in which you'd declare your variables with caps but write their usage in lowercaps. This way the instantaneous auto- capitalization checked for you that you had written the name correctly (instead of implicitly defining a new variable!).

<comment><USER38> Even today, auto capitalization fixing (and just auto-formatting code as you type in general) is one of my favorite features of Visual Studio, one that I wish I could have in every IDE/editor.

For example, if your class is named FooBar and you are declaring a FooBar variable by typing foobar, Visual Studio will just auto-fixit as you type. Same goes for properly formatting if statements, declaring functions required by interfaces, etc... In comparison, Xcode requires you to "confirm" the autocompletion fix by hitting enter, which is less ergonomic in my opinion.

</comment></comment></comment><comment><USER39> Interesting point of view to hear. RE: enums - There is an idiomatic way to do enums in go I believe:

      type MyEnum int

      const (
            A MyEnum = iota
            B
            C
            D
      )

<comment><AUTHOR> Rust's enums aren't like Java enums, they are algebraic datatypes and each variant can hold different data. Check out the example with DrawTriangle and whatnot for what I mean :)

<comment><USER40> You are not correct regarding Java's enums. Define properties for your enum type, widen the constructor appropriately, and provide the accessor methods:

[https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html...](https://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.9)

<comment><USER41> That's not the same thing. Rust enums are types, each with the possibility of having different fields that store data. Java enums are instances of a type, each with static data.

(rust enums can have associated data too, but its not their main usage in idiomatic code)

</comment></comment></comment></comment><comment><USER42> What about compilation speed of Go/Rust? Surprisingly there wasn't mention about this in article. I consider slow compilation as a main issue of Rust compared to Go. Am I right?

<comment><AUTHOR> Rust is very slow, yes.

However, I was writing a rather tiny library so it wasn't a major factor, so I didn't notice this until much later.

I did intend to add a blurb about this when posting to Polyglot Weekly, but I .. forgot ;P

<comment><USER42> thanks for answer)

</comment></comment></comment><comment><USER43> Having written in both Rust and Go, I found that a very good article.

The big new idea in Rust, of course, is the ownership model and its compile time borrow checker. That's worked out surprisingly well. I expect to see that idea appear in future languages. One could have a Go-like or Python-like language with a borrow checker. It's not inherently tied to Rust.

As a practical matter, programming in Rust is more likely to hit problems with type checking than borrow checking. Ownership problems are usually with your own code. Type problems often involve code written by others, and changes to other modules often induce type errors. Because Rust has type inference, and because it's often not obvious what the type inference engine is doing, Rust can have rather abstruse type problems. Go is rather straightforward in that area.

Go lacks generics and templates. This simplifies the language, but the lack of generics then has to be worked around. Go has too much use of "interface{}". Bolt-on compiler passes such as "go generate" and the protocol buffer compiler have been added. Both are used mostly to get around the lack of generics. Rust has very powerful generics and templates, so powerful that they tend to be over-used. Everything seems to need a generic. Rust is starting at the cruft level it took C++ 20 years to reach. This may or may not work out in practice. It may be necessary to restrain Rust template enthusiasts from getting carried away.

Error handling in both languages is via return values. Go is straightforward, with multiple return values being the normal approach. The Rust mechanism, involving Result<> and Some<> types, is rather clever, but results in wordy code to do simple things. Too much Rust code goes into putting things into Result and Some objects, then analyzing and dismantling those objects. It's not clear that leaving exceptions out of Rust is a win. Negative experience with C++ exceptions may have motivated that design decision.

Rust has Resource Allocation Is Initialization (RAII). Go does not. For both languages, problems come up with resource release. Go has "defer()", which is kind of clunky and can't be encapsulated, while Rust has destructors called when something is deallocated. In both cases, it's hard to handle an error at resource release time. Destructors that do anything non-trivial are usually troublesome. Both languages have this problem. Languages with "with" (Common LISP's "(with-open-file ... ...)" and Python's "with FILEOBJ as HANDLE : " have fewer headaches with resource release errors, since they occur in ordinary code, not at some special destructor time.

<comment><USER44> In rust, can't you just use a {} block to force the scope limitation?

(I've just browsed the rust docs, never written anythign in it)

        fn do_stuff() {
          // already inside a function!
          {
            // allocate here...
            let x = Giraffe();
          }
          // should be deallocated by now. right?
        }

<comment><USER43> You can certainly limit scope in Rust. That's not the problem, though. The problem is, what if something goes wrong in Giraffe's destructor? Like maybe the remote procedure call to Zoo fails.

</comment></comment></comment><comment><USER45> goimports-on-save is an _essential_ tool in your writing environment for go. It's not mentioned in the official docs, but using it completely obviates fiddling with your import declarations ever again. While you're at it, you might as well turn go vet-on-save and go lint-on-save as well.

<comment><AUTHOR> Yeah, it's been mentioned to me in this thread many times :) I so wish I had known beforehand ;p

It would be nice to have a cheatsheet full of Go tips & tricks like gofmt/goreplace for replacing idents, and goimports-on-save, and whatnot. TBH I didn't really look for such non-in-built solutions when starting though, so I would have missed it anyway :P

<comment><USER45> > I didn't really look for such non-in-built solutions when starting

I can't fault new users for this; the non-discoverability of these awesome tools for new users is a genuine fault of the Go ecosystem.

Just a "Tips" or "Useful Tools" list at the end of the Getting Started page or the How to Write Go Code page would be better. Just to make users aware that such tools exist.

</comment></comment></comment><comment><USER46> "Unlike Rust, Go is really easy to pick up. It's possible to jump directly into it, and you can be writing useful programs after a single afternoon of messing around or reading."

I think it's safely implied that you put more effort into Rust code, but get more out of it. It's a tradeoff from Go. It's worth it for some programs, and others it's not.

Go for me doesn't work out because it's not C ABI compliant which is a limitation Rust doesn't have. As a language nothing draws me to it in particular. The killer feature is how easy it is to get started with it. Something that is undersold.

Coming primarily from Python I'm still favoring the field over Go until my problems matched Google's. I would probably reach for Erlang for concurrency and Rust for anything low-level going forward.

</comment><comment><USER47> The most important thing I took away was that Rust has enums as tagged union types; I cannot count the number of times I wished I had this in my day-to-day language.

</comment><comment><USER48> "Unlike Rust, Go is _really_ easy to pick up. It's possible to jump directly into it, and you can be writing useful programs after a single afternoon of messing around or reading. On the other hand, while basic Rust is easy to pick up, it takes a while to get used to the borrow checker (and in general understand ownership/borrowing). Additionally, most libraries make full use of advanced features (like associated types) and one needs to learn these too to be able to use the libraries."

This is pretty much why I consider these two to be in less competition than first meets the eye. Rust intrinsically involves putting more effort in to the code. You put more effort in and you get much more out, but there's a lot of code for which that's not the right tradeoff, just as there's a lot of code for which it is.

"In Go there's no obvious way to get this. The closest thing is the type called interface {} which is similar to Box<Any> in Rust or Object in Java.... Of course, I could implement a custom interface MyMessage on the various types, but this will behave exactly like interface{} (implemented on all types) unless I add a dummy method to it, which seems hackish."

I think most Go programmers stick to interface{}, but personally I put the tag method on the type, being from the Haskell side of the house on that front. In practice it turns out that often the "tag" interface grows a useful method of some sort, at which point it ceases to feel silly. If nothing else, you've got the ".Handle()" option. See also [http://www.jerf.org/iri/post/2917](http://www.jerf.org/iri/post/2917) .

Also, just generally on the performance front... developers who care about performance are at this point subconsciously pretty used to being able to choose between "language like Rust or C++ that really, _really_ cares about performance, but is hard to use" and "dynamicly-typed language that's really flexible and powerful but 50-100 times slower than the other choice". In the limit, Rust will absolutely be faster than Go, no question, but the performance penalty may be more like a factor of 2 in the end... Go's pretty fast, and while you can't go absolutely crazy with optimization C-style, you do get to play with locality optimizations with real structs and real arrays and such. Worrying about the performance differences between C and Python before you write a line of code may be perfectly valid, because the gulf is pretty large... worrying about Go vs. Rust is going to be a much narrower band of validity before you're just prematurely optimizing. Rather a lot of high performance code still has "vtables" in it, used quite extensively.

In practice, I don't expect many people to decide between Go and Rust based on performance needs on similar code... non-zero, yes, but not many. What expect people to choose between them are general software engineering complexity considerations. When it comes down to it, the reason to write Servo in Rust and why Rust needed to be created to do it isn't that there weren't languages that were "fast enough"... it's that the browser has bat-shit insane sharing patterns, complexity beyond the mind of any mere mortal, and you end up with code that either does way too much copying or crashes when it doesn't do enough, because there's no ownership management in the language. That's the sort of reason to choose Rust over Go. If you're making something that looks like a browser, or an office suite, or a big highly-integrated business workflow suite, or something like that, I'd choose Rust over Go in a heartbeat simply because Rust is designed to shine in that environment, and Go ultimately doesn't particularly offer anything to make that scale of that sort of code any better than any other statically-typed language.

<comment><AUTHOR> Fun fact: The professor who asked us to use Go in the course also knew Rust and Nim and in general liked programming languages. When I shared the original version of this article with him, he said this interesting tidbit (which I agree with wholeheartedly):

> ... there is no other language I can think of with such a small surface area > that I can tell students in the first week to learn and deliver an > assignment by the second week

...

> This is pretty much why I consider these two to be in less competition than > first meets the eye. Rust intrinsically involves putting more effort in to > the code. You put more effort in and you get much more out, but there's a > lot of code for which that's not the right tradeoff, just as there's a lot > of code for which it is.

I don't consider the two to be in competition (aside from "which hip new language should I learn today") either, though it's less due to the easy-to- pick-up thing and the Rust mentality that:

\- If it can be a footgun, be explicit (unsafe, exhaustive matching, unwrap)

\- If you can do it at compile time, DO IT DO IT DO IT DO IT (all the compiletime type safety, ownership, etc). All abstractions should be zero-cost or with minimal cost (at runtime). Try to write your code so that tests won't be necessary (because a successful compile should _be_ a test), and then write tests anyway!

(This mentality is pretty prevalent in both the Rust stdlib/language and external libraries. The equivalent of interface types in Rust (`Box<Trait>`) is generally frowned upon and only brought out when absolutely necessary, for example)

Go doesn't really embrace either of these principles, so it doesn't compete that way. You're right, developers already are used to making those choices.

> worrying about Go vs. Rust is going to be a much narrower band of validity > before you're just prematurely optimizing. Rather a lot of high performance > code still has "vtables" in it, used quite extensively.

Not necessarily. As mentioned before, the Rust way of doing things generally leads to a _lot_ of optimized stuff. Taking the vtable example -- Go code that I've seen uses vtabley things _everywhere_ (the stdlib is peppered with interface types). Using vtables isn't bad, but when you use it for stuff that could have been solved by static dispatch (for large codebases -- that can be _everywhere_ ), then it can become an issue. In Rust a vtable is a last-resort that people will grumble about before picking up and using (but will use it whenever absolutely needed). Sure, a single vtable isn't much of a performance optimization, but when all your APIs use static dispatch due to this mentality, the collective optimization is huuuge.

> In practice, I don't expect many people to decide between Go and Rust based > on performance needs on similar code... non-zero, yes, but not many.

For many applications, I agree. Systems programming is one where this doesn't apply, but for stuff like a distributed consensus algorithm implementation (which I was doing), both Go and Rust are perfect. And I'm pretty sure that if I'd had more practice in Go, I would have been confused which language to write it in. (Right now I love Rust and am not great at Go so of course I would use Rust if given a choice)

For stuff like a browser, it's not so much that there are batshit insane sharing patterns, it's more because a browser is huge and performance matters a LOT. (I think pcwalton above explains why better than I can)

<comment><USER48> "Not necessarily. As mentioned before, the Rust way of doing things generally leads to a lot of optimized stuff. Taking the vtable example -- Go code that I've seen uses vtabley things everywhere (the stdlib is peppered with interface types). Using vtables isn't bad, but when you use it for stuff that could have been solved by static dispatch (for large codebases -- that can be everywhere), then it can become an issue."

Yes, but by definition, we're discussing optimized code here.

[http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...](http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=rust&data=u64q)

Yeah yeah, benchmarks blah blah, but the point here is, compare with, oh, say, this:

[http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...](http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=perl&lang2=rust&data=u64q)

As I said and will repeat without blinking, Rust will always be faster than Go (and the problem in the shootout Go beat Rust on is in my opinion certainly simply an unoptimized Rust implementation, no question), but language deltas of 2x or 3x in practice are dominated by algorithms and IO far more often than 50-100x. For all the long list of reasons that Rust is faster than Go, all of which are true, they add up to much less than _developers are used to_. Intuitively, when you hear "go is slower than Rust because vtables and bad optimization and GC and its pauses and interfaces" you probably mentally expect Go to be like 10 times slower, when instead it's 2-3.

This is relevant because I don't think Rust advocates should sell "speed!" too hard as the primary thing they have... C++ will pretty much forever be able to keep up on the raw speed front, especially in benchmarks. What it has is _complexity management, at speed_. But complexity management first.... Rust could probably take a straight-up 2x speed penalty over C++ and _still_ write a renderer than ran faster than C++, because it'll be a _better_ renderer.

<comment><USER49> > unoptimized Rust implementation

 _Scotty! We need more CORE[s] ! "_

</comment></comment></comment></comment><comment><USER50> My hat is off to the author of this piece; what a beautifully written fair evaluation of two technologies.

Kudos.

</comment><comment><USER51> Here's part of why the interface thing is useful: it gives you dependency injection almost for free, and it allows modules to be extremely decoupled. You can create a module-local interface describing not just a "generic X" but "specifically what methods of X I want". That way you don't even depend on other object's types, but only on their permitted actions. And making mocks is very easy. The IO libraries use this extensively; they don't depend on where you're getting your IO from. They just require it does this or that.

Bonus, you can define "tolerable minimum" and "nice to have" versions of the same local interface. Define your methods in terms of the first, but attempt to cast to the second.

      if nice, ok := minimal.(Nice); ok {
        // do stuff only possible with the nice to have interface
      }

Example: the HTTP libraries will flush your IO if you give them something flushable, but they don't require it.

</comment><comment><USER52> It seems he approached this in good faith and gave an honest review. Which seems quite rare for people commenting on Go.

</comment><comment><USER53> I might be mistaken, but `func bar(){}` is not public, I think you meant to capitalise the "B".

<comment><AUTHOR> fixed, thanks!

</comment></comment><comment><USER54> My biggest gripe with Go: Unused variables. Unused anything doesn't let me go on with coding. It's obviously a design decision from the makers of Go, but the way I usually program is "experiment first, then clean up".

<comment><AUTHOR> We used to have `#![deny(unused)]` in Servo, and it was quite annoying. Especially because a compile takes a while and the lints run mid-compile (after type/borrow check but before the llvm stuff). Quite annoying, eventually we turned it off. But it wasn't _so_ bad; because when writing Rust code there's more fixing of type/borrow errors and less waiting for a full compile and running tests; since most of the "correctness" is encoded in the types used.

</comment></comment><comment><USER55> Regarding enum support, you can create type safe enums in Go like this:

        type Color int

        const (
          Red     = iota
          Blue
          Green
          Sausage
          Yellow
        )

The `Color` type is not compatible with int, so except for explicit casts and literal assignments, it's type safe.

Though that's quite a different enum style compared to the tagged unions of Rust, his approximation with interfaces is indeed closer to that.

<comment><USER56> but that's only a simple c-style enum. What the author is describing is a algebraic data type/sum type: an alternative between types with possibly different types (i.e., a Boolean, two strings, etc.). Read the example in the article closely and you will know what I mean.

</comment></comment><comment><USER57> Looks like an error in the Go code in the What I didn't like/No enums section. In the paintingLoop function the type assertion switch should be on the message and not the channel.

Should be "switch msg.(type)" instead of "switch ch.(type)"

<comment><AUTHOR> thanks; fixed!

</comment></comment><comment><USER58> Re: Go errors for unused imports

> This rules out some workflows where I partially finish the code and check if > it compiles.

Sounds like a great job for an IDE to automatically add/remove the appropriate imports for standard library stuff.

<comment><USER31> Goimport (i believe is the tool name, i use it for Vim) does just that. Also, because of the namespacing in Go, it actually works for non-standard library imports as well. It runs along with Gofmt on every save for me.

The only time in my experience that it has trouble is when there is a namespace conflict and it has to guess. Generally that's easy to avoid though, and uncommon.

</comment></comment><comment><USER59> The problem with Go is that you don't grok Go interfaces.

EDIT: downvoters, please explain what's wrong with my comment.

Go interfaces are quite a novel concept, and most developers that jump from language X to Go don't have enough time and experience to understand how they work, and how to design their application around this new model.

Their example of the messaging system/UI application is a straight port of the Rust code, and they lament the fact they have to use interface{} to overcome the lack of object orientation or pattern matching.

        func paintingLoop(ch chan interface{}) {
            // shorthand for a loop over receiving over
            // a channel
            for msg := range ch {
                switch ch.(type) {
                    case Quit:
                        // quit
                    case DrawLine:
                        // cast to a drawline message
                        line := msg.(DrawLine)
                        // draw `line`
                    case DrawTriangle:
                        tri := msg.(DrawTriangle)
                        // ...
                    case SetBackground:
                        bg := msg.(SetBackground)
                        // ...
                    default:
                        // Need a default case in case
                        // some other type is fed through here.
                }
            }
        }

This is not idiomatic Go. The author here should be leveraging Go interfaces and they wouldn't lose type safety.

        type Drawable interface {
            Draw()
        }

        type Line struct {
            x1, x2, y1, y2 int
        }
        func (l *Line) Draw() { ... }

        type Circle struct {
            cx, cy, radius int
        }
        func (c *Circle) Draw() { ... }

        func paintingLoop(ch chan Drawable) {
            for object := range ch {
                object.Draw()
            }
        }

        func main() {
            ch := make(chan Drawable)
            go paintingLoop(ch)

            ch <- &Line{x1: 10, y1: 10, x2: 50, y2: 50}
            ch <- &Circle{cx: 10, cy: 10, radius: 20}
        }

You wouldn't expect Python programmers to try Haskell over a weekend and have enough experience with it to write a blog post about "Thinks I dislike about Haskell", but it seems much to often people play with Go and, when they fail to translate their ideas to this new language, post yet another "rant" on HN about how Go sucks.

Go has its fair share of shortcomings, but try to _learn_ the language before writing yet another misinformed article.

<comment><USER60> > Go interfaces are quite a novel concept

They're not: [https://realworldocaml.org/v1/en/html/objects.html#ocaml- obj...](https://realworldocaml.org/v1/en/html/objects.html#ocaml-objects)

> This is not idiomatic Go. The author here should be leveraging Go interfaces > and they wouldn't lose type safety.

You've conveniently ignored the case of the non-drawing commands. Should they be Drawables with a Draw which does not draw anything?

> Go has its fair share of shortcomings, but try to _learn_ the language > before writing yet another misinformed article.

The OP has been upfront about his limited knowledge of Go, and his rust knowledge coloring his thinking.

<comment><USER10> > You've conveniently ignored the case of the non-drawing commands. Should > they be Drawables with a Draw which does not draw anything?

In particular, you can't implement Quit using a virtual method, unless you do something like have every function return a boolean to the caller indicating whether it wants to quit (or panic and recover, but that's too awkward for words).

You also can't have methods that set local variables in the caller, unless you do something like pass in their addresses to the function, which gets awkward quickly if you have a lot of local variables.

<comment><USER61> > You also can't have methods that set local variables in the caller...

How would you do that using ADTs?

<comment><USER10> You don't use methods, but instead switch on the discriminant of the ADT and take different actions (such as updating local variables).

This is pretty related to the so-called expression problem. OO-style methods are good at extensibility, but they're bad at adding extension points (method calls), since you have to update every one and calls are limited in expressive power compared to the body of a switch statement. Functional-style ADTs are bad at extensibility (adding a new type requires updating all pattern matches), but they're good at adding new extension points, since you don't have to touch the data types and pattern matching is powerful. Supporting both styles in a language gives programmers the freedom to choose the best one for the task at hand.

<comment><USER61> Makes sense. Thanks.</comment></comment></comment></comment></comment></comment>


Forrst releases new invite system & notifications - <AUTHOR> http://blog.forrst.com/post/5138975423/on-the-forrst-invite-system

<comment><USER2> Forrst is a 500startups company. How are things progressing with that?

</comment><comment><USER3> Hopefully this will help with their backlog. One problem I have with the way the invite system works now is there's very little feedback once you request an invitation.

I requested one a few months ago and I haven't heard anything about it since, not even a single email. As far as I'm concerned I'm stuck in the limbo of their backlog.

A yes/no answer would be preferable to limbo. Or perhaps allow Forrst members and/or the requester to comment on invite requests?

<comment><USER4> Same here, been about 2 months and didn't hear anything. Just sent a new one, already seems much improved in that you get an application url. However, part of the application is critiquing a visual design - that seems biased against developers. There are definitely some very talented developers who would be great members of the community but don't know anything about graphic design.

If anyone would be willing to vote a fellow HNer here's mine: <http://forrst.com/i/5uz>

Sidenote: There's is something to be said for the allure of exclusivity in these types of networks. Also, perhaps requiring a community vote / interview process before allowing write permissions on HN could be a way to stem the decline there's been so much talk about lately. Perhaps a short form of the yc application to be voted on.

edit: bout 40 minutes later, I'm in. thanks anyone who voted.

<comment><USER3> It took a lot of loading new posts, but I finally got a snippet of C++. Right now it does seem like there are a lot of images. Maybe one way they could improve the process is by having different pools of posts for developers, designers, and developers/designers.

</comment></comment></comment><comment><USER5> Well, the new system seems to be working with dramatically different speed. I just applied and became part of Forrst in the span of about five minutes.

</comment><comment><USER6> Great news. Now can we have the API?

</comment><comment><USER7> I am interested to get on here and take a poke around, and possibly increase the developer presence. Any fellow HN people care to vet my invite?

<http://forrst.com/i/5u2></comment>