ama

nomies of scale. If it's your intent to just play around, a Raspberry Pi might be a fine choice, but a Raspberry Pi plugged into the wall isn't close to a proper server setup. > the network isn't that relevant when going this low, since you won't be serving anything substantial out of it Firstly, that's not necessarily true. If you're running something like an SFTP/FTPS server, you might make good use of the connection speed, despite only using a lightweight VM. Even if you're hosting a proper Web 2.0 site, an efficient architecture goes a long way. HackerNews and StackOverflow use famously few servers, for instance. Secondly, a lot of ISPs are hostile to web hosting from home connections, so a Raspberry Pi might not be an option even if you're only hosting a 'toy' site. Thirdly, it's not just performance, it's also reliability. AWS invest in redundancy and robustness. A home/small office connection isn't in the same league. > getting into the cloud without using any cloud-native features isn't money well spent If you can get a serious virtual/physical server for a better price elsewhere, that might be worth considering, sure. GitHub does this - they're hosted with a company called Carpathia, rather than with one of the major cloud providers. [0] The 'cloudy features' of a platform like EC2 are powerful though, features like automatic recovery from hardware failure, the ability to easily change the hardware spec of your instance with just a reboot of downtime, the ability to easily transform your virtual HDD into a virtual SSD, etc. [0] https://github.com/holman/ama/issues/553

are of the server question (apparently they use a physical-server provider called Carpathia [0]), and because git always needs to be available but is only used rarely, the amount they charge you is probably less than the cost of running a dedicated server for the purpose. And all that is assuming that a self-hosted GitLab is just as good as GitHub from the developer's point of view. It may or may not really matter, but GitHub is probably the more polished and feature-rich service. Building a competitor to GitHub is possible, but not trivial, see SourceHut. (We've been talking about GitHub, but of course they're not the only Git provider.) I can see only a few situations where it makes good sense to run your own Git/GitLab: 1. Your Internet connection is slow and/or unreliable 2. There are extraordinary safety/security concerns associated with your source-code (military avionics code, say) so you want to run Git in an isolated network (no Internet connectivity at all) 3. Related to point 2: You don't want your organisation's data to reside in the USA. (To my knowledge GitHub don't offer any choice about this, but I could be mistaken.) For the average developer though, I don't see much upside. Having more control isn't a compelling advantage, it's another way of saying you have more obligations. [0] https://github.com/holman/ama/issues/553

contributors on the project. Frameworks like Rails give you so many security, development, and deployment niceties that I have zero interest in rolling my own anymore. (I saw a "screw frameworks" Go talk that spent ten minutes on how to reload code in development, for example... that was a solved problem for me in 2005.) I'm kind of in love with the idea of writing everything in Ruby (or something similar) and when it makes sense and can be provably improved, extract it out in something like Go or C. The Go+Ruby combination in particular is super attractive to me, and it's likely going to be fine for the foreseeable future, I think. --- [1]: https://github.com/holman/ama/issues/698#issuecomment-118958... > The recent post from Parse Engineering Team [...] if you look at GitHub also, the number of Ruby repos are getting lower over these months. I think looking at these examples don't the whole picture here. GitHub, for example, is a fairly feature-complete product, and their next few years will likely focus on optimization work. If you have a mature product, you have a very clear performance profile of what's breaking, what's fast, and what's slow. That's why GitHub, a seven year old company, is more likely to open source Go libraries at this stage of its life rather than Ruby libraries (for example)- it's obvious which use cases can be targeted for speed, maintainability, and shareability. Parse is another clear example of this- they have a codebase that they've worked with for quite some time, with obvious spots of improvement, so they switched to Go. If you're looking at new companies that need a fair bit of creativity, product development, and development speed, I think Ruby makes a lot of sense. Premature optimization is not just a waste of time, it's an exponential waste of time, as you might head in a wrong product direction that can potentially sink the entire company. > I am wondering what's will be the next language gonna rule like PHP. Though there are JS tech is in the peak, I still not convinced to use it on server side. Go and Rust looks promising. I'm really the wrong person to ask here, but I can't really imagine anything taking over like PHP did for the next five years or so. That was a pretty meteoric explosion, and there weren't a lot of clear and open source options fifteen years ago. I don't see JavaScript development being a flash in the pan, I think Go is clearly going to continue to increase in popularity, and I think languages like Ruby and Python and PHP will probably hit a decent cruising speed for the time being. Even .Net technologies have a brighter future ahead of them again. There's a lot of choice right now, there's a lot of resources flooding into open source from companies who clearly want to compete in the community, and there's a ton of stealing of good ideas between communities rather than getting siloed off in the past. A decade from now, yeah, things may be completely different, but for the time being there's a lot of exciting choices and options happening. Kind of love it.