And Android, all of the ad stack, analytics (it gives google a lot of data), chrome, maps, docs, drive (in some form), calendar, app engine, hangouts (part of gmail). There are tons of products that are both successful, and are tied to core things google wants to be good at.
ChromeOS is open sourced and will still be available for some time, but yeah, they're merging the two. Ubiquity between Android and desktop/laptops would be great.
How would that help them? It doesn't seem like they have any incentive to prevent more people from using the JVM. In fact, I would imagine they want more people to use it, and multiple languages compiling to it makes it more popular.
I'm unable to get it to run either. Turning text into tokens is something I've wanted to be able to do in golang before, so it would be super nice if it was easy to install with `go get`. I still need to work through some of the other libraries here: http://biosphere.cc/software-engineering/go-machine-learning...
If you just want to segment larger blocks of text into tokens you can try the segment library (it implements the word boundary portion of unicode annex 29):
If you need more manipulation of tokens after segmentation/tokenization, you could look at the analysis sub-package of bleve. Its intended to be able to be used indepenently of the rest of the library.
Eventually docker-machine will deprecate boot2docker-cli (the piece which you use to actually manage the VM). However, boot2docker-cli is (mostly) pretty stable and a lot of people use it (including me), so we don't want to toss it out overnight or without a good migration path for b2d users.
boot2docker sets up a virtual machine with docker. Machine does this too, but it also allows you to choose a cloud provider, instead of only your local machine.
It would be really nice if we could see the source code for this site to see the selection criteria.
It definitely seems random. It's not just showing new projects created on a given day, because I see projects that are really old. Is it checking for projects that are small and recently updated, maybe?
I've used this in the past for manipulating data on the fly for testing and it worked out nicely. I wrote a little program that can redirect requests, so instead of going to production they go to a local server or to a QA environment. Helpful for testing javascript libraries that get included in third party pages around the internet (like Google analytics or ad code).
Goproxy was really performant and easy to use compared to other solutions. (https://mitmproxy.org/ had some performance problems/memory leaks).
mitmproxy keeps all requests in memory, so that you can browse them quickly. If you want better performance, you can just swap "mitmproxy [args]" with "mitmdump [args]" and get all features in a headless mode which scales well and keeps a low constant memory profile.
I disagree. It's more a question of do you want to spend engineering hours updating all your tools to the latest version, or do you want to spend engineering hours developing features. Different organizations have different priorities. Many times new versions give you features that are worth the effort taken to update. In most cases I'd rather not use technology that is continually breaking my code on every update, and instead focus on solving interesting domain specific problems. It's flawed to say that this means the culture is "fucked up".
Scala simply doesn't move that fast and doesn't break that often. I can say that as someone who has been using it since 2.7. (Some of the thirdparty Scala libraries on the other hand will are close to giving me aneurisms ...)
At its current velocity, Scala is hitting a sweet spot in between improving language features and dropping cruft. The way you can change language features via imports is awfully nice a well.
Note that most of the major library providers for Scala jump on the new versions of the language while it's still in the milestone stages of development. Examples are scalaz and akka.
It's not just simple stuff either, often major libraries will have specific versions that work with specific releases of the language. No matter how well engineered your code base is, if you have to change apis that you use throughout your code as well as cope with languages changes too, it's going to be a lot of work for relatively little business value.
> It's more a question of do you want to spend engineering hours updating all your tools to the latest version, or do you want to spend engineering hours developing features.
How is this different from e. g. Java? Developers pick a version which works for them and stick with it until it makes business sense to upgrade.
> In most cases I'd rather not use technology that is continually breaking my code on every update, and instead focus on solving interesting domain specific problems.
I've been developing Scala full time since 2.7. I have not had a release yet that didn't involve changing code to recompile to each new version.
I also have Java projects that were written in pre 1.0 releases that have updated to 1.7 without a single code change.
This is due to a different set of priorities. Each of those priorities has different costs and benefits but to act like Scala's lack of backwards compatibility doesn't have a cost is unfair.
