Why use a database instead of just saving your data to disk? - <AUTHOR> http://programmers.stackexchange.com/questions/190482/why-use-a-database-instead-of-just-saving-your-data-to-disk <comment><USER3> Well, here's some good reasons, your OS doesn't want you to store tons of small pieces of data in many different files. If you're storing a 100 byte record in a file you're doing it wrong because:

1\. Your FS has a minimum blocksize, often somewhere around 4k, you'll waste disk space with small files

2\. Your OS MMAPs/FS caches pages with its page size, ~4-8k, you'll waste ram with small files. (MongoDB also makes this mistake)

3\. Reading/writing data from files directly requires syscalls, a DB can cache a lot in memory and minimize syscalls.

4\. Atomic transactions are hard, even with a database. Are you actually sure you know how fsync works? (see the famous ext4 fsync issue: [http://blogs.gnome.org/alexl/2009/03/16/ext4-vs-fsync-my- tak...](http://blogs.gnome.org/alexl/2009/03/16/ext4-vs-fsync-my-take/))

5\. Distributed operation is hard, take a look at a databases like couchbase, elasticsearch or S3, where data is replicated across machines and datacenters in a highly reliable way

6\. Consistent backups on a live app are hard. Using postgres or another MVCC DB? Just perform a dump, it will be a true snapshot.

7\. Do you need to coordinate writes across multiple app instances (E.G. every web-app ever), you'll have to figure out your own record locking system. Need a high-performance counter atomically incrementable from multiple clients? Easy in SQL (UPDATE foo SET counter=counter+1 WHERE id=1), try doing that in a simple way with plain-text files.

The list just goes on and on and on. The kicker is even if you understand these issues, it's hard enough building a non-buggy implementation of these basics. Oh, and lastly, even if you do build your own mediocre DB, future devs will have to learn your crazy system rather than leveraging all the existing SQL knowledge they currently have.

<comment><USER4> I noticed when a discussion like this comes up people separate themselves into two camps that mock each other's assumptions while both talking about the same thing. It would be nice to talk more concretely with benchmark numbers.

1\. What about a database saves you disk space? Whatever it is, the filesystem can do the same thing. Perhaps you had a preconceived notion of a specific filesystem and OS in mind when you wrote this.

2\. Your database MMAPs/caches pages with its custom page buffer too, and that wastes ram with small records.

3\. Reading/writing data from a database requires syscalls too. An OS can cache a lot in memory and minimize disk writes. Arguably the database is duplicating the caching logic of the OS and slows things down.

4\. Filesystems have atomic transactions too. You can use the flock call to lock files, and rename is atomic. It's a rather befitting hack for HackerNews which "atomically" renames a file to update it.

5, 6 and 7: You can get distribution, replication, fault-tolerance, availability, and snapshots for free out of a filesystem like GlusterFS too. (Also note SQL is crap; it's a bad serialization of a data structure.)

I wonder if the real reason we have better databases than better filesystems is people didn't want to program for the kernel, which is where filesystems had typically ran.

People not grasping you can store data on a filesystem is probably one of the most valuable things a new programming language would have going for it. It would be a staggering reduction in complexity if a language made data manipulation easy, perhaps at the dismay of programmers stripped of the amusing complexity of using this separate thing called a database.

<comment><USER5> Could you clarify on 2? I mean, there's of course a per-row overhead on a DB, but many rows get put into the same page - so I'm not sure how that's remotely as wasteful as a hypothetical filesystem that uses a minimum of a page-per- file. Of course, that's not a requirement for FS behaviour - just historically a lot of them have worked that way.

> Reading/writing data from a database requires syscalls too

Not for stuff that's in the DB's page cache.

> Arguably the database is duplicating the caching logic of the OS and slows > things down.

That's a pretty biased assessment. A 'real' database like Postgres will use calls that bypass the OS page cache, so there's no duplication there. It also understands its usage patterns better, so it can do generally better than a general-purpose cache.

> and rename is atomic

Assuming your file system doesn't atomically give you a truncated file post- system-crash :-).

> (Also note SQL is crap; it's a bad serialization of a data structure.)

Agreed that SQL is not the best language, but is this an argument against set- based query languages, or just SQL specifically?

Databases make some things that are really hard less hard. Managing concurrent read/writes over sets of files (say) is currently difficult. Sure, your FS could have deadlock detection, MVCC and so on built into it, but that would be turning the file system into even more of a database system than it already is. Database systems are complicated because people often want to do complicated things.

<comment><USER4> A way to execute set-based queries is a major point you bring up here. It's also the most baffling. When tens of filesystems with sophisticated features completely omit what is one of the most common features used by database users, presumably it's not because filesystem designers are not capable of implementing it but of some more mundane reason.

> Not for stuff that's in the DB's page cache.

The database has to log what was written. It does use syscalls to write the write-ahead log. Agreed it can save read syscalls. Then again one process sending a query to another process to read something generates even more syscalls than having everything (app+db) all in the same process.

You are right about 2. I'm playing devils advocate here jumping around assumptions. I could ask why you assume an OS will use a page per file, you can say Linux does this, I can say why is your OS so heavy and point to Exokernel, you can say that's side-stepping the issue. I could say user-space filesystem having its own page cache; in the end we are talking about the same thing. In the end: the less layers the better.

When I look at the kernel I see something like the Berlin wall. A barrier that was there since you were born and which you never asked for. A kernel being hard to hack and monolithic is bound to push developers away, but it won't stop developers from building what they want in the end.

</comment></comment></comment></comment><comment><USER6> The subtext of the largely upvoted answer is that databases > text files. I may be preaching to the choir BUT:

"1. You can query data in a database (ask it questions)." If you use your file system as a "database" you can ask it questions too with file paths

"2. You can look up data from a database relatively rapidly." Given that lines of text can match some problems quite well, a text file can be MUCH faster.

"3. You can relate data from two different tables together using JOINs." Denormalization makes this unnecessary.

"4. You can create meaningful reports from data in a database." I work as a data analyst and make meaningful reports from event logs all the time. To be fair, I do prefer them being in a DB usually. ;)

"5. Your data has a built-in structure to it." Just because it has a structure doesn't mean an RDBMS is the right place for it to be codified. Also let's be clear the poster of this answer is clearly referring to an RDBMS.

"6. Information of a given type is always stored only once." It's important to note, this only matters if your data is not immutable. There are many applications where this is the case, but also many where it is not.

"7. Databases are ACID." Meh. This matters but after the advent of NoSQL era I now realize this matters much less.

"8. Databases are fault-tolerant." There are tradeoffs made in this name as well. Sometimes you can do better by letting your app be fault tolerant of your data instead.

"9. Databases can handle very large data sets." Files on disk can't? No I think here a valid point would be a database can span multiple disks and make them appear cohesive. That's a very nice bonus. For 95% (worst case) of the world though, that's not a concern.

"10. Databases are concurrent; multiple users can use them at the same time without corrupting the data." Again there are tradeoffs made in the name of this in an RDBMS (like locking). Reading immutable data scales across multiple users just fine.

"11. Databases scale well." CDNs have shown that files can scale even better. Again immutability is a constraint but I think it's an interesting constraint to explore for many systems.

Just to be clear I'm not saying databases are usually the wrong choice. Not at all. Instead they're just all too often the wrong first choice. Start with files, iterate from there.

<comment><USER7> You provide a nice counter-argument in general, but let me nitpick a single concern.

After the advent of NoSQL, ACID matters not much less, but in fact a lot more. Startups lose data all around the world because their shiny new database doesn't support the basic principles of databases.

<comment><USER8> Please stop peddling this rubbish.

Startups have been losing data all around the world with SQL databases as well e.g. Dribbble.

The implementation of ACID is just as important as the concept itself.

<comment><USER7> Okay, so ACID all the way, then! No concept or implementation can ever save your data from corruption or disk failure, which is why you need all the guarantees you can get in all layers.

</comment></comment></comment></comment><comment><USER9> Well here's one good reason: If your data cannot all fit in memory at once, you cannot simply serialize and deserialize it from disk. You will have to create some kind of indexed solution involving reading and writing to files piecemeal and by doing so you'll have created an impromptu database by default.

Other problems including loosing data if your application crashes and isn't able save it's data, performance on very large datasets, lack of concurrent access, etc

Generally, flat files are fine for low availability applications with small datasets. As your application grows however, you generally need to find more robust methods of persisting your application. Picking a persistence engine/database which matches you application will be essential at some point. It need not be a RDBMs, as 'NoSQL' databases and object databases may fit your application better.

One more thought: A lot of the fuss about 'NoSQL' vs RDBMs come from people trying to treat RDBMs strictly as persistence engines. That is, they start with an application that run well in memory and then realize that they need to deal with one or more of the issues I raised above. They pull out a RDBM and are annoyed that they now have map the data from the perfectly fine datastructures they were already using to a normalized tabular structure.

The reason this happens is because RDBMs were created to solve a different class of problems than simple persistence. They are for when you are starting out with data that needs to be housed and organized, as opposed to an application that simply needs to save its data.

<comment><USER10> No, you'll have created a paging system, and it'll probably fight with your OS's pager.

The disk paging system is but one of the components of a database, but what makes a database a database is the leverage that you get over your data, versus just a blob on disk.

<comment><USER11> Actually what i find to be the core question in deciding to use a database or not, is whether all data can be loaded at program start into memory or not. Loading all data at start is pretty simple and efficient. In this regards, there is another problem, getting the changes from memory back to the disk. Writing all data to disk, and even overwriting existing data is out of question, so such a system is needed which saves the changed data incrementally. Is there such a "database", which: a. loads up all the data at the start + loads the incremental changes, b. writes the incremental changes in transactional manner to disk, while not messing up the OS paging? I wonder if there is such a "persistent paging file" library available?

<comment><USER12> >Is there such a "database", which:...?

As far as I know, no, all of them are lazy and load only what you query into the memory. But if your data fits in memory, it'll stay there, and subsequent queries will be faster.

Also, you can take the quotation marks from database, you have some quite generic requisites, most of them implement all requisits, except for the caching at startup one.

</comment></comment></comment></comment><comment><USER13> There was a great short talk by (I think) Richard Hipp - or possibly Ted T'so? about mistakes people make trying to 'just save your data to disk'. I can't find the one I remember but this does cover a lot of the same material (in a less snappy way): <https://www.youtube.com/watch?v=TxXROT_nHqo>

The meat, on the implmentation of ACID in sqlite3, is around 14:20 in. More complexity than you want to think about is the answer. You could do the same without a db-as-such of course.

Anyone remember the talk I mean? It would have been around the same time - 2009ish.

<comment><USER13> I found the talk (in the comments on Shaver's 2008 blog article that cropped up in another comment - I was close on the time at least)

It's by Stewart Smith, it's called "Eat My Data: How Everybody gets File I/O wrong", and it's well worth watching: [http://mirror.linux.org.au/pub/linux.conf.au/2007/video/talk...](http://mirror.linux.org.au/pub/linux.conf.au/2007/video/talks/278.ogg)

</comment></comment><comment><USER14> Worth noting that Hacker News is a "store it all in files" design.

<comment><USER15> Do you know if that's why user comment averages (as on our profile pages) aren't updated in real time?

Seems like that's the kind of thing which is very easy with a database and much less so with flat files.

<comment><USER16> It might be very easy to _code_ with a database, but the DB still has to do a lot of behind-the-scenes work, so you might not want them updated in real time anyway. (n.b. this is all theoretical, I have no idea about the workings of HN)

You could argue that this is another plus for flat files; you have a better appreciation for what operations are hard work, whereas a 'simple' one line select/join can hide a huge performance blocker...

</comment></comment></comment><comment><USER17> I think this is a really good question, and I'm surprised by the answers, many of them are not particularly accurate. I won't tear into the wrongness of the answers and instead I'll highlight the rightness of the question - why use an incredibly complex data management system when you can store your data simply. IMHO The answer usually is "because thats the way everyone else does it" and thats not really a wrong answer but its not really all that interesting either.

If you are storing a dataset thats write once, read many, then not using a database is great and you're likely to save a lot of work efficiency. However, if you end up doing complex things with your data, its probably not that great to re-invent the wheel. You should also look at the cost of training other people to work around your storage system, if its not actually simple, you waste a lot of time getting people up to speed.

<comment><USER18> _why use an incredibly complex data management system when you can store your data simply._

Databases haven't been incredibly complex for years. Anyone can be up and running with MariaDB or psql or even mongodb in literally minutes. Actually using them is absolutely no more difficult than file system operations.

<comment><USER17> Sorry, thats not my model of complex :) If I have to store one line of text IE: "This is a line of text" in a database, the amount of overhead required to do that is huge. To store that simply with a flat file, I just put it into the file, thats a low complexity system.

<comment><USER18> Your original post referred to it as "incredibly complex". It isn't at all complex. Is it more complex -- at least to start -- that an fopen/fwrite/fclose? Sure, but it's still easier than virtually any other part of any solution worth doing.

Worse still, avoiding such non-complexity early on almost certain dooms you to serious complexity later on, because soon enough silly things like concurrency pop up -- the sorts of issues that databases solved decades ago.

</comment></comment></comment></comment><comment><USER19> Clearly stackexchange is showing pro-db bias. I'm a huge fan of unstructured data in filesystems as well, that's how the service behind my prototypesapp.com is built.

I also happen to think MySQL-backed websites are the bane of the internet, further testament to the pro-db bias of the average web developer.

A properly built sql store (or, increasingly, nosql) is definitely a necessity for large service. But what is "large"?

I once heard the rule of thumb that a db is necessary when the size of the data you store in it becomes larger than the size of the db code. I kind of like it.

<comment><USER20> It really depends on your structure I think. In the days of PHP3 I saw a lot of developers that built .txt-backed websites, with complicated parsing that would break when you looked at it.

In my opinion, they would have been better of with a database, or a more clever design like yours probably is.

A lot of my first work was rewriting PHP3 sites that used text-files to PHP4 with MySQL. Some of them had 200mb articles in text-files, and for every request they parsed this file, and didn't know why it was slow.

</comment></comment><comment><USER21> I recently did experiments with storing documents (blobs) with UUIDs as files. I stored documents within a hierarchy of a few levels of directories to avoid having too many files in a single directory (UUID abcdefg was stored as a/b/c/d/abcdefg). Performance was surprisingly low. Reading documents resulted in a lot of disk seeks. Also it seems that directory entries lookup is a O(n) operation in a standard ext4. I also did experiments with simple databases like GDBM. The effect was also disappointing. In the end I started to really appreciate RDBMSes design and all theory that is behind them. Creating a highly performant system using I/O operations is HARD.

<comment><USER22> What was your usage pattern? This doesn't sound that different than static web file serving, which can be extremely fast. The file system relies heavily on the buffer cache to be fast, and I know there some options to tune that, although I'm not an expert.

Do you mean that dir entry lookup is say O(10,000) when you have 10,000 files in a single dir? If so then I imagine that is the reason that git has a hierarchy, i.e. look in .git/objects/[0-f][0-f]/.

</comment></comment><comment><USER23> The question is like asking "why do I need an operating system"? Or why live in a society with government services and laws instead of living alone off the land?

Databases are most valuable when there's more than one user at the same time, doing UN-anticipated things, involving multiple resources, whose uses may conflict with each other.

Databases provide certain services that allow things to run smoothly as concurrency, amount of data, types of data, and unanticipated usage begins to scale up. In exchange, databases impose a tax that includes extra complexity, increased latency, reduced throughput, potential license fees and general bother.

For coders who are just beginning a project, who are short of time and don't feel comfortable with a database, I see no good reason to insist on immediate database use.

If their project scales to many users, a lot of data, and lots of unanticipated queries WITHOUT using any kind of database, the coders would have made a HUGELY interesting discovery - at least as interesting as map- reduce.

</comment><comment><USER24> What databases seem to be REALLY bad at though is storing large blocks of CDATA/"unsorted data" with meta data attached.

A small business has grown up using nothing but files. These files store large blocks of text which cannot be altered, just meta data pulled out (they're flat files, between 10 KB and 5 MB each, which is basically like dumping a large char[] arrays into files, and unfortunately they need to be kept in this format because the formats vary/incompatibilities/flexibility).

Anyway... Basically they have 30+ GB of these flat files. Literally millions of them. All in *.dat files. It works quite well like that. But the downsides as discussed in the link crop up and cause problems.

So we tried to put them into a few SQL databases as LONGBLOB, and after the first couple of gig the thing just became unmanageably slow, badly formed queries would cause it to lock up, and the thing took up way more space on the file-system than files did (and was WAY harder to manage with the performance issues discussed).

So I guess my point is, SQL databases are great for sorted data. They're freaking nightmares for CDATA/BLOBs. Just a complete waste of space. Almost no database is designed to handle that amount of data and continue to work.

<comment><USER25> Not that the filesystem isn't a valid option, but there are more databases than SQL databases. That cases seems great for a key-value store (which is essentially what a filesystem is).

<comment><USER24> True there are, and I'd be lying if I said I had tried everything.

But in general even key-value stores are designed to store sorted/structured data. Not really massive BLOBs with a little meta data sprinkled in to explain it.

You just run into serious performance issues when you try and store/access >2 GB of "junk" data via some clever database management engine, which is really more accustomed to storing tiny little columns of explain-able data you can write clever queries to.

We've wound up in a situation now where we just use databases to store the meta-data and have left the actual data in files, which from a programming point of view makes things harder (since you're hooking into two methods of data access as opposed to one).

<comment><USER26> I've used CouchDB's attachment feature for that purpose:

[http://onabai.wordpress.com/2012/05/08/working-with- attachme...](http://onabai.wordpress.com/2012/05/08/working-with-attachments/)

</comment></comment></comment></comment><comment><USER27> I don't like databases, and the reason I don't like them is that they seem to cause terrible performance problems in web browsers. Firefox's use of SQLite is well known to cause or have caused trouble - for example [http://shaver.off.net/diary/2008/05/25/fsyncers-and- curvebal...](http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/) . And then you get advice like this: <http://savanne.be/153-performance-tip- of-the-day/> .

Safari has similar issues. In particular the favicon SQLite database is a common source of slowness - see [http://www.chriswrites.com/2012/05/how-to- delete-favicon-cac...](http://www.chriswrites.com/2012/05/how-to-delete- favicon-caches-from-safari/)

I don't know if these are inappropriate uses of databases, or if these databases could perform well, but are misconfigured in some way. But I have seen SQLite cause performance problems on desktop apps so often that I think there must be something hard about it, that's not hard about other data storage mechanisms.

<comment><USER5> I know you've acknowledged the limitations of your knowledge in your comment, but it's tremendously limiting to take an attitude of 'I don't like databases' in the presence of such limited knowledge and on the basis of a single implementation.

<comment><USER27> Maybe I was too glib. I should have said, I think that databases are overused.

There's a bias in favor of databases in the comments here and in the StackOverflow page, which isn't properly tempered by negative experiences. I also see a lot of misinformation, for example, "A database is needed if you have multiple processes modifying the data."

I have seen some desktop apps with terrible performance, that issue disproportionately huge amounts of disk IO, and where backtraces show SQLite functions. I conclude that using SQLite correctly in a desktop app is harder that people say. (Other RDBMSs aren't really in the running on the desktop.)

I have also seen a lot of dog-slow WordPress sites, including my own. Wouldn't you agree that many of them would be faster and more robust if they used a flat-file generator like Jekyll? Mine sure was!

So if databases are overused, what is the explanation? Well, look at the top voted reply: use a database and now your project is fast, ACID, fault- tolerant, can handle very large data sets, is concurrent, and can scale well! And when should you use files? The second reply answers that: it's when you "don't care about scalability or reliability."

If you believe these things, it will lead you to use databases in inappropriate contexts, and make the mistake of thinking that now your I/O performance is good. If anything, it's the opposite: databases abstract I/O, so properly evaluating performance means you need to work harder to understand what's really going on.

<comment><USER5> I think my own answer would be that a database system is very often the right solution if you know what you're doing with them. In this situation, diagnosing performance problems is quite easy (thanks to diagnostics), concurrency is certainly easier, and scaling can be easier too - <USER2> problems like concurrent file access for writing are hard in a flat-file situation and easy on the database, and that's exactly the kind of problem you often run into when you scale.

Unfortunately, when you don't know what you're doing with them, they're basically a black box where magic happens, and you don't know how to fix any problems that occur. The thing is, that applies to many things. When you don't know what you're doing with concurrent file access, you'll run into even bigger problems than you will on an RDBMS - just last week I was in fact rewriting an otherwise-competent colleague's code, because concurrent read/write to files caused massive unrecoverable corruption issues.

I don't think your wordpress comparison is apples to apples - wordpress is known to be dog-slow, and if you tried similar access patterns over file systems it would be at least as bad. There's little incentive for them to fix it, though, because wordpress sites are read-mostly, and all you have to do to fix all your problems is stick one of the wordpress caches in front of it. Frankly it boggles my mind that they don't ship with a cache on by default.

There's absolutely a place for no-db - if your content is static or write- once, doesn't need indexing over, and you can guarantee that those requirements won't change. In this case, there's no need at all to use a db, and it will simplify your life not to. I'm writing such a site as we speak, in fact! If you have dynamic content, well, I'd use a DBMS personally.

tl;dr: understanding how to use RDBMSs will make the average software engineer's life much easier.

edit: Just a note on SQLite specifically: SQLite can be slow compared to the common file system trick of write new temporary file -> rename, because the file system trick (on ext3 at least) doesn't require an fsync. It does mean that the change is not guaranteed durable, but often for browser data that's OK! An equivalent in database-land would be not writing every single transaction to the transaction log when it commits. That means that on a crash you lose everything that hasn't hit the disk yet, but you maintain consistency. Pre 3.7 SQLite this wasn't supported because SQLite didn't use write-ahead logging, which meant you had to fsync to maintain consistency. I believe in WAL mode this behaviour is easily available now though!

</comment></comment></comment></comment><comment><USER28> Depends entirely on what you're doing. If you're just saving large sets of data to the disk, and doing nothing else with them, then yeah, don't use a DB. If you're running lots of random queries on piece-mail parts of several dozen sets of those files, then use a DB.

There's a reason it's called SQL: Structured Query Language. If you're interrogating the data, you want SQL (or something like it). If you're just loading stuff / saving stuff to disk, like a Word file, and not performing any sort of random search or query on it, then yeah, using a DB doesn't make sense.

<comment><USER29> This was my first reaction, as well. This goes especially for large datasets. If you are making linear passes over very large databases, I don't think I see much advantage in using a DB beyond possible benefits of shared storage.

</comment></comment><comment><USER30> It really depends on the problem. Using a DH well also requires some expertise.

I'm writing a small web app where users have a spaiic list of items. I started with a db but it's so much more complex than a simple file per user. Beside you have single big indexes for all the user data while there is a clear split of information between user. I didn't know how to handle hat efficiently. It turned back to one file per user with the content loaded and cached in memory.

</comment><comment><USER31> Database is a sophisticated form of compression. Text compression is not so good after all. Database allows you to only keep indexes, and directly access those. Text compression is naive and inefficient, database software guide programmers to optimize their data types themselves. It's either that or storing everything in binary files.

We use database because they allow us to organize a binary file. It's a standard, but it's only relevant if you need to use those kind of data patterns.

You also have to understand regex doesn't scale at all.

</comment><comment><USER32> I'm thinking about moving some of my data out of my postgres database, and into S3 objects. I think for "documents" that will only accessed by a single user (so record locking etc. doesn't matter), it will help things scale more easily. The web app will be hosted on AWS, so I wouldn't think the S3 retrieval time should be too bad. Anyone have some good guidelines on this?

</comment><comment><USER33> Ah nostalgia... I recall wondering about this myself back in the early days of my career.

However, that was before the current wave of document-based DBs (Redis, Couch, Mongo etc.) so the meaning of a "database" was more targeted at RDBMSs. These days a lot of the reasons listed in the answers are equally applicable to, say, JSON files stored in Redis.

</comment><comment><USER34> The same reason you divide your programs into functions, classes, etc. A well- designed database can change as the data you store needs to change. You also get a nice abstraction for accessing/querying data (e.g. relational algebra/SQL) that is well-studied and widely applicable.

</comment><comment><USER35> That's all good but if your DB can't handle your insert rates you only have files as an option. And most DBs have very poor insert rates.

</comment><comment><USER36> _Why should one use a database instead of just saving the data to disk?_

Expressed in English, this says "YAGNI" of all the advanced RDBMS features.

Answer: Yes I freakin' AM gonna need it _eventually_

<comment><USER37> "Eventually" will very likely be "immediately" for any system that's remotely serious in any way, and being created by developers who consider themselves professionals in even the slightest sense.</comment></comment>


Go vs. Crystal Performance - open-source-ux https://ptimofeev.com/go-vs-crystal-perfomance/ <comment><AUTHOR> I am not an expert at this but I want to inquire:

\- Everytime there is any kind of benchmark between 2 or more languages, there is always a caveat - "Not a fair comparison" or the algorithm isn't right.

What, then, is a good way to compare languages? After all, they are not apples-oranges comparison. They are a tool to get things done. It is like I am comparing 2 different brands of hammers. Sure the grip is different, the shape of the head is different, but if we are testing a particular aspect of nailing - say nails/sec, then it is worth investigating which one is better. One hammer takes a lot of expertise to use it and yet another one is easy to use. So, then, write those pros and cons down, it doesn't make the comparison a worthless activity which is the cliche response to benchmarks - developer time matters and not the language.

What is a good way to compare 2 languages. Say Python vs. C? Are there standard implementations of algorithms (e.g. Mandelbrot) or something like that we can use and definitively compare the speed? Shouldn't we have standards around these benchmarks? Some kind of a ISO implementation of an algorithm reviewed by experts that can be used for benchmarking?

For majority of programmers, the speed doesn't quite matter. But that discussion is off the table and orthogonal. Sure for most things, I personally pick up Python and it is the fastest way to develop for me. But there are many reasons why we should compare languages and these concerns are shouldn't stop us from evaluating objectively.

<comment><USER2> > _What, then, is a good way to compare languages?_

Digging into details and yielding very specific conclusions.

Let's take the example benchmarks.

The first one, Fibonacci, can only be properly assessed by inspecting the assembly. It is an analysis of _compiler output_ , not of the language, not even of compiler optimizations.

It therefore only measures the CPU speed of function calls, and one compiler outputs a different set of assembly instructions:

• Go (go tool objdump fib) is all like "CMPQ JBE(label(morestack)) … LEAL(-1,cx) MOVL(cx) CALL(fib) …×3 ADDL(-2,cx) MOVL(cx) CALL(fib) MOVL ADDL …×3 RET label(morestack) CALL(morestack) JMP".

• Crystal (crystal build --emit=asm fib.cr) is all like "subl(1) …×6 callq(fib) …×1 subl(2) …×7 callq(fib) movl addl …×6 addq retq" for the recursive condition.

So the conclusion is that Go outputs less instructions, but has to maintain its segmented stacks (useful for goroutines, its lightweight threading system) on every call, while Crystal uses the standard assembly calling system with little overhead beyond light dynamic typechecks.

So there is a language-motivated difference: calls in Go are a tiny bit more expensive, but built-in lightweight threads consume little memory because their stack can increase dynamically according to use[0].

The second benchmark, HTTP servers, has everything to do with the implementation of the default library, and nothing to do with either the language or the compiler. And I presume Crystal is backed by an optimized C library for TCP[1] while Go is probably a full reimplementation of TCP and HTTP.

[0]: [https://blog.cloudflare.com/how-stacks-are-handled-in- go/](https://blog.cloudflare.com/how-stacks-are-handled-in-go/)

[1]: [https://github.com/crystal- lang/crystal/blob/master/src/sock...](https://github.com/crystal- lang/crystal/blob/master/src/socket/tcp_socket.cr)

<comment><USER3> > Go outputs less instructions, but has to maintain its segmented stacks

I think they dropped segmented stacks in 2014: [https://en.wikipedia.org/wiki/Go_(programming_language)#Vers...](https://en.wikipedia.org/wiki/Go_\(programming_language\)#Version_history)

The stack can still grow, but contiguously. I'm not sure if there are any instructions required to monitor the stack size and grow if it needed.

<comment><USER4> > CMPQ JBE(label(morestack)) …

^^ It's still the preamble for most functions :)

</comment></comment></comment></comment><comment><USER5> Completely anecdotal:

\- In my small benchmarks, Crystal is very fast \- In benchmarks not my own, Crystal is very fast \- Crystal has a very nice batteries included stdlib.

Benchmarks that aren't mine: [http://lh3.github.io/2020/05/17/fast-high-level- programming-...](http://lh3.github.io/2020/05/17/fast-high-level-programming- languages)

The only other language that is high level in its ballpark is D.

<comment><USER6> Benchmarking strings is often benchmarking memory allocation speed or the GC.

If you manipulate strings day in day out in your workflow, the first thing you do is remove all those allocations and for what is left you use a memory pool.

The speedup could easily go into the 20x in any language. It's actually one of the area where Python or JS can beat statically typed languages, they focused a lot into optimizing strings while statically typed languages often leave that as an exercise to the reader.

<comment><USER7> > It's actually one of the area where Python or JS can beat statically typed > languages, they focused a lot into optimizing strings while statically typed > languages often leave that as an exercise to the reader.

I think this has more to do with writing the string handling functions in heavily-optimized C rather than in Python/JS than it does with memory tricks, but I'll happily accept correction.

<comment><USER6> Yes low-level C + retaining memory around in the GC. The second part avoids many malloc/free that may be hidden in destructors in low-level languages.

</comment></comment></comment></comment><comment><USER8> Sounds like another win for languages with an LLVM backend. Definitely excited to see this language grow, especially as it has generics already.

Does anybody use Crystal professionally here? Any thoughts so far if so?

<comment><USER9> We run it in production. Our apps are mostly Ruby but we have been rewriting services in Crystal. Originally we were attracted by the speed and type checks, but one surprising benefit has also been the reduced memory consumption. It's difficult to compare directly, but in some cases it cosumes 10x less memory and performs around 20-35x better. Even I/O bound services are sped up since we can take advantage of Crystal's concurrent fibers (rumored to come in Ruby 3.0).

The main downside has been the somewhat frequent deprecations of methods and changes to the standard lib. But it's mostly due to the preparation to launch 1.0.

<comment><USER10> Is there any web framework for it, like rails? That's really the main reason I use ruby is because as a single developer it's amazingly fast to set up new apps (admin panels, reporting panels, sales funnels, etc). The out-of-the-box functionality of rails makes this super painless. I'd LOVE to use something faster but I don't really want to have to custom write a lot of things (CSRF, sessions, cookies, blah blah).

Also, how do you handle jobs with Crystal? Sidekiq being the common one for ruby.

<comment><USER11> Hello! I'm the creator of the Lucky web framework [https://luckyframework.org](https://luckyframework.org). I've been building it for about 3 years and we've got a number of people using it in production.

It still lacks some features found in bigger frameworks, but is nearing 1.0 and gaining many new contributors that are helping us fill in the gaps.

Feel free to hop on our chatroom to ask questions about it. We try to be super friendly and love answering questions and getting feedback [https://gitter.im/luckyframework/Lobby](https://gitter.im/luckyframework/Lobby)

<comment><USER10> Awesome, thanks!! What would you say the top 2-3 missing things are currently?

<comment><USER11> Right now I'd say we need to make it easier to work with nested params so you can easily save Parent + (n) children. Easier handling of uploaded files is another big one. It's being actively worked on right now. There are a few more escape hatches that are needed when you need to break out of the framework. But overall it is fairly full featured.

You can check out our roadmap to 1.0 here: [https://docs.google.com/document/d/1EYzx37Kq5h7iLH9SQTFyXNwb...](https://docs.google.com/document/d/1EYzx37Kq5h7iLH9SQTFyXNwby2xVvzuRUlMuxcoktx8/edit)

</comment></comment></comment></comment></comment></comment><comment><USER12> Benchmarks don't matter. It's 2020. We use Stock Price Driven Development now.

The main reason to use Swift is Apple created it.

The main reason to use Go is it's the first two letters of Google.

The main reason to use Python is Google hired GvR in the 2000s and created momentum.

The main reason to use Kotlin is Google announced at I/O 2017 its support in Android Studio.

Get with the times gramps.

<comment><USER13> Wow. No.

Engineering school was/is supposed to help us (you) move beyond cynical judgements to thinking.

<comment><USER14> I could care less if a statement was positive or negative what is important is if the statement has a realistic possibility of being true.

If anything Engineering school should have taught you how to logically observe situations rather than viewing things through an optimistic or cynical lens.

</comment></comment></comment><comment><USER15> This is a pretty basic benchmark, but there are more robust ones for Crystal and others here: [https://www.techempower.com/benchmarks/](https://www.techempower.com/benchmarks/)

Under Filters you can select the languages / frameworks that are of interest to you. For example Go seems to have several implementations that beat Crystal: [https://www.techempower.com/benchmarks/#section=data-r19&hw=...](https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=fortune&l=zdjvnj-1r)

Having programmed in both though, I far prefer the language / idea of Crystal for innovation. But it is hard to beat the performance and explicit nature of Go for production applications.

<comment><USER7> The non-recursive Go fibonacci implementation computes in ~160ms and uses only 1.5mb on my MacBookPro (and I can get the binary size down to 850K by stripping symbols and using the println builtin instead of fmt.Println). This microbenchmark seems to tell us more about function call overhead than it does about typical application performance.

Further, while I don't doubt that Crystal binary sizes are smaller in general, I don't think we can get much information about binary sizes from these micro- toy-sized programs. For example, the Go version shaved off a full mb by using the `println` builtin rather than `fmt.Println`, probably because the former pulls in more of the runtime than the latter. These toy benchmarks are very sensitive to these kinds of things, and the size of the runtime is going to be a trivial portion of the size of any real application anyway.

</comment></comment><comment><USER16> the HTTP benchmark is not fair since the crystal implementation is setting the content type explicitly while the Go implementation is auto detecting it.

<comment><USER17> Indeed the benchmark was dismissed on Reddit coupe of days ago: [https://www.reddit.com/r/programming/comments/h0knmi/go_vs_c...](https://www.reddit.com/r/programming/comments/h0knmi/go_vs_crystal_performance/)

<comment><USER18> The repost[0] in r/golang shows similar critiques. This perf comparison is naive on many levels.

\- binary size (static vs. dynamic linking)

\- recursion is not idiomatic in go, it is assumed that you write imperative for loops.

\- mathematical functions like the Fibonacci sequence are a rather atypical computation use-case for a Go program (I don't know about Crystal). Tree/graph traversal/mutations would be a more fitting test. Or generally something that is composed of dynamically growing and shrinking slices and maps.

\- http test apparently cannot be reproduced, some get better results for Go, some for Crystal.

\- http tests w/o involving some parsing/marshaling/serialization or something along those lines aren't that useful. You usually want to either read or send some JSON string or similar.

[0] [https://www.reddit.com/r/golang/comments/h0kogq/go_vs_crysta...](https://www.reddit.com/r/golang/comments/h0kogq/go_vs_crystal_performance/)

<comment><USER19> Recursion is really not the idiomatic way to solve most things in Crystal either, not that it make the test relevant.

</comment></comment></comment></comment><comment><USER20> Why doesn't Crystal use more than 100% CPU like Go does if the server has 8 cores? Why didn't both languages max out the cores? Is it because the params to WRK was within what one core could handle in Crystal?

<comment><USER21> It seems crystal is single threaded by default. Although you can configure it to use more threads.

[https://crystal-lang.org/2019/09/06/parallelism-in- crystal.h...](https://crystal-lang.org/2019/09/06/parallelism-in-crystal.html)

<comment><USER20> Yeah, but in a benchmark it seems strange that he doesn't restrict both to use just one CPU or unlimited.. kind of compares apples/oranges.

</comment></comment></comment><comment><USER22> I've taken Crystal out for a spin with a number of popular and less popular frameworks. Even for my small test application, edit/compile/run times were slow. Only the thinnest frameworks like Kemal seem tolerable to me.

I really do hope that the compiler gets faster and the larger frameworks figure out how to compile faster. These are the benchmarks that matter to me before I'd make a recommendation.

<comment><USER23> My understanding is that the compiler performance issues in Crystal are sort of inherent to the language design and making it much faster will be very hard. I believe it's related to Crystal's type inference -- it has to traverse every code branch to ensure type safety. I believe explicitly typing everything is supposed to help, but I'm not sure by how much (especially if you have dependencies that aren't doing that).

<comment><USER24> maybe LLVM as well..

</comment></comment></comment><comment><USER25> Here Is a Gist where I compare Crystal, Go, OCaml including compile time. [https://gist.github.com/s0kil/155b78580d1b68768a6c601a66f8e2...](https://gist.github.com/s0kil/155b78580d1b68768a6c601a66f8e29b)

<comment><USER26> Why did you combine compile time and execution time?

<comment><USER25> The idea is to have a balance of compilation + runtime performance.

</comment></comment></comment><comment><USER27> I wonder how the GC pause times and throughput compare. My understanding is that Go sacrifices some compute performance for better GC pause times.

<comment><USER18> > better GC pause times

What does that mean exactly / in this case?

My assumption is that "better" means more predictable. Or does it mean straight up fewer/shorter?

<comment><USER28> Go sacrifices basically every other GC metric to minimize average pause times. Sortof a 'if you can't succeed, redefine success' mentality if you will.

<comment><USER29> That's not necessarily a bad thing for writing web services. I used to spend a fair bit of time tuning JVM to achieve acceptable tail latencies for Java services, not to mention once in a while, they would need to be tuned again... Not so with Go.

<comment><USER30> Java now has two low latency collectors: ZGC and Shenandoah.

</comment></comment></comment></comment></comment><comment><USER31> It seems strange that Crystal would not utilize more than 100% of the CPU in the HTTP benchmark given that it ran on an 8-core machine and with fibers should be able to split the load across multiple cores. What explanation is there for that? Also, it's impressive that while using one third of the CPU Crystal outperformed the Go HTTP server on throughput.

<comment><USER19> Because currently Crystal is singlethreaded. You only get multithreading if you compile with -Dpreview_mt . I suppose it will be on by default at some later point.

</comment></comment><comment><USER32> Might binary size comparisons be misleading, unless the Crystal binary is statically linked, as presumably the Go binary is?

</comment><comment><USER33> Anybody knows the status of light-weight threads, channels and automatic multiplexing ("mapping") of light-weight threads on operating system threads in Crystal?

(This has been promised to come in Crystal (as opposed to pretty much any other language than Go), but has always seemed to be "yet to come").

<comment><USER9> It's available [https://crystal- lang.org/reference/guides/concurrency.html](https://crystal- lang.org/reference/guides/concurrency.html). Fibers (like goroutines) are scheduled by Crystal and map to system threads.

The work on parallelism is available as a compile-time flag, but not yet GA: [https://crystal-lang.org/2019/09/06/parallelism-in- crystal.h...](https://crystal-lang.org/2019/09/06/parallelism-in-crystal.html)

<comment><USER34> One wonders, once it is GA, if there is value in a Go transpiler. There is a lot of useful software in Go land that would be immediately useful for Crystal devs, and Go itself is not too complicated to map to another language with the same features (a few of the runtime features will have to be emulated).

<comment><USER35> How would this be achieved? Could you expand a little on this idea?

<comment><USER34> Literally convert Go code to Crystal code. I have not looked into Crystal enough to confirm it's features are a superset of Go's. For example, I saw that Kotlin w/ the advent of their coroutines, had most of Go's features so I wrote a transpiler[0] that got pretty far (can run all of this [0]). I abandoned the project because I have abandoned the JVM.

0 - [https://github.com/cretz/go2k](https://github.com/cretz/go2k) 1 - [https://github.com/cretz/go2k/tree/master/compiler/src/test/...](https://github.com/cretz/go2k/tree/master/compiler/src/test/go)

</comment></comment></comment></comment></comment><comment><USER36> I always find these benchmarks superficial. unless you're doing some serious number crunching, it doesn't make sense. people need to start bench marking languages on speed of development, developer ergonomics, error reporting, ease to deploy etc.

</comment><comment><USER37> Tangent: would technical writers please stop using the phrasing "is X times smaller" when "is one Xth the size" is more accurate? I had to read the reference to "Crystal's binary size is 5 times smaller than Go's" twice to realize it was 0.2x and not 5x.

<comment><USER38> I don't get it. "5x smaller" and "0.2x the size" are the same.

Can you explain then what do you expect to be the meaning of "two times smaller"?

<comment><USER37> Clarity of language for one thing, but also that "times" is indicative of multiplication so "five times" anything has to be bigger[1]. One fifth is far clearer as there's no way to interpret that other than being a _part_ of the size of the reference, ergo, smaller. Is it impossible to understand? No, but it's poor style for technical writing.

[1] I'm ignoring the case of decimal math since the reference in this case is always the whole integer 1.

<comment><USER38> I don't know under which rock you've been hiding but "x times faster/smaller" has been in common use for _decades_ , including technical writing. Everyone understands it as 1/X, there is absolutely no confusion.

</comment></comment></comment></comment><comment><USER39> Now compare Crystal with Nim.

<comment><USER40> I want to say this: [https://framework.embarklabs.io/news/2019/11/18/nim-vs- cryst...](https://framework.embarklabs.io/news/2019/11/18/nim-vs-crystal- part-1-performance-interoperability/index.html) was published on HN at one point. Regardless, it's a decent rundown.

<comment><USER39> Oh wow I expected Nim to be at least as fast as Crystal.

<comment><USER6> Nim JSON parser is not optimized, it was mostly written for maintenance (for example it allocates a Table per node in the json file)

I.e. the difference in speed here is a difference in elbow grease.

I have yet to come into an optimization problem where you cannot reach the speed you can achieve in C in Nim.

</comment></comment></comment></comment><comment><USER41> Without having done _any_ of my own research, I'm initially skeptical of Crystal's binary size. I initially saw something similar with Swift, but that's just because the runtime is external to the binary.

</comment><comment><USER42> Interesting. But more important is how productive can I be and how expansive is the ecosystem? What's the developer experience like? Is the community welcoming?

</comment><comment><USER43> I suggest the word femtobenchmark for this kind of work.

</comment><comment><USER44> Consider using wrk2 in order to avoid coordinated omission.

</comment><comment><USER45> Has anyone compared Crystal and Rust on similar lines?

<comment><USER46> Did a rust build with the following...

        fn fibonacci(n: u32) -> u32 {
          match n {
            0 => 1,
            1 => 1,
            _ => fibonacci(n - 1) + fibonacci(n - 2),
          }
        }

        fn main() {
          println!("{}", fibonacci(47));
        }

size: 2.67kb time: 7.391s

I think rust wins :-D

\--- edit: not sure if I used valgrind/massif right, but the largest values in the output file.

        mem_heap_B=1816
        mem_heap_extra_B=32

I think this means it stayed under 2k ram?

<comment><USER47> Wouldn't processing time depend on your CPU, and unless you run the benchmarks in the article, this comparison would be meaningless?

<comment><USER46> Don't have a go environment setup, but could do that. The executable size and memory use was also lower.

<comment><USER47> Well to be honest, Go binary sizes are always going to be big, to the benefit of ease of development and deployment.

Memory usage, I don't know. The Fibonacci benchmark code was a bit... shit.

Do you want to send over your Rust code in a Gist or something, and I can compile and compare?

<comment><USER46> It's in the comment above...

</comment></comment></comment></comment></comment></comment><comment><USER48> I'm still waiting for someone to write an LLVM backend for Go.

<comment><USER49> gollvm? vs gogcc. that's why i said "an IR interface" when someone asked about transpiling crystal to go and vice-versa.

</comment></comment><comment><USER50> It's always interesting when people compare Go to other languages they always use file size of binary, as if that's something that anyone in modern professional engineering considers.

Another good example would be to statically cross-compile a non-contrived program into ARM64, 32-bit linux, and Darwin without needing google!

And if you think you have your binary statically linked, go test it in the "scratch" docker image. You may be surprised at how difficult it really is.

<comment><USER51> Sure we do, I have spent the last week trying to upload 10 MB files in a quite slow uplink, and yes in Europe, suburban area of a German town.

First reason why people uninstall apps on mobile devices is app size.

<comment><USER47> Are mobile apps the target market for Go? CI/CD takes care of upload for the dev side at least.

It would be handy to have a compile time flag indicating the desired file size optimisation level still, with tradeoffs being ease of debugging, and performance.

<comment><USER51> Given that gomobile exists, maybe.

CI/CD is something almost unknown outside HN bubble.

Also that was just two examples, here are another two, cost of production for USB Armoury keys running Go bare metal, or download costs for WebAssembly modules written in Tiny Go.

<comment><USER47> Are you sure re: CI/CD? I was looking around the job market recently, and every role was interested in my experience in it, since they were using it too. To be honest, that could be self-selecting, as my resume likely attracts companies similar to ones I have worked at. I still do hear about microservices, CI/CD a whole lot in job descriptions etc, but whether they are already practicing it (well), is another question...

I was going to suggest TinyGo! I mainly work on a backend system, so I guess we have different priorities and needs. The embedded work I have done has all been C/ ASM, though it could be fun to revisit with Go.

<comment><USER52> In terms of sheer numbers, I would guess that at least a plurality of websites are running old versions of PHP and are released via FTP. But I don't think that's really meaningful or interesting to worry about, since those services aren't even considering the tooling decisions we're talking about.</comment></comment></comment></comment></comment></comment>


China denies two million people detained in Xinjiang concentration camps - <AUTHOR> https://www.usnews.com/news/world/articles/2019-03-06/bachelet-presses-china-for-un-access-to-xinjiangs-uighurs <comment><USER2> It is hard to understand how could a country move backwards so fast, from banning their access to the internet to taking them to concentration camps.

<comment><USER3> Concentration camps aren't a step "backwards": they've been used in pretty much all modern societies. They did not exist before the modern era (say, 1800), and are a thoroughly modern phenomenon.

<comment><USER4> Modern in a historical sense sure, modern in the colloquial sense no.

</comment></comment></comment><comment><USER5> Cool. Nazi propaganda used similar terms for concentration camps.

<comment><USER6> Indeed. "Concentration camps" was just such a euphemism, itself: this was the British term for relocation camps for civilians in the Boer War. They weren't great, but they weren't death camps.

</comment></comment><comment><USER7> _" There is no internment camp, no concentration camp, there is only vocational training centers," Dai told the panel._

Are there any other such vocational centers in any other part of China for Han Chinese or any other ethnicity?

<comment><USER8> Actually yes, it's kinda like a correctional facility, people would be set free in a year or two.</comment></comment>


Rewriting each other's commits with Mercurial Evolve - <AUTHOR> https://www.youtube.com/watch?v=4OlDm3akbqg

<comment><USER2> Soon in Mercurial. Years later (probably never) in Git.</comment>


The U.S. Tested a New Missile and We're All Worse Off Because of It - <AUTHOR> https://foxtrotalpha.jalopnik.com/the-u-s-tested-a-new-missile-and-we-re-all-worse-off-b-1840689768 <comment><USER2> While the treaty made a lot of sense 30 years ago, it makes no sense today in light of Russia's violations of the treaty and the rise of China and other powers.

[https://www.fairobserver.com/more/international_security/us-...](https://www.fairobserver.com/more/international_security/us- inf-treaty-withdrawal-russia-china-nuclear-security-news-43210/)</comment>


Apple's Tim Cook Voluntarily Forgoes $75 Million Payout - <AUTHOR> http://www.forbes.com/sites/timworstall/2012/05/25/apples-tim-cook-voluntarily-forgoes-75-million-payout/ <comment><USER2> It's probably actually higher, since Apple has so much cash lying around. They have no reasonable prospect of spending it and they're getting to the point where no acquisitions that make sense would dent the horde. (I mean, they could buy a carrier, but why buy the cow if you already get all of the profits of milking it for free.)

This suggests that, like MSFT before them, they'll eventually raise dividends.

</amateurish speculation>

<comment> wh-uws I like it though (despite it being "amateurish speculation").

Allow me to add my own. I would love to see them purchase a carrier though.

Imagine it. How much better would things get if Apple owned the towers and spectrum too.

They've got more hardware and software talent in units as small as 5 or 10 then some of those companies have in their entire workforce.

And for all the ridiculousness they've put us all through over the years I would love to seen them squirm as they try to figure out how they are going to compete with Apple.

<comment><USER3> The thing people don't seem to get about buying a carrier is that you can't just add "Wireless Carrier" to your inventory, dual-wield it, and collect the stats boost.

Carriers are capital-intensive, operations-intensive, customer service- intensive businesses. You have to run them effectively, _as a carrier_ , at huge expense, or they degrade.

Apple has no competence in running wireless carriers. Tens of billions of dollars will buy a lot of competence, but not instantaneously. Given the stakes, I imagine "operating a wireless carrier" is not one of those things you want to learn how to do as you go.

I'm also amused by the sentiment on HN (and the Internet at large) that 2012 wireless carriers are really just a cartel organized to collude on providing bad customer service and exorbitant rate structures. As if no carrier figured out that executing better service and value would improve their competitive position; no, the only reason wireless carriers suck is that they choose to suck!

<comment><USER4> I remember back in 2006 when everybody thought the phone manufacturers were doing the best they could as well. The CEO of Palm famously responded to rumors of the iPhone:

> _Responding to questions from New York Times correspondent John Markoff at a > Churchill Club breakfast gathering Thursday morning, Colligan laughed off > the idea that any company — including the wildly popular Apple Computer — > could easily win customers in the finicky smart-phone sector._

> *"We've learned and struggled for a few years here figuring out how to make > a decent phone," he said. "PC guys are not going to just figure this out. > They're not going to just walk in."

Turns out they really were just sitting on their laurels, and Apple really could walk in and eat their lunch.

Not disputing that running a carrier is a PITA. Just that the carrier market today really is competent and providing roughly the best value it can.

<comment><USER5> > Turns out they really were just sitting on their laurels, and Apple really > could walk in and eat their lunch.

Not really, Apple had been struggling for a few years to learn how to make a decent phone too, they just didn't release the ones that kind of sucked.

AT&T (in its previous incarnations as Cingular, SBC, BellSouth, and AT&T) has spent the last twelve years trying to make a functional cell carrier, and it takes them over 70,000 employees to do so. I suspect that Apple's 60,000 employees aren't focused on carrier operations.

</comment></comment></comment></comment></comment><comment><USER6> Another reason may be to avoid a conflict of interest - Tim Cook, as the one ultimately responsible for commencing the payment of dividends, would be paying himself a rather large bonus out of the company cash.

<comment><USER7> Another way of putting this would be: Leadership.

Apple comes into a lot of criticism for the constraints that it puts on its employees. If I were an Apple employee, Cook's action here (omitting financial gain form himself) would be a valuable demo to me of commitment to employees' welfare.

<comment><USER8> Exactly.

I hate how the author automatically assumes the worst about Cook and that it has to do with taxes (even if it did, I'm pretty sure 75 million - (whatever taxes incurred) is still quite a few million).

I think it makes sense and is a solid move that he recognizes that he's issuing the dividends and that taking them could appear as a conflict of interest. If I was an Apple employee, I would be impressed.

</comment></comment></comment><comment><USER9> Why keep the money at Apple? Why not set up a foundation/donate it to a charity? Could go just as well for Apple's stingy reputation toward charities.

<comment><USER10> Apple is not a charity. Even though things are going well today in 2012, doesn't mean that things will be going equally well in 2018. In any case, I think there will be issuing of dividends down the line. The shareholders can then themselves decide whether to use the dividends for the purpose of charity or not. I feel this is the most fair way to run a company. (I am not saying that Apple should stay entirely away from charities though.)

<comment><USER11> A good to also think about is that not too long ago, Apple was almost bankrupt. A lot of people these days just the of Apple as the iPod/iPhone/iPad titan who makes money hand over fist. But, I wouldn't be surprised if there was a decent amount of institutional memory about their almost fate in the 90s.

If you almost lot it all, only to come back, you might want to kee a large war chest too.

</comment></comment></comment><comment><USER10> My heart skipped a beat as I misread the sentence as "[...] Forges $75 Million Payout". I agree with the other commenter in here regarding it being a conflict of interest, as Cook is personally responsible for handling the divident payments to the shareholders.

<comment><USER12> Does the board have a say in this? Or are dividends something the CEO decides on?

<comment><USER10> As far as I know, only the board of a company has the power to issue dividends. However, it is often the case that a chief executive officer is also a member of the board, thus giving him power to issue dividends.

Tim Cook serves on Apple's board of directors according to this page: <http://www.apple.com/pr/bios/tim-cook.html>

</comment></comment></comment><comment><USER13> How cool would it be if he donated it to cancer research?

</comment><comment><USER14> This is actually not really news since Apple said this already on their dividend announcement in March. Check the transcript for source

</comment><comment><USER15> According to forbes [<http://people.forbes.com/profile/timothy-d-cook/6607>] he has 52bln$ in stock. He's just giving up on loose change. This is comparable to me giving up back to the company around $30, I think I would not have a problem with it (it also would not make big news)

UPDATE: ups, indeed, I can't read, moot point then

<comment><USER16> That's $52 million, not $52 billion, and that's 2010 income. He has unvested stock worth up to half a billion over the next decade (assuming the share price stays roughly where it is at the moment).</comment></comment>


CPU DB: Recording Microprocessor History  - <AUTHOR> https://queue.acm.org/detail.cfm?id=2181798

<comment><AUTHOR> For those who are equally disturbed by some of the graphs, Herb Sutter's "Welcome to the Jungle" makes for a great read: [http://herbsutter.com/welcome-to-the-jungle/](http://herbsutter.com/welcome- to-the-jungle/)

</comment><comment><USER2> Actual database:

[http://cpudb.stanford.edu/](http://cpudb.stanford.edu/)

<comment><USER3> Even better:

[http://cpudb.stanford.edu/cpudb.1333574285.tar.gz](http://cpudb.stanford.edu/cpudb.1333574285.tar.gz)</comment></comment>