Hacker Newsnew | comments | show | ask | jobs | submit | joewalnes's comments login

A very tiny shell script: https://github.com/joewalnes/go-getter

Like go get, but you specify exact versions, including transitive dependencies. One GOPATH per project. And most importantly, you don't have to use go get to install the tool in the first place.

-----


Dave thanks for doing this. Not just for building the tool but for a very well thought out and convincing presentation.

I'm completely with you. My own solution has similar ideals (per project versioned deps) though a different solution. https://github.com/joewalnes/go-getter/blob/master/README.md. Honestly I'm just glad others are finally talking about the elephant in the room.

-----


Very slick! Love seeing Python built games like this. Well done, sir.

-----


Thank you! My love to Python started with this game. Though now I'd rather use something like C++ and Lua for games. It'd make it much easier to port and distribute.

-----


javascript.. the actual wora.

-----


Good point, I actually considered Javascript too. Though it seems like there's no one-size-fits-all tool, but right tools for right problems. I'd use Javascript for in-browser games, but something different for standalone ones if high portability is the requirement. Lua seems to be a good choice, because it's de-facto industry standard in gamedev and runs on anything but my door bell (http://luajit.org/luajit.html). So my current best idea is to write all control logic in Lua, and platform-specific low-level stuff in C++. Regarding the speed concerns, both Javascript and Lua have JIT, and anyways, no Lua or C++ code should be visible in the profiler at all if we're talking about performance. It seems to me most computations should be done on GPU instead.

-----


Words cannot describe...

-----


This is a slightly modified snippet extracted from something I wrote last year predicting the Google Code shutdown. https://medium.com/@joewalnes/some-2015-tech-predictions-1e7...

------------

It's not about Mercurial vs Git.

When Google Code added Mercurial support, Mercurial and Git were roughly equal in popularity. Git was more functional, but Mercurial was a lot simpler to use. In fact, almost everyone I spoke to at the time preferred Mercurial and honestly I thought it was going to be the winner. Project hosting sites that had typically used centralized source control systems like CVS or SVN scrambled to add Git and Mercurial support (including Google Code).

Then GitHub happened. They realized that the it's not just the source control system that should be decentralized but every aspect of the project. Projects could be forked with a single click, pull requests created and tracked, network graphs explored. It created an organic and discoverable open-source ecosystem, the likes of which we never saw on Google Code, SourceForge, etc. Anyone could explore ideas in existing projects without having to gain committer access. It was magical.

GitHub may have just as easily decided to bet on Mercurial instead. I believe if that would have happened, Mercurial would be the most widely used system today. BitBucket did something similar for Mercurial and did pretty well, but GitHub always had the lead.

It was the project hosting sites that lead the source control systems, not the other way round

So, back to Google Code. It could have been something huge and it could have made Mercurial the winner, but Google Code never grokked the importance of "social coding". Even though the source code was decentralized, the projects themselves were still centralized. Decentralized project concepts such as forking, network graphs, pull requests, etc - this was all from the new world of GitHub.

Over the past two years we've seen Google release new open-source projects on GitHub, then existing projects starting to migrate. Recently, Go started migration too — this is no casual move because it affects the import paths used in a vast amount of user created Go code which will build breakages. Yeah, the writing is on the wall for Google Code.

When SourceForge fell out of favor it was sold. It’s now filled with ads, especially deceiving ones on project downloads page which try to trick users into downloading some malware infested turd burner. In fact, for a while SourceForge were actively modifying genuine project releases to include spyware. Cocks.

Google didn't do a SourceForge. If there's anything we’ve learned from Google over the years is that they’re not afraid of shutting down projects that don’t work out. By the way, I really respect Google for this — killing products takes guts.

Google Code — I salute you. You did well, you made the open source world a better place, and above all you stepped aside when you knew the time was right.

-----


Codehaus was the birthplace of many Java open-source projects last decade.

Enterprise Java was becoming mainstream, but the open-source community saw that it had much more potential than the tools provided by Sun.

Codehaus provides project hosting (source control, issue tracking, websites, continuous builds, downloads, mailing lists, IRC, etc). This was back before GitHub existed and the only other option was SourceForge (which was terrible).

But above all, Codehaus provided community. The developers across projects all hung out together, on mailing lists, IRC and the occasional global meetup. Respect and friendship. It was there that many gripes and problems were discussed and new projects were born.

If you've ever benefitted from Groovy, Jetty, Grails, Gradle, XDoclet, XStream, jMock, EasyMock, QDox, Drools, Esper, Mule, PicoContainer, Jackson, Janino, JBehave, Stomp (and hundreds others), this was thanks to the Codehaus community.

Many of the projects and people have gone on to do great things. Companies have been formed. New communities created. Many projects died, some thrived. Codehaus is no longer the hotness it once was, but it provided the foundation that many of us have benefitted greatly form, and it's no doubt one of the giants that the Java open-source community is standing on the shoulders of.

Codehaus is now shutting down: http://codehaus.org Please join me in raising your glasses to the people and projects. Codehaus, we salute you. So long, and thanks for all the fish.

-----


Just to add to that list of projects, Maven Central shows more than 2000 artifacts for codehaus:

http://search.maven.org/#search%7Cga%7C1%7Ccodehaus

-----


Yes, I often have 10K plus processes running on a production server. It's caused troubles at time due to misbehaving processes, but mostly it's been ok. Linux is surprisingly good at this (wasn't always the case).

For the times when some of my processes were misbehaving, it was easy to identify which processes were misbehaving with "ps", "top", etc and resolve with "nice", "kill". This killed the bad connections without bringing the rest of the app down. Sysadmins like me.

-----


Have you been waking up all 10K of them at a time? Handling 10,000 sleeping processes is not so surprising.

-----


websocketd treats each line as a message. i.e. boundaries are marked with \n

-----


Yep. The only magic thing is a line break (e.g. \n) is used to terminate each message.

-----


ed is for the weak. Real developers edit bits using the magnetic forces of oceans.

-----

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: