Why we switched from Python to Go - <AUTHOR> https://getstream.io/blog/switched-python-go/ <comment><USER2> Python was my entry into the programming world, and I've been an evangelist ever since... Or I was until I ran into distribution and parallelism. Since then, Nim has been my go-to language of choice. It is all that Python was, plus unbelievable speed, compiling to shippable binaries, and some other cool language features that admittedly, are still beyond my scope of abilities. Still quite lacking in libraries compared to Python, but after a few attempts (perhaps halfhearted), I never felt "Go" was a suitable replacement.

<comment><USER3> For me, the ecosystem matters as much as the language itself these days (actually more). There are languages that I've used at home just as a learning experience, but ideally, I want a language that I can put into production at work. That means quite a list of criteria: only a small number of languages have a well-supported AWS SDK, for example.

I won't say that Go is mainstream yet, but it feels very "production-ready" in those respects.

<comment><USER4> I'd say that simplest "production-ready" criterion is this: does it have an officially supported and stable release of a IntelliJ IDE (there is a slight Java-ecosystem bias, but I think it's only slight).

So the mainstream languages are...: C/C++, C#, F#, Go, Groovy, Java, JavaScript, TypeScript, Kotlin, Objective-C, PHP, Python, Ruby, Scala, SQL, Swift, VB.NET (source: [https://www.jetbrains.com/products.html](https://www.jetbrains.com/products.html)).

Sounds about right :)

<comment><USER5> So, from the top of my head, Erlang, Haskell, OCaml, Perl, Fortran, Cobol and any type of shell script is not production-ready. Nice to have that clarified. :P

<comment><USER6> They may be production ready, but have a quite small ecosystem compared to other languages mentioned.

<comment><USER7> Do shell and Perl really have a "small ecosystem" compared to something like Groovy?

</comment></comment></comment></comment></comment></comment><comment><USER8> >Go forces you to stick to the basics. This makes it very easy to read anyone's code and immediately understand what's going on.

I'm not criticizing Go since I have no LoC in it, but in other restricted-and- flat languages and areas our company's expertise quickly (read: in half a decade) went to the limit with no chance to turn the lang partly into dsl and level up. It is like playing rpg where you stuck to level 5 and never get powerful enough to take middle-level quest even with a great party.

While it seems cool to have automatic jsonification, build process and out of box concurrency, inability to create something that only your team can use and understand effectively means you're locked to growing markets (bubbles) and never have real expertise and/or budget over bloated competition. This may play a bad game with your future, should roads cross with one who has.

Again, the type I'm talking about must be rare, and "there is only one opinionated way to do it" seems to fit better on average tasks.

<comment><USER9> I understand what you mean by "inability to create something that only your team can use and understand", but the article doesn't say anything about that and isn't really addressing developing new code in Go. The article is about Python not matching their needs after a few tries at optimization and Go having a similar development time (although if the code was already implemented in Python then I assume the Go code was almost trivial to write so I'm not sure that was a valid point).

As for "'there is only one opinionated way to do it' seems to fit better on average tasks", from the Zen of Python: "There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch." And Python has been used to do plenty of above average tasks.

<comment><USER10> At a high enough level, Python does not live up to that zen. It does not restrict how you will organize your code, it just restricts instruction level options.

Keep in mind that the Zen of Python is mostly about how Python differs from its ancestors (basically, Perl). It's not a work on software engineering.

</comment></comment></comment><comment><USER11> I'm surprised to see Go's error handling listed as a disadvantage. Go encourages writing good error messages, and that's one of my favorite things about the language.

To get a sense of it, take a look at a failing test in a language such as Python that uses asserts for testing and compare it to the equivalent written in Go. Quite often, the error message in Go will be clear and to the point. On the other hand, I've seen plenty of assertion based tests in other languages that report inane things like "1 != 2" or "true != false" when they fail.

Go encourages putting the effort into this up front. It pays off later when things go wrong and you want to know why.

<comment><USER12> Probably complaining from someone used to exceptions and/or assertions, where there is perhaps less boilerplate and manual verification that context bubbles to the right place.

You can get there either way, but what you're used to weighs heavily.

For your example, depending on my experience, knowing that 1!=2 in some code I'm using directly might be more meaningful or actionable than "out of filehandles for accept()" in some deep chain of dependencies I know little about. Just depends on what you're used to.

<comment><USER13> Or anyone who's used a language where errors aren't as stringly-typed as Go and where the compiler can enforce error handling. Exceptions have benefits and drawbacks, but any language that can return a Result type will have better error handling than Go in basically every way.

<comment><USER14> In Go, `error` is an interface, which means you can return anything that implements the `Error() string` method as an `error`.

<comment><USER5> Yeah, but 99% of libs won't return anything with additional accessible structure.

<comment><USER15> Yeah I think the point is, errors shouldn't be overloaded with too much extra structure. They should be errors. If additional structure is needed, it should probably be sent separately via the common multiple returns idiom in Go.

<comment><USER13> Additional structure like, say, a numeric error code? An HttpError could definitely contain the corresponding status code.

But I think the bigger point is that, for libraries, errors should be an enumerated set of possible error conditions, not strings. You say "additional structure", I say the duplicate filename, the invalid email address or, crucially, the error that caused the error...chaining errors is very useful. The multiple returns idiom in Go may make this possible, but it's hacky and strictly worse than languages that can utilize generics and a more richly- typed set of errors.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> How do these shallow articles get upvoted so much ? they don't have much specific information except very generic "developer productivity".

Let me give a specific example where moving to Go really helped our tooling:

Go has some great interfaces, specifically their net & ssh client. In order to perform operations against some machines, we have to tunnel through bastions, however we'd also like the tool to work when an operator has already ssh'd within the region (the tool is installed on hosts as well -- so that long running tasks can be performed).

It was easy to create HTTP clients that easily tunnel through an SSH connection via Go's Dialer interface (present in the net & ssh package) or just directly if no tunnel was needed.

<comment><USER17> Actually moving to Go was a very thorough and long process. We did small example projects and tried out many of the libraries we needed. The blogpost is more of a high level summary of why Go is such a great language.

<comment><USER18> Did the Go implementation of the ranked feed use the algorithm optimizations discovered while optimizing the Python implementation?

<comment><USER17> No most of the optimization were Python specific. But of course development time was a bit faster due to it being the 2nd time solving the same problem.

</comment></comment></comment></comment><comment><USER19> Why does anyone write web apps in Python? PHP? Ruby?

Modern Java and Go are so much faster than the alternatives that it's stupid to consider anything else if performance is important.

Golang and Java can manage over a half million HTTP responses a second. Node is pretty fast but why bother when Java is many times more mature in features, tooling, and and supports concurrency... And uses less ram and is usually faster. People moan about the "huge" Java runtime when JavaScript uses 3-5x more memory and has a huge runtime of its own.

All the big companies are using Java and Go almost exclusively for high volume endpoints and it blows my mind the amount of mental gymnastics some companies go through to avoid following suit.

Java has come a long way since J2EE. These days it's asynchronous, non- blocking, serverless, etc.. pretty much all the acronyms thrown around about node except its not JavaScript, which IMO is a huge win.

<comment><USER20> _Why does anyone write web apps in Python? PHP? Ruby?_

First: Because squeezing every last nanosecond's worth of performance out of your web app is actually an extremely rare problem to have. And if you truly cared about performance over programmer convenience, you'd practice what you preach and build your web apps in hand-rolled assembly, but I'd bet a lot of money that you don't do that.

The typical web application -- I'd be willing to bet over 99.999% of all deployed production web applications serving requests today -- has a bottleneck at the database and the network that dwarfs any overhead from language performance.

I remember a bit over ten years ago when there was debate in the Python web world about which templating engine to use to generate HTML. And people argued endlessly over microbenchmarks of them, to figure out which was fastest, but I remember one blog post which showed a pie chart of time spent in the average request/response cycle. Nearly all of it was accessing the database, and template rendering was a tiny, tiny sliver, so the author humorously labeled it "obviously _this_ is the part we need to focus all our optimization work on". Language choice is similar.

Second: Because what else your company does matters. Where I work, web applications are how we expose data and interfaces to that data. But there's a gigantic stack behind that, of data intake, data parsing, data processing, analytics, the whole nine yards. It's all in Python, because Python has hands- down the strongest ecosystem of any popular programming language for that stuff. So the web applications which serve as the interfaces to the data are also written in Python; it means we have one language to worry about, one language to work in, one language every software engineer knows. I've been pulled onto projects doing things that didn't involve web applications at all, and I've been able to be productive because those projects were still in Python, and I could read code and get up to speed on what was happening, and take care of mundane things for a more domain-experienced person whose domain expertise was then free to apply to things I couldn't do.

Third: Because programmer convenience really and truly does matter. When I first started doing this nearly twenty years ago, people posted comments like yours, incredulous at the idea that someone would use PHP or Perl given their performance characteristics compared to Java (or C -- plenty of web apps used to be written in C!). But even then we knew: servers are cheaper than people. The average salary of a quality software engineer (or "web developer" as we were known then) would buy you a lot of compute time, either on your own (in- house or colo'd) metal, or nowadays on someone else's cloud.

So you choose based on convenience to humans. PHP, for all its faults, was an _incredibly_ convenient language to write web apps in, and compared to the usual CGI model that preceded it, was a breath of fresh air when it took off. Today, frameworks written in Python, Ruby, PHP, etc. are similarly in a good position compared to more heavyweight things like the Java world (which for better or worse is still suffering the lingering effects of its mid-2000s "enterprise" reputation), or even Go (which is still young and still seems to come up short, both language- and ecosystem-wise, on some of the things actual working web programmers want. In particular, programmer-friendly ORMs in statically-typed language really really _really_ want generics or a good equivalent, and Go's historic attitude toward that has not been great.

<comment><USER21> > _And if you truly cared about performance over programmer convenience, you > 'd practice what you preach and build your web apps in hand-rolled assembly_

The performance gain from Python/Ruby to Java/Go is an order of magnitude larger than the performance gain from Java/Go to assembly. The productivity loss from Python/Ruby to Java/Go is an order of magnitude smaller than the productivity loss from Java/Go to assembly.

Therefore, going from Python/Ruby to Java/Go _might_ be a good idea for web apps, but going from Java/Go to assembly is virtually _never_ a good idea for web apps.

<comment><USER20> If you're disregarding programmer convenience in the name of performance, then do it. But once you make the decision to trade off some performance for convenience -- no matter how much or how little you give up/get -- you start losing the high ground for preaching to others about how they should refuse to trade what you see as inappropriate amounts of performance for convenience, because now you're just arguing matters of degree and unquantifiable personal taste.

</comment></comment></comment></comment><comment><USER22> > Python, Node and Ruby all have better systems for package management

Maybe they have better tools for managing package dependencies but Go doesn't have to deal with interpreter dependencies, which can be a major headache. Go also doesn't have the problem of conflicting system level packages.

Honestly no matter how good your deployment practices are, if you have to manage an application's deployment long term you're going to have dependency problems of some kind. I'd rather deal with those problems at compile time than hit an edge case during deploy or in prod.

<comment><USER23> > conflicting system level packages

In Python, if you have control over the target system, this is solved with virtualenv. You can install whatever versions of libraries you want in there with pip without causing conflicts with system level packages.

If you intend to ship to end-users, yeah, you are kinda screwed. You are stuck using one of the various "freeze" methods, which, in my experience, kinda blow.

<comment><USER24> > this is solved with virtualenv

Except when you run into edge cases, which happens all the time.

<comment><USER25> elaborate?

<comment><USER26> Most of the time pip installs work fine, but once a while after some type of OS upgrade (namely, my experience has been MacOS), you run into odd compiler types of issues.

So it's why a lot of teams will use either Vagrant / Docker to setup local developer environments.

<comment><USER27> Can confirm that once upgrading macOS required using Docker to be productive, because some C-dep we had stopped working. We have developers using macOS 10.10 to avoid any issues (although they're likely gone by now, it's not worth the effort to figure it out anymore).

</comment></comment></comment></comment></comment></comment><comment><USER28> A thing that REALLY turned me off in go...

The fact that go's Math functions only work with floats. Idiotic.

You have so many packages that have to add the same freaking min(int a, int b) function.

<comment><USER29> Does Go have templating?

<comment><USER30> Templating is built right into the Stdlib [https://golang.org/pkg/text/template/](https://golang.org/pkg/text/template/)

The only 3rd party library I pull in to build web servers is gorilla (routing, sessions) and a database driver .

Everything else you need is in the go standard library .

<comment><USER31> I believe the parent means templating in the sense of generic types: [https://en.wikipedia.org/wiki/Template_(C%2B%2B)](https://en.wikipedia.org/wiki/Template_\(C%2B%2B\)).

</comment></comment></comment></comment><comment><USER32> Wait just one minute, Thierry...

Are you telling me that Python helped you create a viable tech-oriented newsfeed and activity stream business, serving 500 companies and more than 200Million "end users"? That sounds like a great incentive for any entrepreneur to get started with Python.

You've gotten this far by using the language you've turned away from! Further, I'm confident you didn't solve every challenge you've had on your own but rather did so with the help of the worldwide community of Pythonistas who answer questions and help to solve problems.

It takes a village to raise a startup. Don't try to burn the village down after you've grown up and can afford to explore other villages.

<comment><USER33> Hi, Jelte from Stream here. The post was definitely not meant to indicate that people should stop using Python. We still use it happily for the website and I'm still a big fan of it myself.

However, for the API we've outgrown it in performance requirements. That's what the article is about, together with the things we found during the switch that we liked and disliked about Go.

<comment><USER34> I would love to hear your experience in two years though. I find the go runtime incredibly lacking in terms of introspectability. That's okay if you run google scale operations where you just throw away the environment on deploys and you do not care about the individual processes, but if you are running a reasonably lean operation the ability to see what a process is doing is incredibly helpful. That even affects simple things such as error reporting which is almost useless in Go to debug issues at runtime.

<comment><USER35> These are good points. Stack traces in Go are a matter of discipline while they're free in Python. That said, I think Go brings a lot to the table even for a lean operation which more than compensate for these weaknesses. Probably the biggest advantages are that Go deploys as a single binary, and one Go process is sufficient to make efficient use of the machine's resources--no need for something like it's uwsgi. At our small Python shop, we probably have two full time positions dedicated to managing our Python installation process. This could conservatively be halved with Go. Beyond that, we have a couple more full time positions for managing the fleet of servers required to run or applications--Go could easily reduce our machine demand to 2 or 3 (including redundancy) which would probably require just one engineer to maintain not to mention the savings on our AWS bill. These are just a couple of obvious benefits to Go, but for us this isn't enough to justify a rewrite.

</comment></comment></comment></comment><comment><USER17> Author here. Super cool to see this post on HNews.

For those of you working with Go. One of the guys on our team wrote a little tool called VirtualGo. It's pretty handy when you're working on multiple go based projects ([https://github.com/getstream/vg](https://github.com/getstream/vg))

<comment><USER36> Thank god something like this exists. I _gagged_ at the workspace structure when I first started Go - it gave me enough pain starting out one weekend that my interest faded away. I've been looking for a reason to try it out again and a bunch of comments here got me really excited again.

</comment></comment><comment><USER24> I think there's a great value in code being straight forward and simple and that is very much not appreciated among many programmers.

A good language enables you to "compress" your code without making the code flow impossible to follow.

A bad language encourages you to obfuscate the flow of the program using wacky abstraction techniques.

Go doesn't exactly hit the sweet spot for semantic compression due to lack of compile time programming (aka generics?), but it does a good job of making the flow of the program pretty clear.

<comment><USER37> I tried using Go this weekend and basically just abandoned it when I learned that it only had 'generic's for three built-in types and other than that you are forced to essentially dynamic cast everywhere.

I just don't get the appeal. Go seems a lot like what you'd get if you just removed every language feature that anyone has ever complained about; for good reason or not.

<comment><USER24> It seems like the domains where Go is used often don't make heavy use of custom containers or data structures, so that makes the pressure on the language makers lower than it would otherwise be.

<comment><USER38> Or the other way around.

</comment></comment></comment></comment><comment><USER39> Thank you for the insights on Go and how Go has added value to your organizations and enabled a better environment for development at your organization! I love hearing viewpoints on tradeoffs and general evaluations on value of new(ish) development technologies.

I'd also like to point out that I write this a Python-phile that has come to the understanding that Python is great until it isn't. When Python becomes to burdensome, the understanding of the problem delivered by my Python sketch helps to narrow the focus of what I need to solve the problem efficiently. By that time, Go has never been the correct tool _for me_. I'm comfortable writing solutions in C, Rust and Java, perhaps this is my problem.

Whenever I read or write Go I don't understand how it managed to capture the mindshare that is has. Especially in the face of other technologies available, Go seems like a timid step forward in descriptions of computation, when there are bolder choices that deliver valuable additions to my development ecosystem.

I appreciate that Go places a premium price on simplicity, however with languages like Rust make some big steps towards static guarantees at compile time the guarantees that Go makes seem pretty weak. But I feel that when I make the leap from Python to Go, I admittedly don't understand the allure. Static compiltion is really nice! Statically linked binaries for distribution is very nice! The tooling is out of this world! Hands down, Go has one of the best out of the box toolchains I've ever encountered. But when helping me think about computation, Go doesn't.

Go's concurrency primitives don't feel like a great deal of a step forward compared to C. I know, I know, this is crazy talk. I feel like I am missing some great wisdom about Go, I truly do. Concurrency is really hard and Go has clearly helped a lot of people minimize concurrency problems. But whenever I use channels I am reminded Go does not allow me to shut my brain off, and whenever the deadlock bug strikes, I feel that I might as well be writing C.

I don't mean to disrespect Go and the great things it does, the opposite of that! I am hoping Go delivers a bulletproof abstraction for concurrency. Until then I've become too familiar with other tools to justify using Go for more than incredibly niche use cases. I really hope that will change (both my mindset and Go)!

<comment><USER40> > I appreciate that Go places a premium price on simplicity, however with > languages like Rust make some big steps towards static guarantees at compile > time the guarantees that Go makes seem pretty weak.

Rust's static guarantees come at a price: You have to learn Rust to take advantage of them, which is apparently no mean feat.

> I am hoping Go delivers a bulletproof abstraction for concurrency.

Don't hold your breath. Go has always been and will always be about "good enough", not "bulletproof".

</comment></comment><comment><USER41> >Reason 3 – Developer Productivity & Not Getting Too Creative

There is a time and place for these tools. A part of managing a team is ensuring there are good practices around "getting creative" and that there is a clear rationale. Python's metaprogramming came in handy for helping us provide a high level syntax to work with our data model.

<comment><USER42> I'm happy that Python's metaprogramming came in handy for you and your team, but Python's propensity for DSLs is one of the reasons I loathe it so much. I guess in the context of data science, a DSL makes sense, but it's a nightmare to debug.

<comment><USER43> > I guess in the context of data science, a DSL makes sense, but it's a > nightmare to debug.

What do you think struct-tags are? it's not like Go is free of DSL either. In fact the std lib itself uses them. Let's not pretend Go is without fault on that matter.

</comment></comment></comment><comment><USER44> I would agree with some of the points - speed (which is stretched over two points), concurrency, and the ability not to do magic as easily, but several of the points (compile time, available developers, strong ecosystem) are not a "versus Python" at all but rather against other languages.

Personally, I see a language like Go and Python as solving different spaces. I wouldn't write a lot of website business logic in Go, and I wouldn't write a low-level TCP redirection daemon in Python.

<comment><USER17> Yeah there are some use cases where Python is a clear winner. For us Python seemed like a good fit initially. Traffic was low and the API didn't provide more advanced features where Python's speed becomes an issue. (Ranking, aggregation)

</comment></comment><comment><USER45> We are switching from Python to Go, because:

> Reason 7 – Strong Ecosystem

> Go's ecosystem (...) it's of course not as good as (...) Python.

Then why do you put that as a reason to switch?

<comment><USER46> Similarly,

> Reason 5 – Fast Compile Time

</comment></comment><comment><USER47> If you can switch from Python to Go, you weren't using Python anyways, you were use Gothon or Javthon.

If you want static binaries, great tooling and an excellent imperative and functional language, try F# with mkbundle. The compelling reasons to use go are shrinking.

<comment><USER48> Would love to, but what I would miss from Go is that low latency GC. If ya need it, ya really really need it.

If only somebody wrote a nice ML that compiled to Go! I love a lot of things about Go, but the language certainly isn't one of them.

<comment><USER49> I'm hacking on a PureScript-to-Go transpiler (ie. alt backend for existing PureScript compiler once PR #3117 gets accepted). Watch [http://github.com/metaleap/gonad/](http://github.com/metaleap/gonad/) \--- hoping to "get there" within 2 weeks. Taking unreasonably long already, given that purs already does its jobs on its own like parsing, type-checking, transforming-ML-to-imperative. One reason I'm taking a bit longer than the quickest-dirtiest approach would, I want to preserve the type information as much as possible rather than have all functions accepting and returning and passing `interface{}`s in a JS-like manner. Ie it's meant to generate sane readable human-like idiomatic Go code. Type-classes mapped to interface types, etc. Will also have to attack the need to have any Go package be represented readily on the PureScript side as an existing module that'll show up in auto- complete and pass compilation, so to quickly auto-generate some kind of dummy FFI bindings whenever a Go-land dep is imported and used. Fun ride!

There's clearly value in combining Go's compilation speeds, stdlib functionality, rich ecosystem, lean fast binaries, GC etc with a rich and cutting-edge Haskell-ish/ML-ish type system (and the leaner syntax and compressed idioms). Will be great for clear thinking and expressive high-level type-driven dev and DSLs (and naturally, implicitly generics/code-gen haha), without having to wrestle with GHC/cabal/stack build annoyances/times and Haskell's whacky academic overly-PhD-ish "wrappings" around raw straightforward real-world needs such as http-server and db-client, where again the Go ecosystem shines.

<comment><USER48> Thanks for the tip! I'll keep an eye on it.

</comment></comment></comment></comment><comment><USER50> > Python allows you to get pretty creative with the code you're writing. For > instance, you can:

> Use MetaClasses to self-register classes upon code initialization

Avoid metaclasses....

> Swap out True and False

Not possible anymore

> Add functions to the list of built-in functions

What are the practical reasons?

> Overload operators via magic methods

Useful but also recommend don't. I can see someone writting numpy would do that, but most applications don't have a reason

Profile profile profile! Find the bottlenecks.

<comment><USER51> "Avoid metaclasses...."

Good luck finding a Python library that doesn't use metaclasses anywhere!

<comment><USER52> How about Requests?

[https://github.com/requests/requests/search?utf8=%E2%9C%93&q...](https://github.com/requests/requests/search?utf8=%E2%9C%93&q=metaclass&type=)

</comment></comment></comment><comment><USER53> You can tell a lightweight article when you read that all you need to do to get concurrency working is stick 'go' in front of a function call.

I must mention that to the LVM developers dealing with my latest lost wakeup problem.

</comment><comment><USER54> Instead of all the 'we replaced x with y', I'd like to for once read something along the lines of 'we started using x and y side by side, embracing the benefits of each'

I use both Python and Go regularly and the use cases rarely overlap. They are both fantastic languages and once you realise what you want to use each one for, you'll be one happy developer. (Applies to many other combinations of languages.)

</comment><comment><USER55> Right now, Docker, K8s and their adoption among Microsoft, Oracle, IBM are what keeps me keeping up with what goes on Go, because "hey we need to write some stuff in Go here".

For me Reason 3 is exactly the opposite, if I have to spend time manually writing code that other languages give me for free, I am anything but productive.

</comment><comment><USER56> Performance shouldn't be a compelling reason to change the language for a project. If they have truly benchmarked, profiled, reworked hotspots using Cython and looked into major bottlenecks such as IO and Python still isn't performing up to scratch then fair enough.

</comment><comment><USER57> > Go's fast compile times are a major productivity win compared to languages > like Java and C++ which are famous for sluggish compilation speed.

C++ is famous for sluggish compilation speed, but Java is not. Java code compiles pretty quickly; it's a simple language.

<comment><USER58> Neither is java a simple language, nor does Java code compile quickly, in my experience.

However the largest disadvantage of Java is Java programs generally consume more than 10x more memory than the same scale Go programs, and need 20x more time to fully to warm up.

I do admit Java is more consistent than Go from the syntax design view.

</comment></comment><comment><USER59> > _Go forces you to stick to the basics. This makes it very easy to read > anyone's code and immediately understand what's going on._

I think all new language design _must_ incorporate this goal going forward. It's been simply too valuable. When I see something introduced that does x, y incrementally better but makes no effort for the above goal I get sad and move on.

It's easy to get caught up in the technical challenges of a language, but this meta challenge is what really helped move the ball forward with Go, and I'd love to see it introduced as a first-class goal in new language design.

<comment><USER60> Some people insist on being obtuse (coincidentally, I'm looking in the general direction of a template heavy C++ user), and for worse or better, personal preference is a large factor in language adoption as opposed to what works best for the industry as an engineering practice.

</comment></comment><comment><USER61> when you list as a con "package management", meaning "go is even worse than python"... man.

</comment><comment><USER62> I cant help to feel that in Go performance is more important that developer productity. Go is the new C. The code looks a bit clunky, with lots of error checks.

I rather work in a language like Python or Kotlin where the code just looks like how you would think the code would like (if i would write it in pseudocode on paper)

However Go in big teams will really be nice. Thats why they invented it in the first place.

</comment><comment><USER38> I'm surprised to see that people choose anything other than C++ if they care about performance. Are you really trying to profile and optimise python and go? It will never be worth it! Just write the same thing in good modern C++ and you get an automatic 100x speed up for most cases. Then optimise to reach the absolute limits of the hardware. Python and go it seems!

<comment><USER63> Some people choose Go rather than C++ for the same reason you went with C++ rather than an assembly language.

Most of the time, things only need to be fast enough and trading speed for ease of development, deployment, and maintenance is an easy decision to make.

</comment></comment><comment><USER64> The guy didn't even mention type checking. Guess it's not a big deal to him. Zero type errors during runtime is a big deal.

<comment><USER65> That's a very good thing for a language to have, indeed. But Go isn't the best thing to look into for productivity-via-the-type-system. What _is_ (barring the purely functional languages' learning curve) is most any ML descendant; albeit Rust in particular if Go-like performance is desirable.

<comment><USER64> Rust is descended from ml? Isn't Rust a algol based language? Is it functional?

<comment><USER66> OCaml was a really strong influence on Rust. The first Rust compiler was written in OCaml. Rust's traits are also similar to Haskell's typeclasses.

<comment><USER65> Rust also has discriminated unions, structural pattern matching and local type inference.

</comment></comment></comment></comment></comment><comment><USER67> A nice write up generally. I just feel he should also mention the classic static vs dynamic typing thing. From my perspective, teams switching to Go — from dynamic typed language such as Python — _really_ appreciate the additional compiler help it provides ;)

<comment><USER68> You have type checks in python if you want them. It's just opt in.

</comment></comment><comment><USER69> I've done a fair bit of web dev work in Python but I am currently building my startup ([https://www.growthmetrics.io](https://www.growthmetrics.io)) in Go.

It is in the initial stages, but so far it has been pretty good - both as a learning experience and from a developer productivity perspective.

I've also open sourced a web app boilerplate that I extracted from GrowthMetrics' codebase - [https://github.com/olliecoleman/alloy](https://github.com/olliecoleman/alloy). It might be useful for people looking to get started with Go.

</comment><comment><USER70> IF you like Python but need performant compiled alternative take a look at nim.

</comment><comment><USER71> > Our largest micro service written in Go currently takes 6 seconds to > compile.

What's the biggest, beefiest real world program yet written in Go, and how long does it take to compile it?

<comment><USER72> Docker takes about 10m to build: [https://jenkins.dockerproject.org/job/docker/job/docker.gith...](https://jenkins.dockerproject.org/job/docker/job/docker.github.io/job/master/1606/)

Kubernetes takes about 16m: [https://k8s-gubernator.appspot.com/build/kubernetes- jenkins/...](https://k8s-gubernator.appspot.com/build/kubernetes- jenkins/logs/ci-kubernetes-bazel-build/223299/)

<comment><USER73> Doesn't sound too fast, that's about how long it takes for FreeBSD kernel to be compiled[1] and I would imagine a kernel is more complex. The whole system takes about 50 minutes[2]

[1] [https://ci.freebsd.org/job/FreeBSD-head- amd64-LINT/buildTime...](https://ci.freebsd.org/job/FreeBSD-head- amd64-LINT/buildTimeTrend)

[2] [https://ci.freebsd.org/job/FreeBSD-head- amd64-build/buildTim...](https://ci.freebsd.org/job/FreeBSD-head- amd64-build/buildTimeTrend)

<comment><USER74> Go's main compilation performance gains come from incremental compilation. Since C++ doesn't have real module support merely parsing the entire dependency graph from headers can take a very long time. In go if you have .a pkgs for all your dependencies your program will compile very fast.

If you use docker as part of your ci build the dependencies as a separate step so they can be cached between builds. This is especially important for libraries like sqlite, which can take a lot longer to compile.

</comment></comment></comment></comment><comment><USER75> Since when is Java famous for sluggish compilation???

</comment><comment><USER76> The only thing actually missing from Go's standard library that I've wanted is an abstraction of 'native' UI things (assuming you're compiling for a graphical platform).

For portability there is shipping your a widget set (QT is OK for this if your licencing needs are compatible with either case).

</comment><comment><USER77> Re: frameworks

My experience with the language (building multiple production systems) is that the language itself is sort of it's own framework. You don't need to add much to build an application with the standard library. Which is a huge plus and makes things simpler.

<comment><USER55> That applies to all languages with exception of C, because they didn't want to standardize it as part of the language, hence we got ANSI C + POSIX instead.

<comment><USER78> Don't forget Javascript which is ridiculously under-featured natively. At least C has the excuse of having to run on the bare metal of a wide range of architectures.

</comment></comment></comment><comment><USER79> Here is a similar piece if someone is interested:

[https://hackernoon.com/the-beauty-of- go-98057e3f0a7d](https://hackernoon.com/the-beauty-of-go-98057e3f0a7d)

</comment><comment><USER40> > Another great aspect of concurrency in Go is the race detector. This makes > it _easy_ [emphasis mine] to figure out if there are any race conditions > within your asynchronous code.

Am I reading correctly?

<comment><USER80> It can be a bear to try and track down some race conditions but at least it will not report false positives. However, it will not catch all race conditions or data races you may have.

<comment><USER40> Is Go even memory-safe in the presence of data races? Don't get me wrong, "memory safety" isn't a hard requirement in my book, but "memory safety or a formal semantics" is.

<comment><USER74> If you're curious, the behavior is well defined: golang.org/ref/mem

<comment><USER40> My English reading comprehension is admittedly poor, but I don't see any portion of the text that automatically implies that unsynchronized reads and writes are atomic.

</comment></comment></comment></comment></comment><comment><USER81> I like these "Why we switched from X to Y" articles. I can be summarized in one sentence most of the time. "Because it supported our use case better."

</comment><comment><USER82> It has func and var compiler hints, which I hate (just like in Swift). Its harder to read too (just like Swift).

I'll stick with Python.

</comment><comment><USER83> The post never mentions PyPy. Have you tried it? Could increase the performance dramatically for free.

</comment><comment><USER6> Did you consider scala ?

I use it at work, and it is awesome. It has awesome error handling (Either/Option >>> exception) on my opinion, a much stronger type system (many errors are checked at compile). It is harder to learn, but you also have top notch package manager with the even bigger scala + java ecosystem.

</comment><comment><USER84> "Plan to throw one away. You will, anyhow." \- Fred Brooks

</comment><comment><USER85> Oh, terrific, another one.

The only solid reason this article gave was the second one and, really, is the only one that would ever make sense: If the language one's using becomes the bottleneck then, by all means, change it[1].

Everything else is fluff and opinions. Every single other reason is stuff that is entirely subjective and/or python already has and even the article itself acknowledges, at least for one "reason", python as the better option.

Well, at least they tried to be impartial by mentioning the absolutely odious error handling in Go. It's the biggest reason I became so disillusioned with the language once I actually tried it.

[1]: _I_ , however, would try switching CPython for pypy before rewriting the entire architecture from scratch. It's more performant.

<comment><USER86> I don't think that performance is the key reason to switch from Python to Go (although it _is_ nice): as someone who switched from Python to Go, what really made it worthwhile for me was knowing that my code is _significantly_ more likely to be correct when it runs. Go's typing is much nicer than Python's, for this use case.

Performance is just gravy.

<comment><USER87> Type errors/misuses aren't my biggest problem and Go's type system isn't very powerful. The Python code is smaller, more expressive, easier to review, etc. I have more confidence in the correctness of pylinted Python code. I wouldn't jump to trade conciseness for compile-time type safety, particularly for applications, because it's easier to create/not see a logic error in heavy code. And depending on what you're doing, Python's type system may be more powerful/appropriate.

</comment></comment></comment><comment><USER88> You had me at 4. I'm definitely GOing to give this language a GO now. That was a GOod introduction to the language, a veritable advertisement, if you will.

<comment><USER88> The audience on Hacker News takes themselves way too seriously, apparently.

<comment><USER88> Case in point. Thanks. Also, the moderators seem to have no life. Please deactivate my account if you're offended. I'd prefer not to spend more time attempting to communicate with one dimensional, armchair experts.</comment></comment></comment>


Show HN: POW-ify (comic scream bubble-ify) your website with a single line of js - <AUTHOR> https://github.com/3x14159265/powify.js

<comment><USER2> WOW! This tool has changed the way how I view the world.

Thank you! <Insert Pow></comment>


Google's Android code deleted from Linux kernel - <AUTHOR> http://www.theregister.co.uk/2010/02/03/android_driver_code_deleted_from_linux_kernel

<comment><USER2> Original (informative) blog post: [http://www.kroah.com/log/linux/android- kernel-problems.html?...](http://www.kroah.com/log/linux/android-kernel- problems.html?seemore=y)

(From the news guidelines: "Please submit the original source. If a blog post reports on something they found on another site, submit the latter.")</comment>


Mysterious gut doctor begging Americans to throw out this vegetable. But which? - <AUTHOR> https://www.vox.com/the-goods/2019/5/8/18537279/chum-box-weird-sponsored-links-gut-doctor <comment><AUTHOR> For those who don't want to read the actual interesting story about chumbox advertising:

"Anyway, seems like the vegetable is corn."</comment>


Modern humans emerged thanks to the disappearance of elephants - <AUTHOR> http://www.jpost.com/Sci-Tech/Article.aspx?id=249041

<comment><USER2> How can the disappearance and the emergence of Homo Erectus be separated? Cause and effect remain unclear. Perhaps its the new Homo Erectus, with its big brain, hunted elephannts to near extinction.</comment>


Tell HN: Skype stopped support for Firefox on web skype as of today - <AUTHOR> Screenshot accessing web.skype on Firefox: https://i.imgur.com/4QMZsu6.png<p>Worked fine this morning, stopped support as of right now. <comment><USER2> How long has it been working for you before? It seems this was always the case, unless they enabled it recently (and now dropped it again).

<comment><AUTHOR> I've been using Firefox to access web.skype.com almost daily probably for the past year. It only stopped working yesterday afternoon.

</comment></comment><comment><USER3> Browser support messages are still a thing?</comment>


Ask HN: How to get more attractiveness in our technical blog posts? - <AUTHOR> Hi, I'm writing a new article on my technical blog and I try to figure out what can keep reading my readers.
I use some images (and gifs) to distract a little bit and avoid the big text block, isn't a good method ?
What do you think ? <comment><USER2> Graphics, lists, headings, short paragraphs, code tags -- e.g.  \-- anything that breaks up text and makes your post scannable. Everyone's so time-stressed, the easier you can make your post to quickly scan, the more value you'll provide. Depending on your content, of course. :)</comment>


WebAssembly Specification Prototype - <AUTHOR> https://github.com/WebAssembly/spec/blob/md-proto/md-proto/WebAssembly.md <comment><USER2> I have a question about WebAssembly.

1- With WASM, would developing for the web become similar to how desktop apps are written? For example, could I use C# and design a UI in xaml, compile to WASM for the web?

2- No more JavaScript?

<comment><USER3> WASM doesn't have access to the DOM, or a GC, or very easy interop with JavaScript, so the answer is mostly "no".

<comment><USER4> I hope DOM access comes very close on the heels of the initial design...

Javascript is an interesting language (particularly after it's recent revival), but IMO it's recent jumpstart would never have happened if it weren't for one killer feature: access to the HTML DOM. People would (and have) forgiven many other things, just for the utility of that as the presentation layer.

I certainly would have picked up _whatever_ language the browsers were pushing, where DOM access was a requirement.

Conversely, I remember trying to get java applets to interact with HTML -- you have to message things through a tiny hole to/from javascript; which was (one of the many) things which made everyone hate java applets.

<comment><USER5> It depends what you mean by "access". The MVP won't have _direct_ DOM access, but it's not really necessary. WebAssembly code can _synchronously_ and efficiently call JavaScript functions (with numeric arguments), so it should be pretty easy to write a WebIDL-based stub generator to provide natural syntax for calling DOM functions from any given compiled language, with a little JavaScript stub on the other end. A future spec might make things more efficient by providing direct access, but it's really a micro-optimization.

<comment><USER6> Well, the tricky part is not getting the basic FFI to work but getting the memory management right. Making sure that DOM nodes that are not part of the document stay alive and that dead nodes die is the hard part, especially if JS/wasm cycles are involved.

(This is not a criticism of wasm, by the way. It's merely motivating potential future GC extensions to the spec.)

<comment><USER7> How does that differ from today? Don't all rendering engines have to deal with that GC now?

</comment></comment></comment></comment></comment></comment><comment><USER8> ⌘⃣F⃣ "todo" ⇒ 29 finds

The binary and text representation sections still lack almost anything. This really seems like an early prototype.

<comment><USER9> And the project is in search of a logo. You can find a bunch of proposals here: [https://github.com/WebAssembly/design/issues/112](https://github.com/WebAssembly/design/issues/112)

<comment><USER10> Some of these are atrocious... Do NOT let programmers design brand identities.

<comment><USER11> It's nothing to do with being a programmer - it's to do with not being a designer. Believe it or not some people are good at both.

</comment></comment></comment></comment><comment><USER9> It looks like Wasm.instantiateModule(b, m) currently takes the binary wasm and memory to create a module, when would you pass in a linear memory object? Does converting a wast always produce two files?

<comment><AUTHOR> WebAssembly modules can still import an external linear address space, but they can now also define their own linear address space, with their own initialization data included in the module file.

<comment><USER9> So if I understand that correctly unlike the current text ast format that is floating around the Binary Format doesn't include the contents of (memory ...)? So foo.wasm + foo.mem = foo.wast?

<comment><AUTHOR> wasm modules can include their own initializers now, so .mem files won't be needed. This is the Data Section in the WebAssembly docs.

.wast is actually just a testing file format that's currently serving the purpose of a text format in the absence of a real one. It isn't expected to be part of typical user workflows.

</comment></comment></comment></comment><comment><USER12> I can't wait until the first time I have to maintain something someone compiled into this monstrosity. The minimal performance gains will be _so_ worth destroying the debuggable web.

Sorry for the snark, but watching this slow-motion trainwreck plow into the Open Web that I love is excruciating.

Pre-edit to respond to the inevitable "But you already can't read and debug minified JS": yeah, you actually can if you're good enough. I do it all the time... my complaint is that the bar for "good enough" is being moved from "can read and debug scripting language" to "can read and debug Assembly"... which I know you _can_ do, but geez. I guess what I'm saying is the Open Web should only run on (reasonably) readable languages. Hate JS? Stand in line, but if you want to replace it on the web, replace it with something a normal person could interpret without a compiler.

<comment><USER13> This is a popular negative remark when it comes to WebAssembly, and I'm getting a bit disappointed at how often it comes up. We really need to get past the flood of comments on having an assembly for the web. They're usually uninformed and opinionated (a bad combination), and do nothing to help real efforts that are in place to combat what they're complaining about.

Check the GitHub pull request below (linked from the article we're commenting on...). The WebAssembly spec includes a work-in-progress Text Format specifically to make it readable by JavaScript developers:

> This proposes an official text format for WebAssembly, aimed at browsers to > use in "View Source", debugging, and related tooling. It uses a JavaScript- > like syntax for readability and familiarity on the Web, though it differs > from JS in several respects, as it aims to reflect the underlying > WebAssembly language.

[https://github.com/WebAssembly/design/pull/704](https://github.com/WebAssembly/design/pull/704)

If you're strongly opinionated about WebAssembly having a readable format for the Open Web (and it would seem that many are with the volume of comments like this), then subscribe to this pull request. You'll have an opportunity to see the text format take shape and provide input on it. Developers are not oblivious to the number of subscribers on a PR or issue, so you'll also be making it known that it's important enough for you to be looped in on.

Please check out the Text Format pull and related links so that you can be informed about this issue.

edit: formatting

<comment><USER12> Thanks for the link to that PR. That's good advice. The truth is, it's hard for me to read what they are recommending as the readable version. Maybe that makes me an idiot...certainly a lot of comments in this thread are suggesting that's the case... but I bet I'm not the dumbest guy who codes for the open web... so for that other guy I'm sharing my opinion, misinformed as it may be.

<comment><USER14> Have you considered that there could be use cases where the performance gains are _not_ trivial? For some code, we're talking about more than an order of magnitude speed difference.

What kind of language target would _you_ prefer for running optimized numerical algorithms? Or do you just think we should keep computational photography, natural language processing, physics simulation, 3d graphics rendering, game AIs, etc. off the web?

Remember, to make their code run at full speed, developers need the ability to use a variety of numeric types and processor-specific instructions (e.g. SIMD), implement low level data structures, precisely manage memory, etc.

Even if these numerical algorithms get written in "plain" Javascript, after being minified they become essentially unreadable. Often to understand even an extremely clearly written implementation full of nice explanatory comments requires reading the technical paper alongside the code. If you're not only missing the paper, but also have nonsense variable names and no comments, deciphering the code becomes an incredible chore. As such, I don't think WebAssembly will have any significant effect on readability. Have you tried reading and understanding asm.js output from Emscripten? That's what we have today, and it's definitely worse than wasm.</comment></comment></comment></comment>


Competition programmers at work. One year history of working with top coders - <AUTHOR> http://developers.memsql.com/blog/where-should-topcoders-work-one-year-later/

<comment><USER2> Ok, so they hired really awesome programmers and they did a great job. Should we be surprised by this or something? What was the point of the article?</comment>


Vintage Tech Ads - <AUTHOR> http://www.itworld.com/offbeat/83351/priceless-the-25-funniest-vintage-tech-ads

<comment><USER2> 4 of my favs...

I loved this one, the first "computer you can put in your pocket" - [http://www.itworld.com/offbeat/83351/priceless- the-25-funnie...](http://www.itworld.com/offbeat/83351/priceless- the-25-funniest-vintage-tech-ads?page=0%2C4)

And this was a great example of how sex sold way back when. I will tell you, if someone did an add that looked like this today, feminists would be up in arms, lol: [http://www.itworld.com/offbeat/83351/priceless- the-25-funnie...](http://www.itworld.com/offbeat/83351/priceless- the-25-funniest-vintage-tech-ads?page=0%2C5)

The original portable computer? "Compact, mobile, low in cost..." [http://www.itworld.com/offbeat/83351/priceless- the-25-funnie...](http://www.itworld.com/offbeat/83351/priceless- the-25-funniest-vintage-tech-ads?page=0%2C12)

And last, GEEWIZBANG! [http://www.itworld.com/offbeat/83351/priceless- the-25-funnie...](http://www.itworld.com/offbeat/83351/priceless- the-25-funniest-vintage-tech-ads?page=0%2C7)</comment>


NORAD's Crazy Santa Cause - <AUTHOR> https://www.politico.com/story/2017/12/24/norads-crazy-santa-cause-260254 <comment><USER2> _...volunteers work in two-hour shifts, backed up by dozens of sponsors ranging from Microsoft to the National Defense Industrial Association, Taco Bell and the local Amy's Donuts in Colorado Springs._

Taco Bell?! According to The Polar Express, only true believers can still hear the bell. Well, I can hear the Bell and enjoy XXL Grilled Stuft Burritos at the same time.

Merry Christmas!

</comment><comment><USER3> The origins have been embellished over the years: [https://www.theatlantic.com/amp/article/421161/](https://www.theatlantic.com/amp/article/421161/)

</comment><comment><USER4>
      > including the four-star general in charge of defending North America

I always find that factoid amusing.

<comment><USER5> Care to explain?</comment></comment>


CipherShed, the Truecrypt fork - <AUTHOR> https://ciphershed.org

<comment><USER2> How close is this fork to the original source? The folks behind the Open Crypto Audit Project[1] have done a fantastic job auditing the security of Truecrypt and they're now doing the cryptanalysis. While an actively maintained fork is desirable, changes to the core dependencies will eliminate the benefits of the audit.

[1]: [https://opencryptoaudit.org/](https://opencryptoaudit.org/)

<comment><USER3> That's very true, but if the Open Crypto Audit Project finds any TrueCrypt vulnerabilities, there will be no one around to fix them.

</comment></comment><comment><USER4> Interestingly the FUSE element is going to get much more difficult come Yosemite. Apple has implemented a strict unsigned kext ban on Yosemite, and obviously FUSE relies on those kernel extensions, so effectively, building things like FUSE from source is going to get a lot more difficult for end- users.

The FUSE element will still work fine if you take a signed OSXFUSE binary for example, because those binaries & the kexts within them are signed, but distributing source packages to OS X at least is going to become more painful.

</comment><comment><USER5> I was under the impression it couldn't be forked. Incorrect?

<comment><USER6> Shouldn't, but could:

> On 16 June 2014, the only alleged TrueCrypt developer still answering > emails, replied to an email by Matthew Green about the licensing situation. > He is not willing to change the license to an open source one, believes that > Truecrypt should not be forked, and that if someone wants to create a new > version they should start from scratch.[1]

(Copy of the email on pastebin[2])

[1]: [http://en.wikipedia.org/wiki/TrueCrypt#End_of_life_and_licen...](http://en.wikipedia.org/wiki/TrueCrypt#End_of_life_and_license_version_3.1) [2]: [http://pastebin.com/RS0f8gwn](http://pastebin.com/RS0f8gwn)

<comment><USER7> The letter of copyright law might allow a prohibition of forking and relicensing (to reiterate, the TC author would have to reveal him or herself in order to enforce that prohibition), but philosophically...

 _" I don't feel that forking truecrypt would be a good idea..."_

This is a straight-up abuse of copyright law. Author has no intent of profiting from the project, no intent of continuing to work on the project, and still waves around the hammer of copyright as if it's a fundamental right absent any connection to the constitutional qualification of _promoting progress in the sciences and useful arts_.

To say there's a moral imperative against forking and relicensing in this scenario is stretching the rationale for the copyright monopoly quite far.

<comment><USER8> Interesting. To who else's work can you write a nerd message board post explaining your intrinsic entitlement?

It's not at all shocking that the creator and maintainer of a free encrypted filesystem would eventually abandon the effort, given that comments like these are how the effort is ultimately repaid.

Is there a name for the hammer you swing, the hammer not of abusing copyright but instead of not writing simulated hardware disk encryption and donating it for free? It seems to me that's a far mightier hammer than the one you described.

<comment><USER9> Uh oh, it looks like @tptacek's calling people message board nerds again.

<comment><USER8> I'm @tqbf, not @tptacek. @tptacek is some other person on Twitter.

</comment></comment></comment></comment></comment></comment><comment><USER10> I used Truecrypt heavily for years, but since all the kerfuffle happened I've switched to other stuff. I like Truecypt and would like to move back, but I'm not sure when I'll be able to trust a fork. I can't audit the code myself so I have to rely, I guess, just on mind share and the opinions of security people who are smarter than me.

I'm curious about what other users are doing in this situation. What are your criteria for trusting a fork? How will you know when something (not necessarily CipherShed) is mature and safe enough to use?

<comment><USER11> What alternatives have you used?

<comment><USER10> For disk encryption on Windows, I switched to Bitlocker for my personal use. At my workplace we use Symantec Encryption and Sophos Safeguard, my understanding is they are both pretty okay.

For file encryption, now I just do everything on my Ubuntu workstation and use GPG + tarballs. This is sort of a pain in the ass though, and it's not as secure as a TC container of course. It's kind of just a stop gap until I can think of something better.

<comment><USER12> You think BitLocker closed-source from Micrsofot is more secure and trust worthy then open-source fork CipherShed ? I would take open-source project over closed-source any day. Linux Action Show recently talked about "Tomb", it looks like a nice alternative. [https://www.dyne.org/software/tomb/](https://www.dyne.org/software/tomb/)

<comment><USER13> It's possible for a closed-source product to be written by experts, while the open-source competitor is only written by hobbyists. When it comes to crypto, you probably want the experts.

Also, someone needs to actually audit the source code for the 'open-source' part to really come into play (other than from the discontinuation of support angle). Even with open source code, it's only really been recently that TrueCrypt itself ever got any sort of in-depth audit.

<comment><USER14> In the case of Bitlocker we know that Niels Ferguson is behind it. The name might ring a bell.

<comment><USER15> [http://en.m.wikipedia.org/wiki/Niels_Ferguson](http://en.m.wikipedia.org/wiki/Niels_Ferguson)

 _Niels T. Ferguson (born 10 December 1965, Eindhoven) is a Dutch cryptographer and consultant who currently works for Microsoft. He has worked with others, including Bruce Schneier, designing cryptographic algorithms, testing algorithms and protocols, and writing papers and books. Among the designs Ferguson has contributed to is the AES finalist block cipher algorithm Twofish as well as the stream cipher Helix and the Skein hash function.

...

In 2001, he claimed to have broken the HDCP system that is incorporated into HD DVD and Blu-ray Discs players, similar to the DVDs Content Scramble System, but has not published his research, citing the Digital Millennium Copyright Act of 1998, which would make such publication illegal.

At the CRYPTO 2007 conference ... Niels Ferguson and Dan Shumow presented an informal paper describing a potential backdoor in the NIST specified Dual_EC_DRBG cryptographically secure pseudorandom number generator. The backdoor was confirmed to be real in 2013 as part of the Edward Snowden leaks._

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> Anybody use this yet? What's the legitimacy of this compared to Truecrypt's fallen domain?

I see that actually list the developers which is nice. But unfortunately I'm not too familiar with the big name's in cryptography software.

<comment><USER17> Reading the "news" section, they actually still haven't made any changes, they just managed to compile it!

Some other place that forked the TrueCrypt sources to some repo (VeraCrypt) managed to change a few constants and make the containers incompatible. At least they addressed a known TC weakness: the low number of PBKDF2 passes.

Finally, the contribution of the TruCrypt.ch (TCNext) is that they put the original sources and binaries behind a new domain name and wrote "TrueCrypt must not die."

In short, it's easy to put other's work behind a new domain or in another repo, it's hard and costly to do the real development.

</comment></comment><comment><USER18> From what I understand the author(s) explicitly do not want this forked. The license has not been changed, and whatever fork this is will be from an older Linux repo.

</comment><comment><USER19> Is this the same or different project from the TrueCryptNext one?</comment>


Sushi Roll: A CPU kernel for cycle-by-cycle micro-architectural introspection - <AUTHOR> https://gamozolabs.github.io/metrology/2019/08/19/sushi_roll.html?r=1 <comment><USER2> A few comments @ [https://news.ycombinator.com/item?id=20736713](https://news.ycombinator.com/item?id=20736713)</comment>


Sergey Brin TED talk about Project Glass (fun about yahoo and bing) - <AUTHOR> http://glass-apps.org/sergey-brin-ted-talk-about-project-glass <comment><USER2> Sergey is an interesting character. He's so brutally honest and unrefined. There's no trace of corporate bullshit, no fear of saying anything wrong about Google (although he did correct himself over eBay).

He's awkward. Says "er" a lot. Makes jokes about competitors. Admits that Glass hasn't succeeded yet. Criticises mobile phones (I assume it's a Nexus 4). Says his wife slaps him.

No CEO would do any of this. It's refreshing to see a company spokesperson so "normal".

<comment><USER3> He kind of comes across as a less shifty Mark Zuckerberg.

<comment><USER4> Thats why i like him more and trust him to make the right calls. (i.e. privacy) Mark does not have that, whenever i hear him you can sense this aura surrounding him. Something is off.

And comparing both companies Google is driving inovation. Google Car will transform our planet within years and the same goes for Glass. Think about where in your workplace you could apply a tool like this.

<comment><USER5> It is worth noting that _every_ major car company is working on self-driving cars, and has been for quite a few years now.

<comment><USER6> > and has been for quite a few years now

They have. I first saw stuff about self driving cars when I was a kid, a couple of decades ago. So where are they?

Google has had a fraction of the time, yet appears to have gotten further than most already..

<comment><USER7> ...only to cancel it at some random future time, mid-drive.

</comment></comment></comment></comment></comment></comment><comment><USER8> Site wasn't working for me.

I think this is the video: <https://www.youtube.com/watch?v=rie-hPVJ7Sw>

</comment><comment><USER9> The most boring presentation ever. He is like, so i created google, so i don't have to make an effort to show excitement in my new product, that's for the marketing and sales.

No onstage demo, jizuz i always present my stuff live ! that's where the emotions are.

<comment><USER10> Personally, I'm fine with people not showing excitement and just being themselves. And I actually liked this presentation; seemed very honest and genuine.

</comment></comment><comment><USER11> Still don't like it. Maybe we'll be the ones that people laugh at in the future, like we do now with the ones that said that Internet was just a fad. But consider, doesn't this mean that many people will let computerized glasses do all the thinking for them? It has been very much debated how now we don't memorize so many information anymore, as we can easily just solve an argument with a simple search on our phones. But this Google Glass is just taking it to another level..

<comment><USER12> That's exactly why I like Glass so much. Humans aren't the only things that have memories, as demonstrated by dolphins, chimpanzees, elephants, and dogs. Humans aren't the only things that can process data, as demonstrated by computers. The thing that is unique to humans is the ability to think, to make high-level abstract decisions. By doing all of the menial labor for me - memorization and basic number crunching and mechanical information retrieval - tools like Google Glass let me concentrate on that decisionmaking. They let me concentrate on _being human_.

<comment><USER13> I would argue that without a foundation of basic knowledge and facts you will be unable to do advanced abstract thinking. Knowing something and being able to look it up are not the same thing.

<comment><USER3> "I would argue that without a foundation of basic knowledge and facts you will be unable to do advanced abstract thinking."

What does that even mean?

<comment><USER14> It means that even with easy access to all the necessay information you can't build a rocket if you don't know how to do it.

You can _learn_ how to do it, but that just means transferring the information from the outside into your brain.

You are not able to meaningfully reason (think) about a topic if you don't know anything about it and I show you the Wikipedia page. Easy access to data is useful if you know what to do with it.

<comment><USER3> I don't see how this argument detracts from glass in anyway. Doesn't it just make a better case for them?

<comment><USER14> Where did I mention Glass?

The OP said that having easy access to information allows him to "be human" and think. I'm arguing that is not nearly enough.

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> OP only submits articles from glass-apps.org. Clearly a shill for that site. 14 submissions from that site in 4 days.

<comment><USER16> Account was registered on 3rd March, domain was registered 5th March. "Hmmm"

<comment><AUTHOR> hey guys sorry if I offended you by my enthusiasm for google glass. I certainly didn't know enough about the hacker news community to to everything right. The site is currently down because of the attention (I have seen the same problem with other news posted here). I think I know now how to act properly in this "community".

<comment><USER16> Let me guess.. home work media job, lots of time on your hands to discuss interesting products?

</comment></comment></comment></comment><comment><USER17> Even if Glass isn't the right implementation, I love the fact that Google are trying to make something Minority Report-level wacky a mainstream consumer item.

<comment><AUTHOR> yes it will be creepy for a while and then become normal. Do you remember those businessman with clunky cellphones we laughed at? -_-

</comment></comment><comment><USER18> That felt a lot more awkward than I expected.

<comment><USER3> No kidding. The awkwardness never really let up.

</comment></comment><comment><USER19> "If I had glass" on Yahoo and Bing:

[http://search.yahoo.com/search;_ylt=Agw0sPNuxbiST6yjUH1P2j6b...](http://search.yahoo.com/search;_ylt=Agw0sPNuxbiST6yjUH1P2j6bvZx4?p=if+i+had+glass&toggle=1&cop=mss&ei=UTF-8&fr=yfp-t-900)

[http://www.bing.com/search?q=if+i+had+glass&go=&qs=n...](http://www.bing.com/search?q=if+i+had+glass&go=&qs=n&form=QBRE&pq=if+i+had+glass&sc=1-14&sp=-1&sk=&ghc=1)

and Google

[https://www.google.com/?q=if%20i%20had%20glass#hl=en&new...](https://www.google.com/?q=if%20i%20had%20glass#hl=en&newwindow=1&safe=off&output=search&sclient=psy- ab&q=if+i+had+glass&oq=if+i+had+glass&gs_l=hp.12...0.0.0.215220.127.116.11.0.0.0.0.0..0.0...0.0...1c..7.psy- ab.I9Ce- uDAX8A&pbx=1&bav=on.2,or.r_cp.r_qf.&bvm=bv.44158598,d.dmQ&fp=2bfa96fe02dccb7&biw=1847&bih=959)

<comment><USER20> If anyone is interested, I did an analysis/visualization of people's "if I had glass" responses. Some are predictable ("I would sell it on eBay"), some are interesting ("surgeon could video and broadcast surgery" - at the very bottom of that visualization), lots and lots are about capturing moments and sharing them:

[http://blog.itrendcorporation.com/2013/03/19/back-by- popular...](http://blog.itrendcorporation.com/2013/03/19/back-by-popular- demand-so-what-would-people-do-with-google-glass/)

I am still amazed at this approach by Google with Glass - they don't offer a compelling reason to buy it yet, and people still seem to want it.

</comment></comment><comment><USER21> He says that they designed Glass to free up your hands and eyes and ears, but that is only true when you're not using it. When you are using it you're using your hands to scroll, your eyes to look at the screen, and you are still listening for what it has to say. How is this different from a phone?

When your phone is in your pocket your hands and eyes and ears are free but when you are using it they're not. The only difference seems to be looking up and slightly cross-eyed and not down.

If Glass becomes a success, I fail to see how it would bring people out of the bubble they're in when using a phone. It seems like Glass just moves the bubble.

</comment><comment><AUTHOR> <http://glass-apps.org/google-glass-anime> I've seen a very good anime about augmented reality. There are really nice glasses that are barely visible on your face. I hope google glass will be as fashionable as that some day:

</comment><comment><USER22> I have a question: Would anyone still be bothered by all the privacy stuff if Glass didn't have a camera?

I guess then it'd be a redundant technology (is there such a thing?), but I assume people wouldn't be so concerned about their privacy as well, right?

<comment><USER23> There are three types of complaints I've seen about Glass:

* Camera-based privacy concerns.

* A rude distraction in my face/someone else's face that interrupts human interaction.

* It's ugly.

I completely ignore the last.

For the second, social norms will change or develop to address this. I expect people who pause in a conversation to stare at their eyeball screen will get similar reactions as people who glance down at their phone. Some will care; some won't. A lot of younger people won't give two poops.

For the privacy/camera based concerns, I'm quite fatalistic about it. Google has indicated that it's going to be obvious when you take a picture -- but more importantly, we are going to be surrounded by more and more cameras and sensors as time goes on. Since I don't think we can beat 'em..

</comment></comment><comment><USER24> Cue the advent of the No-chamber: <http://dune.wikia.com/wiki/No-chamber>

</comment><comment><AUTHOR> wtf is wrong with his hair?

<comment><USER25> That's really all you have to ask? Interesting...

<comment><AUTHOR> I know all other official stuff about Glass :_)

<comment><USER20> Nobody does though. I don't think even Google knows what to do with Glass (or how to sell it) just yet.</comment></comment></comment></comment>


Building a Native Soundcloud Android App with React Native and Redux - <AUTHOR> https://wiredcraft.com/blog/native-soundcloud-android-app/?utm_source=hn <comment><USER2> I've been away from React for a while and haven't really encountered Redux...is it to replace Flux? Is it worth learning?

<comment><USER3> It seems to be one of the front contenders among the Flux alternatives now. Another one is Relay/GraphQL.

Redux adheres to the basic unidirectional data flow philosophy of Flux. Where it mainly differs is that there is one store. All state is kept in a (potentially large) graph of JS objects and arrays. It is also very functional in nature.

One advantage is that it solves the Flux store singleton problem. This makes it more amenable to building isomorphic apps, among other things.

I've been using it and find that it's more straightforward than typical Flux implementations. There's less boilerplate. It also allows for more heterogeneous data storage and more flexible structure. You don't need to create a new store every time you need a new collection, for example. You can use it to store the majority of your state, and keep your React components largely stateless.</comment></comment>


Ask HN: What can we do to help during/after Covid-19? - <AUTHOR> Even if we the spread of the virus is contained in the next 30 days (personally I am very pessimistic), the devastation left by it is going to last a while - already hundreds of thousands of people have lost their jobs and this is going to worsen.
How can someone with no money, but some tech skills/time/willingness, help in this situation?
Edit : Also, how can ordinary Joe/Jane be prepared for something like this in future without looking up to the government and the generosity of a handful of billionaires like Bill Gates (nothing against him, he is doing great work)? I understand the normal stuff - keep some savings, keep some canned food, be in as good health as possible etc. But these aren't enough? <comment><USER2> I've already donated money to causes. I am willing to donate my skills and time to something as well. Go coder in the Seattle area here.

<comment><AUTHOR> Tristate area here, I am willing to donate time and skills as well. But this would require more than just tech skills - how are we going to find jobs for potentially a few million people fast, for example?</comment></comment>


How Consumer Reports got Apple's attention when no one else could  - <AUTHOR> http://37signals.com/svn/posts/2458-how-consumer-reports-got-apples-attention-when-no-one-else-could

<comment><USER2> I respect Consumer Reports (though, significantly less than I respect Cooks Illustrated, which has not only a mission but also a singular perspective). And I see why Apple reacted to them and not, say, to Engadget. But if you look closely at CR's coverage of the antenna, it isn't faultless. It starts out levelheaded, becomes breathless, and changes as part and parcel of the online news cycle --- exactly what this 37s post says CR _doesn't_ make a habit of doing.

</comment><comment><USER3> I respect (and pay for) Consumer Reports, but their scoring system is unnecessarily confusing. CR only 'Recommends' products they consider to be exceptionally good. It's like receiving an A+, not a C-. Unfortunately, no one who isn't a subscriber is going to understand the distinction. The mainstream media reported the story as if by not 'Recommending' the iPhone 4 CR had told people _not_ to buy one. It's still their highest-rated smartphone.

<comment><USER4> You have pointed out a problem with mainstream regurgitation of Consumer Reports recommendation, not with Consumer Reports.

CR are doing the right thing by only recommending exceptional products. That should be what a recommendation is. "It's not total crap" and "it's better than the other total crap that's out there" are not recommendations and shouldn't be.

(For the rhetorically impaired: I realize there are several levels of quality between total crap and exceptional.)

<comment><USER3> The term itself is inherently confusing. If only the best products are 'recommended', are the rest 'not recommended'? That's how it was interpreted, by the mainstream media and blogs alike.

They could just as easily label them as 'Outstanding' or 'CR Choice' products and avoid the confusion.

<comment><USER5> How is recommend a difficult term to understand?

They don't recommend it. Simple.

I find the idea refreshing that someone can still speak plain english as well as hold up high standards.

<comment><USER6> > How is recommend a difficult term to understand?

Because Consumer Reports is using the term with the correct denotation, while being oblivious to the media and population at large using this term connotatively. Most people think the word "recommendation" is a binary term, similar to "good" versus "bad," when it really is meant to be relative term referring to a continuum. If you tell somebody that something "is best of breed, but still not recommended," they would either look on you with suspicion or even accuse you of being contradictory, even though you technically aren't.

[http://itsfiveoclocksomewhere.blogspot.com/2006/09/grammar-m...](http://itsfiveoclocksomewhere.blogspot.com/2006/09/grammar- moment-denotation-vs.html)

A connotation mutates a word's original denotation over time, as anybody who has heard of the "euphemism treadmill" can attest.

(FWIW, I have no intention of buying an iPhone, just not for this reason...)

</comment></comment></comment></comment></comment><comment><USER7> CR has published it share of canards. Most famously, it helped fan the flames of the false Audi 5000 "unintended acceleration" story in the 1980s — and there was nothing wrong with the cars, as a subsequent NHTSA report demonstrated.

</comment><comment><USER8> There seems to be CR fans everywhere now they are taking it to Apple. But I'm a long time car guy and CR isn't well regarded in those circles. For autos, they have been well behind the curve in recommending models just because of the maker. Toyota is the most glaring example they only recently with the bad press have stopped rubber stamping recommendations for them. With all of the data they have, they had to know about the engine sludge problems or minivan doors but kept recommending all of their models. Likewise, they placed cars such as the latest Chevy Malibu in the same iPhone recommendation purgatory - due to name only. They overweight recommendations based on past performance.

I admit to looking at CR if I need a dishwasher. However, if 37signals would make that same post in a car site it would be laughed at.

</comment><comment><USER9> This is dead on. My parents (and other family members outside of tech) read and heed CR religiously.

<comment><USER10> But do they buy iphones and many other tech gadgets? I can't imagine there is much overlap between CR readership and bleeding edge gadget consumers.

</comment></comment><comment><USER11> It's pretty clear that the engineering work behind the press conference was well underway before the Consumer Reports video hit.

Google for "apple responds to consumer reports" and the top hits are from Consumer Reports' web sites, then some other stuff, but nothing that really says it happened.

Was there something in the press conference?

</comment><comment><USER12> The underlying theme that trend bucking businesses with deep commitments to a service of rich value is well taken. And the Apple/CR example is indeed an intriguing and worthy example to examine.</comment>


Ask HN: How to Find Remote Jobs? - <AUTHOR> I am just learning Python for web dev. I know basic HTML and CSS so far. I can hack and build simple sites.
I am quitting my job to focus on learning web dev full-time.
How to find remote jobs? <comment><USER2> You can always checkout remote companies directly, here's a list of 900+ Startups hiring Remotely in 2019 - by Remotive.io[0]

[0] [https://docs.google.com/spreadsheets/d/1TLJSlNxCbwRNxy14Toe1...](https://docs.google.com/spreadsheets/d/1TLJSlNxCbwRNxy14Toe1PYwbCTY7h0CNHeer9J0VRzE/htmlview?sle=true#gid=1279011369)

<comment><USER3> thanks

</comment></comment><comment><USER4> I'd suggest not quitting your job until you have a new one secured.

<comment><USER5> +1

It may take longer than expected to get a junior remote web dev position.

</comment></comment><comment><USER6> This is one of the best resources I have found so far is remote.com

A big number of companies support remote work now, so you can easily filter it in stackoverflow or linkedin.

\- [https://remote.com/jobs](https://remote.com/jobs)

\- [https://stackoverflow.com/jobs](https://stackoverflow.com/jobs)

\- [https://www.linkedin.com/jobs/](https://www.linkedin.com/jobs/)

</comment><comment><USER7> A good website is [https://remoteok.io/](https://remoteok.io/) I've had success through stack overflow remote jobs too. There's no silver bullet, you have to send resumes, study, get rejected time and time again until you land your first job. Once you get remote experience under your belt it would be a lot easier to land the next job.

</comment><comment><USER8> You still don't have contact details in your profile, and you didn't answer the question I posted as a reply[0] to the last time you asked.

[0] [https://news.ycombinator.com/item?id=20708132](https://news.ycombinator.com/item?id=20708132)

<comment><AUTHOR> I am sorry for delay.

petercooperu at gmail dot com

<comment><USER8> There's no need to apologise, and perhaps my point wasn't clear. I'm trying to say that if you're looking for jobs, not having contact details in your profile is a bit ... well ... "odd". Surely you want people to be able to contact you.

But it's not just your email, it's having a link to a CV, or some sort of page that talks about what you can do, and what you're looking for. If I'm looking to employ someone (which sometimes I am, but not at the moment) I'm going to want to know that the person is a problem solver, and can anticipate problems and work either to solve them, or to avoid them. I want to see examples of what they can do.

So in the light of that, how does it look for you to ask about finding jobs, but not have anything in your HN profile? You might want to have a think about that.

You're not the first person to do this, and I'm sure you won't be the last. I just always find it a little surprising.

</comment></comment></comment><comment><USER9> I am looking for remote embedded engineering jobs - this seems to be much harder to find!

</comment><comment><USER10> I've hired quite a few people and networked through upwork.com</comment>


Pitch Drop Experiment - <AUTHOR> https://en.wikipedia.org/wiki/Pitch_drop_experiment <comment><USER2> Not fair! They discount two longer-running experiments because they were interrupted. Then go on to explain how this experimental procedure was changed halfway through to control for temperature. So really, not the world's longest-running experiment. Not by a century.

<comment><USER3> It's a pet belief of mine that Guinness World Records are a 'scam'. The big sporting records, like fastest 100 m sprint, are actually tracked by the sports bodies. What say they have in the matter is its own debate (e.g. there's no record for the 150 m, because the IAAF don't sanction a 150 m race, but there was a famous unsanctioned race between winners of the 100 m and 200 m races), particularly in sports with multiple federations or codes, but at least they sometimes have international government funding from which to derive some kind of authority.

GWR have nothing but a tacky book, yet we've all been sucked into this notion that it's not an official world record unless they say it is. And what they accept as a record is subject to strict guidelines (i.e. what they're willing to put in a child's Christmas stocking) and dubious rulesets. There are even unbreakable 'first xyz' records and geographically limited 'world' records.

<comment><USER2> Its an entertainment book to have in a bar to settle bets. If you have something more convenient/as cheap, let us all know!

<comment><USER4> I've never been to a bar that actually had the book. Is this a regional thing?

<comment><USER5> Have you made a bet in a bar that the book could have settled? Maybe they only pull it out when needed, instead of keeping it on display.

</comment></comment></comment></comment></comment><comment><USER6> I walked past this 'experiment' every day for a number of years at UQ in Brisbane (on route to my lunchtime nap in the great court). The glass cabinet is fairly inconspicuous, sitting outside a bunch of small rooms, above a minor thoroughfare. I don't remember exactly how long it took me to take notice and stop to read the inscription (2 years+?) but I was impressed when I did. And it's extraordinary the number of times it has come up in conversation since.

</comment><comment><USER7> For some reason, I find the thought of a pitch drop hanging on (for years and years before falling) very unsettling. I just want it to fall already!

<comment><USER8> Seems like precisely the thing that so many mobile games are monetizing on.

</comment></comment><comment><USER9> St. Andrews has one as well, apparently dating to 1927 too. [https://books.google.ie/books?id=74PgZAHPw38C&pg=PA32&lpg=PA...](https://books.google.ie/books?id=74PgZAHPw38C&pg=PA32&lpg=PA32&dq=%22st.+andrews%22+%22pitch+drop%22&source=bl&ots=lKIjtti0yZ&sig=ACfU3U0ZonS2S7YhxVoa-6Yy9DTp1nKS0Q&hl=en&sa=X&ved=2ahUKEwj0_K- Tmb7nAhWoUhUIHWDAAXkQ6AEwAXoECGEQAQ#v=onepage&q=%22st.%20andrews%22%20%22pitch%20drop%22&f=false) It was on display in the Physics building, and I assume probably still is.

</comment><comment><USER10> > Large droplets form and fall over a period of about a decade.

It would be fun to pair this with a program that outputs the amount of liquid collected, with the display delayed by the amount of time it took for the previous droplet to fall.

</comment><comment><USER11> (I want to tease the Long Now folks about their clock: Why not just make a big pitch drop "water" clock? I know, I know, it's not to their point, and FWIW I love the machines they make, but the reliability and simplicity of a 10,000+ year clock made of pitch has something going for it, _ne?_ )

<comment><USER12> Calibration is a huge issue for clocks. Your pitch water clock would have issues knowing the correct month after 10,000 years. But, if you just want cheap and long lasting, erosion of a large stone is worth considering.

<comment><USER11> Oh I know, it's a dumb joke.

</comment></comment></comment><comment><USER13> It's a good source for a RNG. Just compute if the interval for two consecutive drops is bigger os smaller from the two previous drops.

Might block, of course, if you ask _too frequently_ for a new bit.

<comment><USER14> Would be a highly biased random source, only one drop was quicker.

</comment></comment><comment><USER15> My dream research job.

<comment><USER16> "Has another drop fallen yet? No." Done working for the day.

<comment><USER17> Plus you can work from home: [https://livestream.com/accounts/4931571/events/5369913](https://livestream.com/accounts/4931571/events/5369913)

<comment><USER18> What a time to be alive. This is incredible. I wonder what those balloons in the case are used for.

<comment><USER19> That's the older beaker containing the previous drops.

</comment></comment></comment></comment></comment><comment><USER20> Is today "post a wikipedia article" day?

</comment><comment><USER21> What, no mention about glass being an even more viscous liquid? I grew up believing the story about medieval church windows being thicker at the bottom because the glass had flowed downward over a period of centuries. It turns out that medieval windows are indeed thicker at the bottom but the part about glass being a "slow liquid" was wrong:

 _These windows are thicker at the bottom owing to the production process. Back during medieval times, a lump of molten glass was rolled, expanded, and flattened before being spun into a disc and cut into panes. These sheets were thicker around the edges and installed such that the heavier side was at the bottom._ [1]

[1] [https://io9.gizmodo.com/the-glass-is-a-liquid-myth-has- final...](https://io9.gizmodo.com/the-glass-is-a-liquid-myth-has-finally-been- destroyed-496190894)

<comment><USER22> nth time i've seen this posted on HN

</comment></comment><comment><USER23> Excerpt:

University of Queensland experiment

"The best known version[1] of the experiment was started in 1927 by Professor Thomas Parnell of the University of Queensland in Brisbane, Australia, to demonstrate to students that _some substances which appear solid are actually highly viscous fluids_."

Perhaps conversely, perhaps all solid materials are really just liquid... just locked in place by a local stasis field of some sort... call that stasis field time, gravity, magnetism, the electrostatic, or strong or weak nuclear forces... Perhaps the stasis field and the distance of its effect, is also relative to scale... and perhaps all fields are just variations of interia, relative to scale and material...</comment>


Ask HN: How does Flynn make money? - <AUTHOR>

Do they consult? Do they sell something?<p>https://flynn.io/ <comment><USER2> They're on external funding right now. I'm guessing that consulting services around flynn deployments are not too far out, given how much progress they've made recently.

</comment><comment><USER3> Get users, _then_ monetize.

<comment><USER4> So kick the can down the road until the dot com v2.0 bubble bursts?</comment></comment>


Indian school 'asks' 840 students to buy iPads - <AUTHOR> http://ibnlive.in.com/news/mumbai-school-asks-840-students-to-buy-ipads/211815-3.html

<comment><USER2> A school in New Zealand has made this mandatory for all students. I welcome the change, however many parents won't be able to afford the gadgets. I hope that schools will allow the use of lower-spec, cheaper tablets as well.

<comment><USER3> How can a school make an expensive piece of equipment mandatory for students?</comment></comment>