Comparing Elixir and Go - <AUTHOR> https://blog.codeship.com/comparing-elixir-go/ <comment><USER2> If you want to really understand the philosophy that makes Erlang ( and Elixir ) beautiful ( and why it made me a better programmer ), this conference by Greg Young is a kind of eye opener : [https://vimeo.com/108441214](https://vimeo.com/108441214) .

You realize then that clustering, hot reload, availability etc... are not only features but the logical consequence of a beautifully crafted environnement that aims at developer productivity.

I'm sometimes amazed on how easy I can achieve stuff on the Erlang VM that would take ( if it's not impossible at all ) at least 10 times the time in a more usual language ( Ruby or PHP when you work in the web industry as I do ).

My last example was when I needed to batch sql inserts in an events database. In a normal language I would have needed a queue, the libraries for it, workers, new deployments and infrastructure to monitor, monitoring, supervision, etc... In Elixir, in 20 lines of code, it's done.

If you do not need complex calculations, the Erlang VM can basically become most of your architecture. It's already per se a SOA.

<comment><USER3> how easy is it, even if you _do_ need complex calculations, to get the best of the Erlang VM and call out to say, Python/Numpy or C when necessary? Can these external processes still be supervised, for example? Are decent sized matrices (for example 100x20000 floats so an 8MB data structure) easily movable around the Erlang VM via message passing?

IE is it viable in your opinion still to use Erlang as a system for distribution and routing of lots of heavy calculations to many users, if said calculations are performed outside of BEAM? I am looking at building a multivariate financial calculation engine, which must be interactive for up to 1000 users, with large firehose of real time data coming in, being massaged, and then distributed, with the calculation graph being customizable for each user interactively.

<comment><USER4> It is possible to start external processes from BEAM and interact with them. I've blogged a bit about it at [http://theerlangelist.com/article/outside_elixir](http://theerlangelist.com/article/outside_elixir)

You can also write NIFs (native implemented functions) which run in BEAM process (see [http://andrealeopardi.com/posts/using-c-from-elixir-with- nif...](http://andrealeopardi.com/posts/using-c-from-elixir-with-nifs/)). The latter option should be the last resort though, because it can violate safety guarantees of BEAM, in particular fault-tolerance and fair scheduling.

So using BEAM facing language as a "controller plane" while resorting to other languages in special cases is definitely a viable option.

<comment><USER5> I spent 30 minutes looking at NIF, but I was scared away. My understanding is that if the NIF crashes then BEAM crashes. Which leads me to think that if you need NIF then you need safety guarantees on the Native side that C can't provide.

<comment><USER4> Precisely, which is why I always advise to consider ports first :-)

However, in some situations the overhead of communicating with a port might be too large, so then you have two options:

      1. Move more code to another language which you run as a port.
      2. Use a NIF

It's hard to generalize, but I'd likely consider option 1 first.

If you go for a NIF, you can try to keep its code as simple as possible which should reduce the chances of crashing. You can also consider extracting out the minimum BEAM part which uses the NIF into a separate BEAM node which runs on the same machine. That will reduce the failure surface if the NIF crashes.

I've also seen people implementing NIFs in Rust for better safety, so that's another option to consider.

So there are a lot of options, but as I said, NIF would usually be my last choice precisely for the reason you mention :-)

<comment><USER6> Aren't dirty NIFs on the horizon as well which help with the whole scheduling issues currently associated with NIFs?

<comment><USER4> Dirty schedulers can help with long running NIFs, but they can't help with e.g. a segfault in a NIF taking down the entire system.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> One thing that is completely missing from the Erlang side of the article are the OOB monitoring and operating capabilities.

An Erlang VM is a living system that has a shell which you can connect to, and control both the VM and the applications running in it. You can also remotely connect to another VM, execute arbitrary code, debug, stop processes, start processes etc. It really is an operating system in itself, that was _designed_ to be that way.

And the best part is that you get all this for free. Whether that is a good thing depends entirely on your needs. You probably wouldn't want to replace your bash scripts with Erlang programs :)

What Erlang is not really suited for is where you need multiple levels of abstraction, such as when implementing complex business logic. You would think that the functional nature of the language lends itself to that, but then you quickly realize that because the primary concern of an Erlang engineer is to keep the system alive, and for that reason you must be able to reason and follow the code as it is running on the system, all kinds of abstractions are very much discouraged and considered bad practice (look up "parameterized modules" for an example of a feature that was _almost_ added to the language but was discarded in the end).

I think that from this perspective Erlang and Go are actually very similar - both prefer simplicity over abstractions.

<comment><USER2> Totally agree. Erlang is quite against "magic" which improves greatly readability. Debugging is really straightforward 99.9% of the time.

</comment></comment><comment><USER8> I think the part about cooperative/preemptive multitasking isn't saying it all.

Go multitasking is based on the compiler inserting switchpoints on function calls and syscall boundaries. But this affects the scheduling of a single OS- level threads executing that specific goroutine. The number of OS-level threads that the Go scheduler uses can arbitrarily grow, and OS-level threads are preemptively multitasked.

So I think the description is focusing a narrow view of the problem. What is usually required by applications is low latency in reply to system events (e.g.: data available on network sockets), and Go performs very well in this context. For instance, the fact that Go is transparently using a epoll/kqueue based architecture under the hood is probably affecting latency much more than the whole "cooperative" issue as depicted.

<comment><USER9> > I think the part about cooperative/preemptive multitasking isn't saying it > all.

That's still not the entire story:

GC & tight loops in Go: [https://github.com/golang/go/issues/10958](https://github.com/golang/go/issues/10958)

Per process vs per runtime GC: [https://news.ycombinator.com/item?id=12043088](https://news.ycombinator.com/item?id=12043088)

<comment><USER9> Can't update parent.

Please /do not/ read my OP as a dig/boost at any level. Just pure geek interest in language architectures and sharing info.

</comment></comment></comment><comment><USER10> This is more for people looking at erlang/elixir than a critique of the blogpost or a suggestion for a change.

> Within Elixir, there is no operator overloading, which can seem confusing at > first if you want to use a + to concatenate two strings. In Elixir you would > use <> instead.

When this popped up, it reminded me of something people try to do often and then have issues with performance. You _probably_ do not want to concatenate strings.

"Yes I do" you'll first think, but actually erlang has a neat commonly used thing to help here.

Let's say you're doing some templating on a web-page. You want to return "Welcome back username!". First pass (a while since I wrote erlang so forgive syntax errors):

        welcome(Username) ->
            "Welcome back " ++ Username ++ "!"

Now it's going to have to construct each string, then create a new string with all three. More creation & copying means things get slower.

Instead, many of the functions you'd use to write files or return things over a connection will let you pass in a _list_ of strings instead.

        welcome(Username) ->
            ["Welcome back ", Username, "!"]

Now it's not copying things, which is good. But then we want to put the welcome message into another block with their unread messages.

        full_greeting(Username) ->
            welcome(Username) ++ unread_messages()

More appending than is good here, concatenating lists is going to take time. Of course, we could put it all in one function, but then we lose re-usability in the templates and have horrible massive functions. While this is a simple example, I hope you can picture a larger case where you'd want to split up the various sections.

Anyway, there's a better way of doing this. The functions that take lists of strings actually take lists of strings _or other lists_. So we can just do this:

        full_greeting(Username) ->
            [welcome(Username), unread_messages()]

You can keep going, nesting this as much as you want. This saves a lot of copying, allows you to split things up and avoids having to keep flattening a structure.

So, for people about to get started, try not to concatenate your strings, you can probably save yourself and your computer some time.

For more info on this, you want to search for "IO Lists" or "Deep IO Lists".

<comment><USER11> > _Now it 's going to have to construct each string, then create a new string > with all three. More creation & copying means things get slower._

There's nothing about the ++ syntax that makes it necessarily so. The compiler/interpreter could understand that we're getting a concatenated string and automatically only create one.

Which is the case in several languages.

<comment><USER12> What is different in Erlang is that strings are a bit messed up in that they are linked lists of numbers. What you are suggesting (constructing the actual string in-place) works fine in Erlang, too, but has a bit of a funky syntax:

        welcome_user(Username) ->
            << <<"Welcome ">>/binary, Username/binary, <<"!">>/binary >>.

However, the main advantage of using io_lists instead is that `["Welcome", Username, "!"]` has constant complexity with regard to the length of `Username`.

<comment><USER13> Note to anyone not already familiar: in Elixir, character strings are all binaries from the start. Just to avoid the notion that Elixir follows the mistake of strings-are-linked-lists from Erlang.

</comment></comment></comment></comment><comment><USER14> Go's philosophy around error handling (or lack thereof) is arguably atrocious compared to BEAM's "Let It Crash (And I'll Just Log It And Restart In 1 Millisecond With Exponential Backoff)" philosophy.

To review: [https://gobyexample.com/errors](https://gobyexample.com/errors)

Manually checking every possible error (and then, only in the spots where _you can imagine an error occurring_ ) is a heck of a lot of extra work for the programmer (and code for the code reader/reviewer) and _still_ won't catch all possible errors (both conceivable and inconceivable) properly. And arguably, the fact that an unchecked/undetected runtime bug in Go will basically send it into an "indeterminate state" which is impossible to reason about (much less debug), is an incredibly strong argument against this philosophy, IMHO. As far as I'm concerned, as soon as my code goes "off the beaten path" state-wise (read this as: "significantly differing from my mental model"), it _should_ crash, ASAP. Isn't every bug literally a situation the programmer didn't account for? Aren't runtime errors _by nature_ unexpected by the programmer? Why would you then give bugs and errors _even more room_ to corrupt the state of the world, then? ;)

We are all obsessed with computers and languages when the real limit is the programmer's mind and ability to reason about the code s/he's building and the states that code can get into. I think BEAM langs and purely functional langs more generally (along with functional/immutable data structures, etc.) do a much better job of addressing this _root_ problem. I'm going to quote John Carmack from his great blog post about functional programming here ([http://www.gamasutra.com/view/news/169296/Indepth_Functional...](http://www.gamasutra.com/view/news/169296/Indepth_Functional_programming_in_C.php)):

"My pragmatic summary: A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. In a multithreaded environment, the lack of understanding and the resulting problems are greatly amplified, almost to the point of panic if you are paying attention. Programming in a functional style makes the state presented to your code explicit, which makes it much easier to reason about, and, in a completely pure system, makes thread race conditions impossible."

<comment><USER15> While I agree wholeheartedly that Erlang's design is better:

To be fair, you can't get Erlang's semantics without also inventing processes and supervisor trees. And those things would be largely meaningless without immutability.

Erlang's magic comes from how all the puzzle pieces fit together into a whole: For example, with immutability comes the ability to always be able to restart from a known state, and probably greatly simplifies the internal implementation of the per-process heap.

Those things fundamentally change the language; Go couldn't adopt Erlang's semantics without eschewing almost everything that makes it "Go".

Error handling is really the least of it. Attempting to replicate some of Erlang's high-level design principles at a quickly lead to roadblocks. For example, goroutines cannot be killed; this means it's impossible to fully implement supervisor trees in Go. It's possible that the runtime could support this at some point, but it's a big can of worms.

<comment><USER16> Immutability probably does simplify a lot of things; but it isn't actually required to get Erlang's model, since Erlang isolates the state of processes from each other. Each process could have its own isolated mutable state as opposed to an immutable one and it wouldn't change the "let it crash" philosophy.

<comment><USER17> You can't guarantee that isolation without immutabilty, or at least forced copying.

In Go, it's extremely easy to accidentally send a pointer (or a data structure that contains a deeply nested pointer somewhere; this includes embedded maps, slices and channels, which are all reference types) on a channel, which is bound to break mutability guarantees at some point.

<comment><USER16> Mutable locals do not necessarily imply pointers...

<comment><USER17> No, but how do you pass "mutable locals" to other processes? That's the whole question.

If you pass a "local" on a channel to a different goroutine, Go can't guarantee to the receiver (which now has it as a "local" variable) that the sender (which still has it as a "local") won't change it:

        d := map[string]int{}
        ch <- d
        d["foo"] = 42  // Oops!

The only way to do this safely is to to write a channel abstraction which uses gob or similar to marshal and unmarshal all data, thus copying it and preventing concurrent mutation, and then always use the channel abstraction. But always copying tends to be terrible for performance. Erlang is able to do zero-copy sends to process mailboxes _because_ the data is guaranteed to be immutable.

Sure, you could instead mandate that senders never hold on to data sent on channels, but can you ensure this 100% across a codebase contributed to by an entire team?

<comment><USER18> > Sure, you could instead mandate that senders never hold on to data sent on > channels, but can you ensure this 100% across a codebase contributed to by > an entire team?

Isn't that precisely what Rust is all about?

<comment><USER17> Pretty much, yes.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> Author here. This was published a week earlier than expected so just a heads up that there are a couple of edits coming.

<comment><USER20> ZeroMQ is a library written in C++, not a server written in Erlang.

<comment><USER21> The presence of ZeroMQ in the list of projects built with erlang also made me frown as well. But in the author's defence, there is a pure erlang implementation of zeromq [0]

      [0] https://github.com/zeromq/ezmq

</comment></comment></comment><comment><USER22> That comparison was way better than I was expecting it to be. Go is still on my to-do list, but Elixir parts seem to be quite thoroughly described and without major mistakes. I also like the conclusion and to be honest this is how I always felt about the two. Definetly recommend reading this is if you're new to any of the two.

</comment><comment><USER23> I think a good way to increase creativity and productivity is to use the right abstractions of thought and craft. Every good(non leaky) abstraction expands the creative envelope further and lends itself to creation of new higher order abstractions for the next generation.

Having coded in imperative languages like Java, Python and C++, I had been on the lookout for a _practical_ general purpose language which provides good abstractions/high expressiveness. Elixir appealed to me more than Go in that regard. It's been six months since I started writing Elixir and it's been a pleasure.

</comment><comment><USER24> I still don't understand what all the hype is about pure functional programming.

Sometimes mutations are useful. There are lot of good programming design patterns which depend on mutations.

Also, always copying objects by value every time you call a function seems very expensive; especially if you're dealing with very large objects/structs/maps/strings which have to be processed by many functions.

<comment><USER24> I just had a thought; if arguments always get cloned by value every time they are passed to a function, doesn't that mean that the time complexity for an insertion operation in Elixir can never be better than O(n)?

According to this answer [http://stackoverflow.com/questions/11055391/time- complexity-...](http://stackoverflow.com/questions/11055391/time-complexity- of-erlang-dict) it claims that for dictionaries it's O(log n). How is that possible if mutations are not allowed? Wouldn't the function have to process at least n items? Or it uses parallel processing to get a speedup there?

<comment><USER25> If you are only dealing with Immutable structures that no one can really change, there is no point in passing by value. You can always pass by reference. The language will not allow any code to modify it. Instead a new variable will have to be assigned if the function changes the values. So, it can always be pass by reference until a change needs to be made aka copy on write.

</comment></comment></comment><comment><USER26> > It has since expanded into numerous other areas, such as web servers, and > has achieved nine 9s of availability (31 milliseconds/year of downtime).

I definitely want to read more about this.

<comment><USER27> This is how myths are created and perpetuated.

This claims from a study of a particular model of Ericsson's ATM switch whose software was written in Erlang.

A can tell you for sure that: * Ericsson has other switches and other telecom equipment whose software is written in C++ * other companies (Nokia, Cisco, Alcatel etc.) also built similar complex telecom equipment whose software was in C++

I'm going to bet that at least one of those devices was more reliable than that particular switch, because it's not the language that creates reliability but people writing and testing the software.

Some languages make it easier than others but attributing some magic qualities from extrapolating a single case study of a telecom equipment is just silly.

Telecom equipment is reliable because it has to be. If you're incapable of writing reliable software for telecom equipment then your company will go bankrupt and be replaced by one that can, even if the language they use is C++.

<comment><USER17> But suitability _is_ a huge factor here. The point isn't that "nine nines" reliability _cannot_ be achieved in C++ or whatever, it's that it's significantly harder and costlier to achieve.

But also: _Of course_ a language creates reliability. Null pointers are impossible in Erlang, whereas they are provable impossible to _avoid_ in C++.

So people bring this up because Erlang programs are pretty much reliable by default (assuming you stick to OTP and its design).

To help it reach insane uptimes, Erlang also has a few features that are hard to replicate in C++, if not impossible. The main one is hot code replacement; being able to incrementally upgrade a system in a safe and controlled manner without restarting it is a huge benefit in such a system.

It's also trivial to attach to a running Erlang program and introspect it as if you're truly running inside it. Goes hand in hand with hot code replacement. With C++, you get fairly crummy, low-level things like gdb, without the ability to actually write C++ code while in the debugger.

Also, remember that crashes can occur in bug-free programs. Hardware failures can be hard to predict and handle.

<comment><USER28> > Null pointers are impossible in Erlang, whereas they are provable impossible > to avoid in C++.

They are trivially possible to avoid in C++ as you do not have to use raw pointers. References, value types, custom non-null smart_ptrs, etc.

<comment><USER17> Not _trivially_ , no. Even if you try to avoid "raw pointers", C++ is an unsafe language by design, and it's non-trivial to turn it into a verifiably safe one:

* Even smart pointers are still pointers, which are trivial to access after release by mistake; and references are only safe as long as the caller still exists. C++ does not have anything like Rust's borrow checker.

* C++ threads allow race conditions that can screw up even smart pointers.

* Plenty of libraries (C and C++), which are usually impossible to avoid and completely impractical to vet, will still use raw pointers.

Generally, the word "trivial" and C++ don't go well together.

<comment><USER28> Note I was explicitly objecting about null pointers begin impossible to avoid. My claim is that the C++ type system allow avoiding them just fine.

I'm making no claim about general the memory safety of C++, and its issues are well known.

</comment></comment></comment></comment></comment></comment><comment><USER29> I am very intrigued in both. I am a reasonably experienced software developer with about 15 hours a week of availability, anyone wants to contract me? I'd gain experience with a modern language, you'd get someone on cheaper than experience would suggest. I know software engineers can use any language but in reality, if I were to get a full time job at a company which uses either of these I'd get a lot less money than I am getting now working with Drupal with 10+ years of experience in it. So I would like to gain some real world experience to make it easier to switch jobs later.

<comment><USER30> I feel this deserves its very own thread, because I too would like to do exactly the same as yourself.

</comment></comment><comment><USER31> > The biggest difference between the two languages is that compilation for the > destination architecture has to be done on that same architecture. The > documents include several workarounds for this scenario, but the simplest > method is to build your release within a Docker container that has the > destination architecture.

@brightball Go has had first class support for cross compilation for a while now, no?

<comment><USER19> I need to clarify that I was talking about that being an Elixir limitation. The previous paragraph talks about Go being able to cross compile no matter what system it's on but the one you highlighted still doesn't read well.

</comment></comment><comment><USER32> I know people will say "apples to oranges" but this is still exactly what I wanted to read. Thanks.

<comment><USER33> Agreed. It is apples to oranges but the article does an excellent job showing when/why to use each one. I believe the conclusion was spot on and IMO combining the stability of Elixir/BEAM with the performance of Go is the best of both worlds.

</comment></comment><comment><USER34> There was a good talk at Strangeloop about userland thread runtime scheduling in both the Go and the Erlang VM.

[https://www.youtube.com/watch?v=8g9fG7cApbc](https://www.youtube.com/watch?v=8g9fG7cApbc)

</comment><comment><USER35> The page (like many other pages nowadays) breaks page down - if I press the page down key I then have to scroll up a few lines because the text are obscured by the always-visible "FREE SIGNUP" banner at the top.

<comment><USER36> I'm responsible for this blog. Thanks for the feedback, we'll work on getting this fixed!

</comment></comment><comment><USER37> Really well written comparison that made me, as someone who has used go for a year, understand a lot more about Elixir.

</comment><comment><USER38> If I were putting together a new awesome Thing(TM), I think I would probably use elixir on the front end and internal messaging to handle and distribute jobs, and let go do the crunching and hard lifting.

<comment><USER30> That's the ideal setup really. Golang's concurrency is pretty decent as well but IMO Erlang/Elixir are much easier, quicker to code in, and more reliable than anything else I've ever used.

So basically use Golang as a modern C for specialized tasks which require [almost] the best your hardware can do, and use Erlang/Elixir for everything else.

</comment></comment><comment><USER39>
        The other trade-off that comes from mutable versus immutable data comes from clustering. With Go, you have the ability to make remote procedure calls very seamlessly if you want to implement them, but because of pointers and shared memory, if you call a method on another box with an argument that references to something on your machine, it can't be expected to function the same way.

I would be happy to know how we can make RPC seamless in GO accross multiple machines (clustering). I've missed a nice lib?

<comment><USER40> The stdlib has an RPC package, but there it also has great gRPC support [http://www.grpc.io/docs/quickstart/go.html](http://www.grpc.io/docs/quickstart/go.html)

</comment></comment><comment><USER41> Nice writeup! ZeroMQ is not written in Erlang. You probably confused with RabbitMQ, which is.

</comment><comment><USER42> _In Elixir, error handling is considered "code smell." I'll take a second to let you read that again._

I think that this makes a lot of sense. My experience in just about any language, is that the official means of error handling already feels like a code smell, even before you start using it. And if that's not the case, then it still manages to feel that way when used in a large project.

Lots of Smalltalk projects would actually handle errors by saving the image on an unhandled exception. For server applications, this was like having a "live" core dump where the debugger could open up right on the errant stack frame, and you could perform experiments to aid in debugging.

<comment><USER43> Funny you mentioned smalltalk. Alan Kay was talking about how Erlang is really an OOP language more so than other languages. In term of message passing and each process is an object...

Erlang just let it crash and you can restart it with a supervisor process. I think most of the time this model is much better since you won't be doing numerical stuff with BEAM anyway, it's not for it and it's too slow.

</comment></comment><comment><USER44> How does Crystal lang compare to the two?

I know the syntax is more similar to Elixir, but the format seems closer to Go in the sense that it compiles to a binary.

<comment><USER31> Swift would be a better comparison - both Crystal and Swift are general purpose languages that compile via LLVM. Neither has any special story for concurrency (yet). Go and Elixir/Erlang on the other hand, change your approach to programming.

<comment><USER45> What are you talking about? Crystal has a concurrency solution in their Channel implementation. They are not yet running in parallel, but it most definitely implement concurrency.

Or in other words, it is very inspired by the Go concurrency solution.

</comment></comment></comment><comment><USER46> The article states that Elixir functions must be in a module, during its comparison between Goroutines and one of the few methods of using concurrency in Elixir (there are others beside _spawn_ ). This description isn't entirely accurate. Named functions must be inside a module in Elixir, but anonymous functions don't have that requirement.

<comment><USER19> I realized I wasn't clear on that after the fact. I should have said defined functions. In my head I tend to think of defined functions and lambda functions as different.

</comment></comment><comment><USER47> The BEAM VM and lightweight processes seem amazing - I just wish they could be tied to a language syntax that wasn't so radically different from c/java/javascript and the like. Go code is almost immediately understandable because of this, whereas Erlang is perplexing.

<comment><USER48> Have you looked at Elixir syntax? Elixir is functionally the exact same as erlang, but with a more ruby-like syntax.

</comment></comment><comment><USER49> I think it's comparing apples with oranges. They are two different species a compiled vs VM based language, one is a functional styled vs other has duck- tapping. Only thing I can see common is GC and a somewhat but very different concurrency programming paradigms, with message passing. Erlang and BEAM is an aged old giant with battle tested proven reliability, while golang is young lad with the flash like abilities everyone has been longing for. While you get awesome stuff like Hot-Reloading, Go lang gives you compiled code that can run heavy loaded servers on my RaspberryPi (I made one and tried all Erlang, NodeJS, and Golang believe me Golang smokes them all on memory footprint [http://raspchat.com](http://raspchat.com) ). I can go on and on and on! But picking one is totally dependent on your scenario.

<comment><USER50> > They are two different species a compiled vs VM based language

This is an implementation detail.

Anyone can write a VM for Go, or an AOT compiler to native code for Elixir.

<comment><USER51> Pretty significant detail though, as no one has done either.. also "anyone" is fairly strong, building decent compilers and interpreters is pretty difficult

<comment><USER50> Anyone with a decent CS degree should be able to produce working compilers and interpreters, otherwise it wasn't a decent degree.

Of course, writing very good ones is a different matter.

<comment><USER11> > _Anyone with a decent CS degree should be able to produce working compilers > and interpreters, otherwise it wasn 't a decent degree._

Which would be useless for production without several years of maturity, a tools ecosystem, and a community adopting them -- and of course continued support.

So this is mostly theoretical.

<comment><USER50> So now compilers should only be written, if v1.0 is production ready?!

> So this is mostly theoretical.

No, it is setting the facts straight about the widespread ignorance of mixing languages with implementations.

<comment><USER11> > _So now compilers should only be written, if v1.0 is production ready?!_

No, but they are only relevant for the purposes of the discussion, that is, when considering whether to adopt a language platform based on if it's AOT or interpreted etc, when they are v1.0.

That somebody can always make an interpreter for an AOT language, for example, is nothing people care about when checking whether to use a language for their projects. It's what's there that matters.

<comment><USER50> Turning on cynic mode, I would say the only thing that matters is which company backs a programming language and only languages offered on their OS SDKs are relevant.

Anything else will just add entropy and development costs to projects, due to 2nd class tooling and lack of libraries on the target platform.

Then it doesn't matter how the code gets compiled at all.

<comment><USER11> > _Turning on cynic mode, I would say the only thing that matters is which > company backs a programming language and only languages offered on their OS > SDKs are relevant._

That's true, but for application programming. For the server side there are other considerations. WhatsApp can get away with using Erlang for example, and still get the sweet billions.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER52> [Deleted] Originally I'd had an off the cuff remark here of "apples to oranges". I'd like retreat to say that the article is actually a good overview and comparison

<comment><USER53> Nothing wrong with comparing apples and oranges. How else would you decide which is best for any given use case?</comment></comment>


The Case for Writing Papers in Economics Using FaKe LaTeX [pdf] - <AUTHOR> http://www.farmdoc.illinois.edu/irwin/research/The_Case_for_Fake_LaTeX_Body_Feb%202018.pdf <comment> cup-of-tea I don't understand why LaTeX is considered hard. I wish people would try TeX out first as well. You literally type stuff and a paragraph comes out. Enter a blank line to separate paragraphs. It can't be much easier. LaTeX just adds some macros to make it easy to make a title and section headings etc. Once you become proficient at entering equations in TeX it's incredibly fast. And you won't even need to render them to read them after a while.

> One can achieve something like 95% of the visual appearance of native LaTeX > documents with a one-time investment of an hour or less work

Yes, and one can use LaTeX and achieve 100% with a similar one-time investment. I really don't understand this. To produce the document presented here LaTeX has absolutely no extra overhead compared with any other tool.

I suspect the misconception comes from the complicated looking tools like TeXnicCenter etc. If people saw me writing LaTeX in emacs (with zero buttons or other complications) they wouldn't think it was complicated. It's just text.

Still, if people insist on using Word for whatever reason I'm glad if they make the documents look nice like this one, even if the page geometry is way off (use Komascript).

<comment><USER2> _"I wish people would try TeX out first as well."_

Do you by any chance have any TeX tutorials to recommend?

<comment><USER3> My favourite TeX tutorial, which will turn you from beginner to expert and make you fall in love with TeX (maybe), is the book _A Beginner 's Book of TeX_ by Seroul and Levy. It comes highly recommended by Hans Hagen in the ConTeXt manual. (It's not free—published by Springer—but you can find it in the usual places you find books: libraries, whatever.)

</comment></comment></comment><comment><USER4> Lots of comments pointing out how obvious it is that the paper was not typeset with real LaTeX, but I think that's a little beside the point. Scott isn't arguing that it looks 100% as good as LaTeX. The article cites research that suggests that writing in LaTeX hurts productivity, even for expert users:

 _We show that LaTeX users were slower than Word users, wrote less text in the same amount of time, and produced more typesetting, orthographical, grammatical, and formatting errors. On most measures, expert LaTeX users performed even worse than novice Word users_

<comment> pseudonom- I think that paper came up on HN before and IIRC the tasks they were measuring were things like manually positioning some figure in an arbitrary position. This is not a use case LaTeX optimizes for or one that comes up often in my experience.

Edit: See [https://news.ycombinator.com/item?id=8797002](https://news.ycombinator.com/item?id=8797002) for an earlier discussion of the referenced paper.

</comment></comment><comment><USER5> LaTeX isn't that hard, Microsoft equation editor is slow, and don't even get me started on how much more time consuming it is to put in references, tables of content, etc.

The first equation in the paper is

$$\Delta P_t = \mu + \sum_{j=1}^J \lambda^j S^j_t + \sum_{p=1}^P \delta_p \Delta P_{t-p} + \varepsilon_t$$

Yes, it's a bit of a mouthful but clicking all of those symbols in equation editor is much slower once you know the syntax.

<comment><USER6> Pseudo-LaTeX syntax works in Word's new equation editor (introduced in Office 2007). I can't test, but I suspect your equation works as-is in Word.

<comment><USER7> I can test for the class. It's close, the curly brackets aren't used for grouping in MathType:

[https://i.imgur.com/T9JxuH5.png](https://i.imgur.com/T9JxuH5.png)

Fixing that for the summation terms and t-p subscript produces:

        \Delta P_t = \mu + \sum_(j=1)^J \lambda^j S^j_t + \sum_(p=1)^P \delta_p \Delta P_(t-p) + \varepsilon_t

[https://i.imgur.com/Imix6GU.png](https://i.imgur.com/Imix6GU.png)

where Word doesn't realize that the terms after the sum should be the content of the sum. Word Help and the equation editor are thoroughly unhelpful in deducing the appropriate syntax of \sum.

What I eventually divined was that the syntax is state-based: If you type it out manually, it will put your cursor into the right position, and once you're done with _t you need to hit the right arrow key before typing the space and plus symbol. Copy-pasting the whole thing is different and does not work.

I mean, it's great that it supports an entry mode that's faster than digging through menus and clicking on symbols with your mouse. But it's still fundamentally different and, dare I say, inferior when the appearance of the equation isn't defined by the sequence of characters you enter (or copy-paste) but by the sequence of arrow keys and escape keys you hit while you type it in. This is exactly the problem with Office vs. LaTeX.

<comment><USER8> If you type a space after P_t it will figure out it's a subscript. That is, after you copy-paste your text you can hit space a few times to wake it up to the fact that it needs to render it.

</comment></comment></comment></comment><comment><USER9> In my experience the abstract statement "The downside is that it is a very time intensive and complicated method of writing papers. " is just incorrect.

There is a bit of a learning curve, but once you are past that it is much _less_ time intensive that writing papers in a word processor. This effect is magnified with longer documents.

That may be somewhat domain specific. And to be open about my biases, I also think that Word's "track changes" is a pretty poor collaboration tool.

<comment><USER10> Hahahahaha

I might be going to downvote hell for this, but as a computer scientist writing papers for a living, every hour spent writing latex belies your comment.

By the way, Context is a much saner alternative, although it still shares many of Latex' core flaws.

Unfortunately, that doesn't matter because most conference mandate use of their Latex or (ugly) Word template, and using Word is cause for ostracization.

You are also correct to say that version control is a big advantage of Latex. I wonder why Microsoft hasn't come up with a better competing solution.

<comment> cup-of-tea How many papers have you written? Have you written a master's or PhD thesis? How exactly are you spending your hours writing LaTeX? It sounds like you are doing it wrong.

<comment><USER10> You're two links away from the answer, person that obviously wants to have a good faith conversation.

<comment> cup-of-tea It took me a while to figure out what you meant. I've never looked at people's profiles on here before. I couldn't imagine writing my thesis in anything but LaTeX. Or rather, anything that didn't support both high-quality typesetting and programming. I had little programs written in my .tex files which would generate some of the tables and figures. TikZ is wonderful. I aimed for nothing less than TAoCP level of quality.

<comment><USER10> The output of Tex is superior to anything else. I doesn't change the fact that the user experience is awful.

But if you want Tex quality with less head-bashing, Context is much better than Latex. It's what I use for my thesis, but not for my papers -- templates are all Latex, and I didn't know about it at the time.

Also I disagree with your basic point: hours of my time are worth much more than some fancy ligatures and fluff that makes the text look very marginally better.

</comment></comment></comment></comment></comment></comment><comment><USER11> Why not using LyX? It writes LaTeX for you with minimal effort and knowledge.

This article screams non-LaTeX in the title already. The word LaTeX should be rendered as [http://site.uit.no/futurelab/files/2013/10/latex- logo.png](http://site.uit.no/futurelab/files/2013/10/latex-logo.png)

<comment><USER12> +1

I've found that writing in LyX is _faster_ than writing in Microsoft Word and friends. It forces you to focus on content (hence the WYSIWYM) and greatly accelerates equation entry with keyboard shortcuts and live preview.

</comment></comment><comment><USER13> I think the point I would make in favour of actually using LateX is that whilst evidence may indicate Word is quicker, the time I spend in Latex is (as a programmer) better spent.

I mean that in the sense that because the interface is basically a compiler compiling my code I can logically reason about what it's doing, and have reproducible results. I can tell it where I can tell it how to take care of images and be confident it will follow my guidance. This is especially important in larger documents. In Word, editted page 3 is as likely to change the layout of page 72 as an edit on page 72 is, and an edit on page 3 will have an equal chance of effecting the layout of page 4-N.

In Latex with very few exceptions I do not manually layout any part of the document, I design the rules for how the document is laid out. Obviously that is more time consuming - as solving the general problem is always more painful than a point fix.

This really pays off when your dissertation is due in 2 days and you're trying to cut 150 pages down to 100. You can focus on content, not why Bill Gates personally believes that _any_ image is a graven image and is therefore forbidden.

</comment><comment><USER14> "I conclude that appearance/aesthetics is the dominant reason for widespread adoption of LaTeX". I fully disagree. IMHO, the dominant reason is that Microsoft word has been a nighmare for scientific documents. The different generations of equation editors were buggy and incompatible. You can not edit an old document using a recent version of word. You can not exchange documents with people using a different version of word. For most people, when you can not use word, the only choice for scientific documents is LaTeX.

Even if recent versions of word are less buggy, people will migrate slowly.

</comment><comment><USER15> Link seems broken atm :(

Regarding the efficiency though, I would think (even disregarding new users of LaTeX) it would really depend on the length and content of the paper.

For longer papers with many formulas I'd pick straight LaTeX any time. Beside the formulas and look, this way once something looks good, it probably won't break in many unforeseen ugly ways when stuff is changed or added elsewhere. This in my experience is not the case with word processors, where you really need to review the whole document after any edit. Plus, working with text in a text editor is so much more efficient and enjoyable.

For things like slides and notes though, particularly when there are a lot of screenshots/graphics/tables/etc. in proportion to text, it's somewhere about 50/50 between Word and org-mode, which I then compile into pdf through either LaTeX or html. But I have accumulated a lot of templates and customization for the latter option to work well; without them, I would just be using Word.

Another factor is whether, and how often, it is going to be necessary to update the document with changed figures/tables/etc. This depends on how they are generated: if they come from an Excel spreadsheet, things work much smoother embedding them in Word; if they are generated by some code running, it's much easier to have the LaTeX document pick them up.

</comment><comment><USER16> If the person already knows markdown, Pandoc is a great option [0]. I find it really useful for creating pdfs. I haven't used it to create official documents that often, but I have used it to create Beamer slides and it was a very smooth experience. If you're an advanced user and you want to do something LaTeX-specific you can just write LaTeX inline and Pandoc will accept it.

[0] [http://pandoc.org/](http://pandoc.org/)

</comment><comment><USER17> The referenced article concerning the speed of Latex vs Word can be read freely online [0].

I remember reading that article shortly after it was published. They conducted an experiment in which participants were instructed to typeset a piece of work from scratch in thirty minutes in either Latex or Word. Since Latex is most valuable and efficient when writing a large document such as a book, containing multiple chapters, citations, cross-references and potentially images, the study is almost meaningless. The only conclusion I would draw from it is "if you want to type something small up real quick, maybe consider something other than Latex".

[0] [http://journals.plos.org/plosone/article?id=10.1371/journal....](http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0115069)

</comment><comment><USER18> If this PDF is supposed to convince me that this 'fake' LaTeX is somehow able to produce results which come close to the real thing it fails rather miserably. Yes, it is set in some variation of Computer Modern [1] and the basic layout sorta-kinda looks like that produced by commonly used LaTeX templates. That said, the PDF distinctly looks like something produced by MS Word due to its rather characteristic (problems with) spacing and kerning. It also does not look the results produced by the AEA template [2] but that might be by choice.

Writing the same document using something like LyX is probably easier than using "FaKe LaTeX" with the added advantage of using LaTeX templates to provide a uniform look. The only real advantage of this "FaKe LaTeX" is the possibility to directly use a spread sheet program for tabular data.

[1] [https://en.wikipedia.org/wiki/Computer_Modern](https://en.wikipedia.org/wiki/Computer_Modern)

[2] [https://www.aeaweb.org/journals/policies/templates](https://www.aeaweb.org/journals/policies/templates)

</comment><comment><USER19> Tangentially related: I recently learned that Satoshi's original paper on bitcoin was not actually written with LaTeX. It seemed to have tricked a lot of people (including myself).

[https://tex.stackexchange.com/questions/306754/was- anything-...](https://tex.stackexchange.com/questions/306754/was-anything-in- satoshi-nakamotos-original-bitcoin-paper-compiled-in-latex)

</comment><comment><USER20> This is rendering very badly for me in Firefox. The font is very hard to read - some parts of it are so thin, they appear invisible. ([https://screenshots.firefox.com/LHvHiygRGnaPkhsy/www.farmdoc...](https://screenshots.firefox.com/LHvHiygRGnaPkhsy/www.farmdoc.illinois.edu))

It looks mostly fine in a desktop viewer though.

</comment><comment><USER21> Of course, the point is moot if the journal you're submitting to only takes LaTeX.

<comment><USER22> Sadly, most journals that I might submit to require Word. I published a paper in transportation a while back, and happily submitted my manuscript for review as an immaculately formatted PDF.

It was reviewed and accepted, which meant that they sent me the final, _accepted_ paper submission guidelines that stipulated... Word.

</comment></comment><comment><USER23> Using LaTeX is like writing a program to automate something you do a lot:[1] lots of effort up front for payback down the line. Once you work out how to use it and iron out the kinks in your templates, it becomes much easier, permanently. Whereas with Word, while you'll get started much quicker, every sufficiently complex document will break in new and strange ways that require extreme dexterity with a mouse and a good deal of random fiddling to fix.

[1] [https://xkcd.com/1319/](https://xkcd.com/1319/) (ignore the bottom graph)

</comment><comment><USER24> But is this paper written in faKe LaTeX?

I assume it is, because the author writes "As a non-LaTeX user", but I'm having trouble verifying this by eye otherwise. Which I suppose is the point.

<comment><USER25> Oh yes, it is. My teeth hurt while reading it. There is much, much more to TeX typesetting than just the Computer Modern fonts (which many find unattractive, by the way).

<comment><USER26> One of the benefits of LaTeX is supposed to be easy switching between fonts.

I don't think I've ever seen something in LateX that didn't use Computer Modern!

<comment> cup-of-tea Maybe you just didn't know it was LaTeX if it wasn't Computer Modern? I typeset my thesis using Minion and Optima.

</comment></comment></comment></comment><comment><USER27> If we care about substance over form, papers should be written in some type of markdown -- leave publishers, or readers even, to impose a format.

<comment><USER28> The substance often is the equations, not the words. I don't really want to write equations in markdown, and I don't want some publisher trying to impose a format on my equation. _I_ want to format it, so that my readers read _my_ equation, not what some publisher thought it said.

<comment><USER27> Then presumably, you are either comfortable with LaTeX or else are capable of asking your publisher to respect your wishes. For writers who are not familiar with publishing tools, I would humbly submit that a markdown language that formats deterministically for publication would be superior to wrangling with MS-Word.

<comment><USER28> Well, I can get LaTeX (or more precisely, LyX) to do what I want, so that on the PDF, the equation is _exactly_ what I want it to be. I don't know if I'm "comfortable" with it (though Lyx is _far_ easier to use than LaTeX). But I think I have no choice. [Edit: I have no choice because the publisher doesn't understand my paper, and doesn't understand the equations in it. The publisher may make a change without even realizing it, and the change _may really matter._ It's my paper, and it's my responsibility that the equations are right.]

Second best would be "asking your publisher to respect your wishes" in the form of looking over galley proofs, to make _sure_ that the equations came out right.

</comment></comment></comment></comment><comment><USER29> I can't tell. Is this genuine, or is it some kind of Poe's Law ([https://en.wikipedia.org/wiki/Poe%27s_law](https://en.wikipedia.org/wiki/Poe%27s_law)) thing?

People say pretty silly things about TeX and LaTeX, but this is so obviously silly that I thought of it as being like an April Fool joke. On the other hand, the sprinkling in of admiration for DEK, for instance, doesn't mesh with that.

<comment><USER30> The OP is definitely serious. Some people just cannot stand TeX.</comment></comment>


New Redis Fork with SSL and Transactions - <AUTHOR> http://www.dr-josiah.com/2018/04/yes-im-forking-redis-ssltls-transactions.html <comment><AUTHOR> I'll be around here and in the similarly named Reddit post, feel free to ask questions.

<comment><USER2> It looks like most of the discussion is here: [https://news.ycombinator.com/item?id=16941992](https://news.ycombinator.com/item?id=16941992)

<comment><AUTHOR> Thank you! I didn't catch that when it started.</comment></comment></comment>


First AI universe sim is fast and accurate – its creators don't know how - <AUTHOR> https://phys.org/news/2019-06-ai-universe-sim-fast-accurateand.html <comment><USER2> AI scares me. Even though I've used neutral networks and even more complex models/networks in projects and have a fair understanding of how they work, they still scare me a lot. Even though we are far away (supposedly) from creating a sentient AI, I can't help but think that AI will turn into something like "I am Mother" rather than C-3PO.

And yes, I understand that AI and machine learning can help us in ways that will advance our abilities in medicine, science, etc but we're human. if something can be used for evil, we should be sure that that will be attempted. We, as a species, have an annoying need of being the first and having control of everything. Only that AI _may_ , in the future, be uncontrollable.

<comment><USER3> As far as AI are concerned, there is no intelligence in them - at all.

As far as understanding what intelligence is - we have a long way to go on that as well.

What these system can do, is process a large quantity of data and then match against a specific set of criteria. The problem is not the computer system but the actions taken by real flesh and blood people who do not question what these systems put out.

<comment><USER2> Yeah,and that's the point I was trying to make about right now. But at some point we'll find ourselves in the position of having created general intelligence. Be it smarter than us or not. In the case of this model, it "could accurately simulate how the universe would look if certain parameters were tweaked [...] even though the model had never received any training data where those parameters varied."

This means that it somehow was able to figure something specific out based on data that had nothing to do with it. Whether by accident or because there's a correlation that we haven't yet figured out, this model was able to understand it. And that's amazing and scary at the same time.

<comment> a0-prw > But at some point we'll find ourselves in the position of having created > general intelligence

Why do you believe that ?

</comment></comment></comment></comment><comment><USER4> Anyone else have a problem with phys.org? The website fails to load, chrome, UK.</comment>


Coronavirus Spreads Alarmingly in Open Space Offices - <AUTHOR> https://www.corona24.news/c/2020/04/28/new-coronavirus-spreads-alarmingly-in-open-space-offices.html <comment><AUTHOR> The outbreak occurred in a building where the commercial offices were located on the first 11 floors, and the rest was occupied by residential apartments.

Of the 1,143 people tested for COVID-19 in the building, 97 were diagnosed positively and 94 of them worked on the 11th floor, for a call center with 216 employees, indicating an infection rate of 43.5%, says researchers in a study published in the CDC Medical Journal.

</comment><comment><USER2> > ABOUT US

CORONA 24 News is your news, entertainment, music fashion website. We provide you with the latest breaking news and videos straight from the entertainment industry.

Seriously? Given the state of the linked article, it looks like a scraping site, edited together badly by semi-literates.

</comment><comment><USER3> Original paper:

Park SY, Kim YM, Yi S, Lee S, Na BJ, Kim CB, et al.

Coronavirus disease outbreak in call center, South Korea.

Emerg Infect Dis. 2020 Aug. doi:10.3201/eid2608.201274

[https://wwwnc.cdc.gov/eid/article/26/8/20-1274_article](https://wwwnc.cdc.gov/eid/article/26/8/20-1274_article)</comment>


Mod_rewrite plays tic-tac-toe - <AUTHOR> http://material5.tumblr.com/post/3599567441/how-to-configure-apache2-to-play-tic-tac-toe-with

<comment><USER2> This is one of the weirdest applications of mod_rewrite I have ever seen. Cool :)</comment>


Statistical and Machine Learning forecasting methods: Concerns and ways forward - <AUTHOR> https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0194889 <comment><AUTHOR> "...the worse Stat forecasting method was more accurate than the best of the ML ones..."

[https://twitter.com/spyrosmakrid/status/1172499153869529088](https://twitter.com/spyrosmakrid/status/1172499153869529088)</comment>


Bitstamp's broken matching engine mismatches orders 7% below market price - <AUTHOR> http://blog.tian.io/bitstamp-has-a-broken-matching-engine

<comment><USER2> A la Cryptsy?

</comment><comment><USER3> I've had order executed incorrectly in the past. Given their support doesn't respond in weeks, I didn't even bother reporting it.</comment>


Poisonous MD5 – Wolves Among the Sheep - <AUTHOR> http://blog.silentsignal.eu/2015/06/10/poisonous-md5-wolves-among-the-sheep/ <comment><USER2> The relevance of the article's mention of the "Flame" malware was puzzling, since no context is provided and the linked Wired article doesn't shed any light.

Wikipedia has this to say, which seems to solve that puzzle:

"Flame was signed with a fraudulent certificate purportedly from the Microsoft Enforced Licensing Intermediate PCA certificate authority. The malware authors identified a Microsoft Terminal Server Licensing Service certificate that inadvertently was enabled for code signing and that still used the weak MD5 hashing algorithm, then produced a counterfeit copy of the certificate that they used to sign some components of the malware to make them appear to have originated from Microsoft. A successful collision attack against a certificate was previously demonstrated in 2008, but Flame implemented a new variation of the chosen-prefix collision attack."

[http://en.m.wikipedia.org/wiki/Flame_%28malware%29](http://en.m.wikipedia.org/wiki/Flame_%28malware%29)

<comment><USER2> Whoops - I didn't remember that Wikipedia uses a separate domain for mobile browsers.

Here's the 'real' link: [http://en.wikipedia.org/wiki/Flame_%28malware%29](http://en.wikipedia.org/wiki/Flame_%28malware%29)

</comment></comment><comment><USER3> I'm no security expert, but I have a question.

In some systems I've built in the past I employ MD5 as a hashing mechanism to verify firmware integrity after flashing it in the memory. I don't use MD5 for anything security related (this is treated in other ways, depending on the system), just to check transmission and memory integrity.

Is MD5 still considered fine for this, or is there a real risk that random or systematic (but unintentional) noise could generate a collision between corrupted and original data? I do believe it should suffice, but hearing all the badmouth makes me wonder...

<comment> andrew-lucker MD5 is good enough to prevent most _random_ collisions. The problem is when you need to prevent _intentional_ collisions.

<comment><USER4> As a note, even CRC32 is enough to check most random collisions.

<comment><USER3> I actually thought of using CRC32 when developing my first system, but I preferred MD5 because it would be easier and clearer for people to check file integrity in a *NIX command line.

</comment></comment></comment></comment><comment><USER5> Aren't all hashing algorithms vulnerable to the possibility for collisions (albeit with different degrees of difficulty)? It sounds like the problem here is more related to the logic that relies on a hash alone to make important decisions.

Not saying that MD5 is a good choice in this case, just that we may be blaming the wrong thing.

<comment><USER6> Your parenthetical is the key, though. There's a big difference between a hash algorithm where generating a collision requires a few minutes of work on a cheap computer (MD5, now) and a hash algorithm where generating a collision requires a computer the size of the universe operating for a trillion trillion years (any good cryptographically secure hash).

<comment><USER5> Cool - didn't realize the difference was so great. I've always known that the good algorithms are better because they're more difficult to brute-force, but always wondered if it's just a matter of a few years before the "impossible" becomes possible. Your illustration helps clarify that improbability in my mind - thanks!

<comment><USER7> >always wondered if it's just a matter of a few years before the "impossible" becomes possible.

This is from 1998 but the relevant parts - [https://www.schneier.com/essays/archives/1998/05/the_crypto_...](https://www.schneier.com/essays/archives/1998/05/the_crypto_bomb_is_t.html)

>Cryptographic algorithms have a way of degrading over time. It's a situation that most techies aren't used to: Compression algorithms don't compress less as the years go by, and sorting algorithms don't sort slower. But encryption algorithms get easier to break; something that sufficed three years ago might not today.

>Cryptographic algorithms are all vulnerable to brute force--trying every possible encryption key, systematically searching for hash-function collisions, factoring the large composite number, and so forth--and brute force gets easier with time. A 56-bit key was long enough in the mid-1970s; today that can be pitifully small. In 1977, Martin Gardner wrote that 129-digit numbers would never be factored; in 1994, one was.

>Aside from brute force, cryptographic algorithms can be attacked with more subtle (and more powerful) techniques. In the early 1990s, the academic community discovered differential and linear cryptanalysis, and many symmetric encryption algorithms were broken. Similarly, the factoring community discovered the number-field sieve, which affected the security of public-key cryptosystems.

DES was used in the 70s, now it can be brute forced in a few days (with the right hardware).

<comment><USER5> I suppose one could say this is an argument against using the "computer the size of the universe operating for a trillion trillion years"-type illustrations. Statements like that reflect the current theoretical strength of an algorithm, but unfortunately the illustrations can lead us to (wrongly) assume that flaws won't be discovered in the algorithm for that period of time, which is very much untrue and undermines the practical implications of those statements.

<comment><USER7> No arguments from me that cyptography is often explained confusingly which leads to misunderstandings.

</comment></comment></comment></comment></comment></comment><comment><USER8> I don't get why it is a security problem that someone can manufacture false positives for an anti-virus. What is the benefit for a virus to have non- malicious code caught by the anti-virus?

False negatives would be more of an issue if the anti-virus has white lists and one can manufacture a Microsoft Excel MD5 signature with a malware. But that's not what the article refers to.

MD5 is only broken if you want to use it as a non-reversible hashing algorithm or if you want to use it as a an unforgeable signature. But it's perfectly fine for many other usage.

<comment><USER9> From the article:

      As you can see, binaries submitted for analysis are
      identified by their MD5 sums and no sandboxed execution is
      recorded if there is a duplicate (thus the shorter time
      delay). This means that if I can create two files with the
      same MD5 sum – one that behaves in a malicious way while the
      other doesn't – I can "poison" the database of the product
      so that it won't even try to analyze the malicious sample!

So it's a technique to get the scanner to ignore a malicious binary by constructing a non-malicious one with the same MD5 sum. This would be much harder if the scanner used a SHA-1 hash or similar.

<comment><USER8> But that's a white list. But I thought anti-virus rather work by black listing.

<comment><USER10> virustotal.com allows you to upload files to scan with a whole range of anti- virus programs. Before uploading, it will calculate the hash of your file client-side to see if the file should be uploaded or if a previously uploaded (by someone else) file with same hash should be re-scanned with newer versions of the anti-virus.

I don't know which hashing algorithm they use but just as example of a situation where whitelist is not used.

<comment><USER9> Yes, I think that's what the author was alluding to here, although I'm not sure:

      The approach may work with traditional AV software too as
      many of these also use fingerprinting (not necessarily MD5)
      to avoid wasting resources on scanning the same files over
      and over (although the RC4 encryption results in VT 0/57
      anyway…).

</comment></comment></comment></comment></comment><comment><USER11> This is actually one of the older and easier attacks against MD5; we've known this was possible for over a decade. Nowadays it's actually possible to so chosen prefix attacks - you can literally take two arbitrary, unrelated files and append some data that makes them have the same MD5. So you don't even have to include the malicious code in the decoy file in any form anymore.</comment>


An app to save sites / read later - <AUTHOR>

Hey there,
I read quite a lot of articles off HN, I usually have all 8 tabs in my iPhone full of sites sites I've read but want to save. Often I will email myself the link, however then it gets caught up in my inbox and not the best way to search.
Is there an app/site where I save these urls, tag them and possibly even take a image/pdf of the site, so if it goes down or offline reading I can still access the content.
Something like Delicious but it doesn't seem to do the offline part.
What do you use to keep track of interesting links? <comment><USER2> I think you want two services here; Instapaper for the offline reading part, Pinboard for the archive part. I use Instapaper for the 'read later/offline' stuff, as a) it works on the web, iPad, iPhone, & Kindle and b) it's great at syncing. Pinboard will let you save URLs and tag them, and with a pro account it'll keep a copy of the page for you.

</comment><comment><USER3> You should check <http://getpocket.com>

<comment><AUTHOR> Thanks, this is looking like what I wanted.

</comment></comment><comment><USER4> I use readability, it even has the option to send to my kindle directly.

</comment><comment><USER5> kippt.com, then I send most of my "read later" stuff to my kindle.

</comment><comment><USER6> you will not beat instapaper.</comment>


Top Gun 2 Officially Moving Forward - <AUTHOR> https://twitter.com/sunriseon7/status/867139377314516992?ref_src=twsrc%5Etfw&ref_url=http%3A%2F%2Fuproxx.com%2Fmovies%2Ftom-cruise-confirms-top-gun-sequel%2F <comment><AUTHOR> I wrote a treatment about F-22 Fighters versus UAVs - and eventually as a Hybrid attack team - so I wonder if I might like their concept even better than mine when it all comes around. I'm a sucker for great airplane footage. The Top Gun 3D Blu Ray surprised me how much I liked the effort.</comment>


Check out 300+ ready-to-use WebGL examples - <AUTHOR> https://cdn.soft8soft.com/demo/examples/index.html <comment><USER2> Wow. Looks like a shameless rip-off of Three.js. Doing a search and replace of 'THREE' to 'v3d' is, frankly, disrespectful, IMHO.</comment>


Show HN: Dashboard of public NHTSA data - <AUTHOR> http://demos.zoomdata.com/nhtsa-dashboard/

<comment><USER2> Care to share details on the technical implementation? What do you have powering the backend?

<comment><AUTHOR> Sure! Full Disclosure: I run frontend engineering for Zoomdata. Zoomdata is powering the backend, it's a server that connects to big data sources. In this case, Cloudera Impala, but we also connect to plenty of other big data stores like Elastic Search, Solr, etc. Zoomdata queries those big data stores, then streams the results over a websocket to visualizations. We have a web interface for analyzing your data in standard charts, but we also allow for total customization of visualizations (like for building this dashboard). Those visualizations can be embedded using iframes, or a more advanced approach using a javascript library. I used our javascript library to embed these visualizations into my own web based dashboard.

You can find out more at our website: [http://www.zoomdata.com/](http://www.zoomdata.com/)

And we're hiring experienced JS devs in the bay area!

</comment></comment><comment><USER3> Awesome! Great design and really useful!</comment>


How to Make Millions as an Art Forger - <AUTHOR> http://www.bloomberg.com/news/articles/2015-05-21/here-s-how-to-make-millions-as-an-art-forger

<comment><USER2> My favorite forger is [http://en.wikipedia.org/wiki/Tom_Keating](http://en.wikipedia.org/wiki/Tom_Keating). He would forge paintings, making sure that they were provably fake (impossible materials, FAKE written in lead paint under the painting, that sort of thing), give them away for a song, and let people fool themselves into believing that they had the real thing.

The greatest irony of his story is that some of his fakes are now worth more than the original artists he faked!

</comment><comment><USER3> _> If someone tries to sell you the Mona Lisa, there's a pretty easy way to check if it's real: Just go to the Louvre to see if the original's still there._

Around 1911, this approach was supposedly reversed - the work was stolen, and forged copies were sold - or so the story goes - search for "Valfierno" in:

[http://priceonomics.com/how-do-you-make-money-off-stolen- art...](http://priceonomics.com/how-do-you-make-money-off-stolen-art/)

</comment><comment><USER4> It's interesting to me how the art world seems to stand alone on their opinion about copies. Literature, music, software... in every other area we believe that if a copy can't be told from its master they must both have equal value. I can't imagine someone saying that they'd rather buy the hard drive someone saved their work on instead of a copy transmitted over the network.

Maybe art collectors are wrong about forgeries - if forgeries don't provide the same mental dividend that real paintings do, wouldn't you be able to tell the difference without an X-ray machine?

<comment><USER5> A lot of the prices of pieces of fine art aren't just tied to the aesthetics, but have to do with artifacts that are scarce and desirable. An Apple I isn't really desirable as a computer, but because it's an Apple I, made by Woz at that time and hard to get. A Nintendo World Championship cartridge might sell for $100,000, but it's due to the same factors, not that people really want to play a game they could still play on an emulator. First editions of novels and other rare books and rare vinyl albums are the same way. It's not just the content of the thing, it's the scarce desirable artifact that holds that content.

<comment><USER6> Agreed. To add to the historical artifact point; with artworks a part of the value in the artifact is what the rest of the art world was doing at the time. What we take for granted today hasn't always been so and often notable pieces of art are recognizable for their place in the evolution of an art, be it fine art or technology.

</comment></comment></comment><comment><USER7> If anyone is interested in selling replicas contact me.</comment>


This Model for Events Sounds Dumb and Obvious - tefo-mohapi http://www.iafrikan.com/2016/03/08/open-source-business-model-that-may-disrupt-how-events-are-done/ <comment><AUTHOR> The reason nobody is doing it is because a collection of online videos and chat group is _not an event_. You go there to meet people, see the speakers in person and maybe have an informal chat over some beer. This is completely orthogonal to watching online videos alone at home.

<comment> tefo-mohapi But events are mostly expensive and waste of money as author notes. Few barely make a profit.

<comment><AUTHOR> I don't think either matters. They don't need to make profit, usually being community events, and are as "wasteful" as going to a concert or meeting friends at the bar, except you also get to learn new stuff and expand your network.

<comment><USER2> #@theAuthor In my country the cost of doing an event can fund 2 startups of 3 founders for 9 months, can build a maker-space, or introduce internet to a whole village. A lot of people want to attend, but can't afford because they live in remote places, they don't come to get drinks take pictures, or network, they just want to learn. This is an optimization sprouted from the local constraints of Morocco and similar African countries. Your opinion is most welcome</comment></comment></comment></comment>


Ursula Le Guin's Writing Was Shaped by Anthropology (2018) - <AUTHOR> https://www.sapiens.org/culture/ursula-le-guin/ <comment><USER2> > In The Dispossessed, she contrasts the different political systems of two > neighboring worlds, not to argue which one is best, per se, but to show that > in order for these systems to exist, humans need to actively participate in > and reproduce them.

This is kind of a strange take. I find it difficult to imagine anyone reading The Dispossessed and not coming to the conclusion that Le Guin's loyalties lie much stronger with one side than the other.

<comment><USER3> Yeah she clearly has a favorite, but she points out flaws in both systems. I think that being critical of ones preferred system is noteworthy.

Edit: Furthermore, are the protagonists of The Dispossessed totally free in their society? No. Despite Le Guin's apparently utopian aims in rendering functional anarchism, the protagonists chafe with society in many ways.

<comment><USER4> I actually think that this understates the degree to which LeGuin critiques the anarcho-communism of Anarres. We are presented with a society which is overtly anarchic and which finds its entire _raison d 'etre_ its its rejection of coercive power structures. But the entire thrust of the Anarres portions of the book is to demonstrate that the society is not, in fact, anarchic, that it is filthy with power and coercion, and that by pointing this out (and by being willing to work with the nations of Urras on scientific progress) the protagonists find themselves on the wrong side of that power structure.

On a recent re-read, I was particularly struck by the anecdote of a playwright who got sent to a de-facto prison for making a play critical of the local governing committee. "Gulags for political dissidents" is a pretty bad time in any case, but doing so in a society that _specifically_ prides itself in having no prisons or police is uniquely bad.

<comment><USER5> Yeah, there is a very strong critique of the way in which neighbors on Anarres can effectively be tyrants.

Le Guin is masterful at letting no one and no thing off the hook. No character or society is ever perfect. She clearly has preferences and hopes. Any character or society which intentionally and actively constrains the liberty of another is subject to withering.

I'm currently in the midst of a read through of everything I can find of hers. Started with the Earthsea books (which I hadn't read before) and now in the midst of the Hainish cycle books (on The Telling at the moment). Many of those I had read before, but the differences in me between now and when I read them before are very apparent. I'm responding to the books in a much more emotional way, now.

Left Hand of Darkness and Dispossessed are deservedly the classics. If you've limited time, read those. "Five Ways to Forgiveness" is a very moving collection of five (funny that) novellas in the same story line.

The Telling is proving to be very interesting to me. It is very explicitly about the notions of humans creating culture by learning and telling mentioned in the original post. That is helping to illuminate many of the reasons why I've remained invested in computing and the web, despite many wrong turns.

</comment></comment></comment></comment><comment><USER6> [Speaking as someone who takes a lot of random book recommendations from side discussions on this site…]

If, like me, you're aware of how prolific¹ she was but have yet to dip in, where would you start?

 _Edit_ : Thanks! Looks like The Left Hand Of Darkness wins so far.

1\. [https://en.m.wikipedia.org/wiki/Ursula_K._Le_Guin_bibliograp...](https://en.m.wikipedia.org/wiki/Ursula_K._Le_Guin_bibliography)

<comment><USER7> On a side note, I noticed some of the best book "choices" I've made came when I was able to read a couple snippets. Just enough to get my curiosity going.

It would be cool if Amazon released some of the most highlighted passages for some of these stories. I feel like it would do more for discoverability than just recommending book titles.

<comment><USER6> Yeah, I'd like to see some improvement too. Simply asking strangers who you think _may_ be like you feels weak.

My favourite weird recommendation was The 2020 Commission Report¹. I watched a guy miss his stop on the train home because his thoughts were so taken by it. Seemed like a good enough reason to pick it up ;)

1\. [https://en.m.wikipedia.org/wiki/The_2020_Commission_Report_o...](https://en.m.wikipedia.org/wiki/The_2020_Commission_Report_on_the_North_Korean_Nuclear_Attacks_Against_the_United_States)

<comment><USER7> Ohh. Thanks for the recommendation. Just reading about the Wikipedia article had me entranced.

</comment></comment></comment></comment><comment><USER8> If you want to learn more about Le Guin's influences, I just finished reading Charles King's Gods Of The Upper Air ( [https://www.goodreads.com/book/show/42951225-gods-of-the- upp...](https://www.goodreads.com/book/show/42951225-gods-of-the-upper-air) )

It's pop-history of the early 20th century anthropologists with a focus on the influence of Franz Boas and the many things he spawned, and how Boas and his pupils fought against genetic determinism. Many of the 'characters' in the books appear in OP's article. Recommended companion piece!

</comment><comment><USER9> Speaking of culture and context: it's crazy that these ideas are relatively new when they seem so obvious to me, having grown up with the idea that culture is anything but innate.

<comment><USER10> isn't participating in culture fun!

</comment></comment><comment><USER11> If you have access to iPlayer then the BBC has a program on Ursula Le Guin which is worth watching:

[https://www.bbc.co.uk/iplayer/episode/m000bh0x/the-worlds- of...](https://www.bbc.co.uk/iplayer/episode/m000bh0x/the-worlds-of-ursula-k- le-guin)

</comment><comment><USER12> "The Ones Who Walk Away From Omelas" is a great short story. It won a Hugo in 1974.

</comment><comment><USER13> Kroeber was ultimately wrong in the sense that culture is in fact intimately tied to evolution.

Natural selection happens at the biological level and at the macro level. Have you ever thought why ecological systems are so in equilibrium with the environment? Because any system that wasn't in equilibrium was ultimately destroyed by natural selection.

Macro level systems with reproductive qualities like culture or ecology are subject to evolution.

<comment><USER14> I don't know why are you downvoted, it's pretty much settled science. There are multiple papers on culture-gene co-evolution of individualism-collectivism and the serotonin transporter gene. And individualism/collectivism is big part of any culture. It's hard to imagine something like Confucianism developing in highly individualistic western Europe.

<comment><USER15> The phrase "there are multiple papers" with no attribution should be considered as something analogous to a code smell.

<comment><USER13> This is not true. If genes control physical features it does not make any sense to preclude genes from controlling mental features.

From evidence we see that culture is flexible among different races but by the above logic alone there must be some genetic factor that we aren't able to measure yet.

I wouldn't be surprised to find a paper that addresses this on some level.

In fact did you know that in the field of anthropology. There has never been a scientific evidence found for a human culture or civilization where women in general dominated and took the overall leadership role? When it did happen it was temporary and the baton was handed back to the males voluntarily. Many anthropologists including my female professor who taught me the concepts at UCLA believe that the prevalence of this fact across multitudes of cultures may point to a biological phenomenon rather than a cultural one.

Controversial, I know. I'm not advocating anything political here just science. Morally I feel both sexes should be judged on equal grounds but even believing this on a moral level, scientifically I cannot deny what has been observed, and much of academia feels the same way.</comment></comment></comment></comment>


Ask HN: is it unfair to refuse a job application simply based on bad writing? - <AUTHOR>

I just refused a job applicant simply because they had bad writing in their resume ("I have advance knowledge ..."), although their skillset actually looked relevant. I've done it before, will likely do it again. Is that unfair? <comment><USER2> Not at all... if part of the job they're applying for requires good communication skills. (And these days, even the most heads-down programmer needs that... bug reports, support docs, etc.)

That said, I think grammatical errors from an ESL speaker aren't the be-all end-all of good communication. It would really depend on what else I had to go on. Was there a cover letter? "Responsibilities" section of his/her resume?

Often extremely clear thinkers more than compensate for non-native language skills with incisive, compelling expression.

tl:dr Bad writing (communication) is just cause for putting a resume to the side. But one-off grammatical errors wouldn't be the only think I'd go on.

<comment><AUTHOR> It was bad writing more than the occasional grammatical error :)

<comment><USER2> Then by all means, put it in the No pile. Love it or hate it, email is the place employees spend most of their days. Good writing makes that time both shorter, and more worthwhile. (Not to mention blogging, announcements, support materials, bugs, documentation, and meeting requests.)

</comment></comment></comment><comment><USER3> There is no easy answer to this.

I've seen many resumes that contain 1 or 2 small grammatical errors or typos. I don't get too hung up on those.

However, if the resume is poorly constructed overall, I usually won't choose that candidate for further consideration.

Every part of our jobs todays involves communications with others. I personally HATE chat-speak in email. "R u going 2 lunch 2day" drives me fucking bonkers, and I don't care if you're typing it on a phone where you have to tap 2 wires together to spell out the message in morse code. So, for me, I really don't want to interact with someone where every other communication is likely to make me want to strangle them. Similarly, even if they have poor English, I don't want people to require a decoder-ring to dissect their every message.

So, depending on the exact details of the resume, I would have probably done the same thing. The exceptions tend to be when you require a particular skill set that seems to be most predominant in someone that is not a native English speaker. EG: if I were hiring an expert on Russian social networks, I would not expect to find an ideal candidate that didn't also make some grammatical errors at times.

</comment><comment><USER4> Probably. But that's not a reason not to do it.

Since you're trying to hire developers, you are undoubtedly aware that roughly 100% of the people who apply for your job are completely unqualified to program computers. Anything you can do to narrow that stack of 300 incompetents down to the 4 you can actually interview is worth doing.

So yes, ditch anybody who can't be bothered to proofread their resume. As other people have said, communication is an important skill for a developer. You have in your hands proof that they're not particularly good at it. Toss it and move on.

<comment><USER5> I think this is the key issue for me. My wife is a PhD but admits that she can't spell. However, she has others look over any important documents or emails before sending them out. Someone who won't do this for something as important as a job application communicates (to me) either arrogance or troubling lack of self-awareness of their weaknesses.

</comment></comment><comment><USER6> Somewhat. They might not be a native English speaker, and granted while some would argue that should be mentioned very early or at least _at all_ , I tend to say what employers ought to be looking for are the things that directly impact the candidates ability to prove they're worth the salary the position offers. This does involve communication, but it's not, nor should it serve as a be-all-end-all.

If nothing else, it's worth it to the employer and the employee to invest in a course audit at a local university to help improve those skills. You might be surprised to see if that helps improve retention and reduce the attrition of human capital. Especially if you include those types of programs to your organization to improve key skills.

<comment><AUTHOR> "it's worth it to the employer and the employee to invest in a course audit at a local university"

Really, you think that's worth it?

</comment></comment><comment><USER7> If someone claims they have "excellent verbal and written communication skills" and then has a litany of spelling and grammar errors in their application, it goes to the circular file.

It doesn't take much to have another person review the thing for correctness. If you don't know anyone who can, spend the money to have a professional check it over.

</comment><comment><USER8> It's not unfair and I've done the same thing. A resume is the first impression you give to a prospective employer; if you can't bother to make sure the details are right on it, how likely are you to bother with details on all the projects you'll be doing over time when the boss isn't necessarily looking over your shoulder?

That said, "I have advance knowledge..." isn't necessarily incorrect, if they are talking about their prophetic talents and not their level of expertise. :)

</comment><comment><USER9> If you were hiring them to write documentation, then yes. If you were hiring them to understand and build complex systems, where the occasional grammar error in a comment is not only forgiveable but extremely likely, then your nitpicking may have just cost you a good candidate.

My resume gets tailored as often as once per application, and the occasional mistake does end up on there. I fix them when I find them, but I expect their presence should not impact the essence of the resume for a manager with a clear understanding of the requirements they're hiring for.

<comment><USER10> > but I expect their presence should not impact the essence of the resume for > a manager with a clear understanding of the requirements they're hiring for.

I read that as: if you're not prepared to get the details right when you're applying for the job why should I expect you'll get the details right when you're on the job?

Why stack the odds against yourself? Given two equivalent candidates, one who appears (by virtue of their application) to get the details right and the other doesn't, I'm going to pick the former.

But then again, I'm not a manager. :)

<comment><USER11> >I read that as: if you're not prepared to get the details right when you're applying for the job why should I expect you'll get the details right when you're on the job?

You shouldn't. Nobody gets everything right the first time (why do you think we have bug systems) and it would be a waste of company resources to reread every email for every grammatical error, especially when they don't actually cause the recipient to misunderstand the intended point.

The same goes for who/whom, its/it's, weather/whether, phrases such as "in a timely manor", etc.

Perfect grammar is like bug free programs: desirable in theory but too expensive and impractical in reality.

</comment></comment></comment><comment><USER12> Making technology do things for people is a highly-complex skill, the foremost part of which is communication, not programming. (Sucks to say that, though. In our hearts I think all programmers would like programming to be some kind of super-intellectual puzzle. But it's really more along the lines of understanding other people, then making yourself understood, then finally going through a bit of technical fun)

You did the right thing.

<comment><USER13> Depends upon the job. Still room for a technical nerd out there I hope.

</comment></comment><comment><USER14> Communication Skills should be evaluated as a part the total sum evaluation. When going through a stack of resumes, I look for clarity, not grammar, and if _I_ can spot your spelling mistakes, you're in trouble. :)

Communication gaps are like any other quality/time/scope/cost factor when managing people. If the lack of language skills aren't counterbalanced by brilliance in other areas, you'll end up with a net loss in investing in the employee.

Evaluating whether the poor language skills is a sign of being lazy, hasty, arrogant or simply from another native language group, you could miss a good deal of other high-value talents.

</comment><comment><USER15> To quote Parkinson:

      When all candidates alike have to write Greek or Latin
      verse, it is relatively easy to decide which verse is the
      best. Men thus selected on their classical performance were
      then sent forth to govern India. Those with lower marks
      were retained to govern England.

The current "system" for getting hired might be arbitary and unrelated to programming ability, but it does at least present a consistent and knowable environment in which candidates have to operate. So you have to question the judgement of someone who makes basic errors like this.

</comment><comment><USER16> Are good writing skills a requirement of this position?

I'm sure pretty much everyone here has worked with people, who don't know how to write English worth a damn. For example in my last job I worked with this Scandinavian dude, whose written English was atrocious. It was so bad we made jokes about it (with him, not at him). I had to repeatedly correct his writing.

But the dude was a brilliant technologist. Innovative, incredible work ethic and he just got s __* done at an unbeliavable pace. The projects we were working on were much better off with him than without him.

<comment><AUTHOR> Good communication is a requirement, yes.

<comment><USER16> That's different from good writing skills.

<comment><AUTHOR> Not different as in exclusive. Writing ∈ communication in this case. It's strongly indicative. (ps: we're not talking about 1 typo here, I should probably have clarified that.)

</comment></comment></comment></comment><comment><USER13> Unfair to you, yes.

If there is a huge stack of resumes and the chances of finding the right fit is good, then no harm to you.

But if (like everyone else) you are looking through a huge pile of chaff for the one right person who may not even be in the pile, then you are doing it wrong.

Nitpicking grammer, or paper color choice, or resume-writing skills in general, is probably not the critical skill your job requires (unless you are starting WriteYourResumeHere.co of course).

</comment><comment><USER17> Good communication trumps good programming skills. As for non-native speakers, they tend to get a native speaker have a look over their CV or provide a CV in their native language.

If they have no native-lang CV which you could understand, you will almost certainly have troubles communicating with them, which means no hire. If they didn't go through the trouble of getting a native English speaker to edit their CV, then how badly do they really want the job anyways?

</comment><comment><USER18> In my experience most of the programmers I know and consider to be very talented also have good writing skills, at least in their native language. When I meet a programmer who writes poorly I immediately suspect they're not going to program well either.

However, I'm willing to concede that I might be engaging in a bit of stereotyping. I'm not sure your actions can be legally or even logically justified, but I can say that I would probably do the same thing.

</comment><comment><USER19> Sometimes it's worth doing a phone interview, as applicants with English as a second language may just have significantly worse written skills than spoken. As long as they can communicate verbally, then it might not be that relevant. I am assuming that you're all working at the same geographic location, thus making talking way more important than email.

</comment><comment><USER20> One word for you: foreigners (or people that English is not their main language).

Very capable, very smart and awesome to work with (most of the time), but can make some silly mistakes when writting in english... Specially on things that a spell checker wouldn't catch.

Not unfair, but you could miss a lot of good people by doing that.

<comment><AUTHOR> Missing good people isn't the issue when hiring, hiring bad people is.

<comment><USER20> Not when it is so hard to find qualified people...

<comment><AUTHOR> No, even then.

</comment></comment></comment></comment><comment><USER21> Was the job about writing letters or coding? If the later is the case then yes, you were unfair and may have rejected a good coder.

</comment><comment><USER22> No. Would you hire someone who made basic arithmetic mistakes?

</comment><comment><USER23> Don't know if it's fair or not, but it's not smart.

</comment><comment><USER24> > Is that unfair?

Short answer: No. Long answer: Yes. Correct Answer: It's a poor question. Given the limited data you provided, anyone here passing judgement is basing it off insufficient information. Furthermore, the information provided (a typo) doesn't make the described situation ("bad writing"). Furthermore, you provide no information regarding the candidate.

Anyone giving you an answer is doing so without all the information. Expecting an answer after providing such limited information is unreasonable.

<comment><USER8> It's not insufficient information. I've disregarded resumes before because of a single typo. Usually in situations where I have more than enough candidates to choose from, but still. A one page document that is your primary and in some cases sole reference upon which to have an employer judge you, should be proofread multiple times and should have no errors. There's really no excuse. If you don't have sufficient skill to ensure there are no errors by proofreading it yourself, then have someone who can ensure that proofread it. Come on, it is the single major document you give to someone to evaluate your potential as an employee, and in most cases it is (or should be) a single page, so it's not like you're editing a book here. "Attention to detail" is not only important, it's crucial when evaluating an employee. Even one typo on a resume can demonstrate a lack of that vital skill. I wouldn't blame someone for overlooking the error or not, it's a judgment call, but as to whether it's "unfair" to toss someone's resume because of it, the answer is unquestionably NO, it is not unfair.

<comment><USER24> > I've disregarded resumes before because of a single typo. Usually in ... > blah blah blah...

What does this have to do with my comment? I was remarking on the limited information provided, not whether it's unfair or not to dismiss a resume based on grammar. I'll just assume you inferred more from my comment than was stated.

> It's not insufficient information.

This is the _only_ part of your comment discussion mine. So, let's see what information is missing.

So, someone whose primary language is, let's say, Italian, French second, and English third is required to have impeccable English skills? In Quebec, whose primary working language is French? These aren't exceptions. These are the rule outside the US. Knowing 2 languages is common. Knowing 3 is not at all unusual.

It's insufficient information precisely because it doesn't provide us any context.

Employer is where? Employee is from where? Employer is hiring for what position? From where? Employer has few/many candidates to choose from? Employer seeking highly specific skill set? English mistakes were real mistakes, and not merely a single typo?

Now, you can make a lot of assumptions and say that the employer was hiring someone from the USA, a native English speaker, for a job in the USA. You can also make the assumption that the employer isn't looking for a specific skill set, and that the mistakes were more than just typos (despite that being the only example offered). I can make a lot of assumptions. But that's all it is, an assumption.

> the answer is unquestionably NO, it is not unfair.

Such a hard and fast rule. Unquestionably? I think it would be grossly unfair to hire in a region where people aren't native English speakers for a programming position and demand better English than the employer.</comment></comment></comment>


Google Places annoys me - <AUTHOR>

You can add a business freely, much like a wiki, but then Google owns the data and is very restrictive about how you can reuse it.
http://code.google.com/apis/maps/documentation/places/
I would like users to at least be given the choice of submitting their data under and open license which would allow reuse.
Anyone else? how could we get Google to listen? <comment><USER2> Whilst I can't offer you advice with regards to Google,I am working on something related to this. My email's in my profile if you want to discuss further.</comment>


Ask HN: Is this a better deep cloning for JavaScript objects? - <AUTHOR> https://github.com/yazjisuhail/js/blob/master/implementations/deepClone.js#

<comment><USER2> I would recommend taking a look at lodash's source to get an idea of how an efficient algorithm might look. On quick glance, defining the clone function inside deepClone is inefficient. The clone function also does not account for functions, which also are passed by reference.</comment>


Cash is a fact, profit is an opinion (2011) - <AUTHOR> https://mondaynote.com/cash-is-a-fact-profit-is-an-opinion-b90b8fb2d089 <comment><USER2> As an accountant once told me: "Revenue is vanity, profit is sanity, cash is king"</comment>