Why should I have written ZeroMQ in C, not C++ - <AUTHOR> http://www.250bpm.com/blog:4 <comment><USER2> This is absurd. Exceptions are just generalised returns. You can use them well and benefit from them, or use them poorly and make the stuff of nightmares.

It's the same with any feature of any language. You can choose not to use exceptions in your code, if that makes it easier for you to understand and manage, but it's certainly not the fault of the feature in general.

Basically, it's up to you to structure your code well. Yes, it gets bad if a potentially throwing function can be called from multiple points. The error needs to be handled at every one of those points, and probably in much the same way.

But if you see repetition, _why aren't you factoring it?_ And why are you calling that function from multiple unrelated locations in the first place?

I get it. I've used C++ for half a lifetime—it's a hopelessly broken language. There are tons of things about it that just make me furious. But I can get stuff done in it because I've taken the time to understand it in depth. Don't complain about the language or a particular feature thereof just because it's not suited to your problem or your way of thinking.

There are other languages out there (Erlang) that are far better suited to stable zero-downtime systems than C++. There are languages (Haskell, Lisp) that help you better manage complexity than C++. Every language implementation worth its salt has C bindings, so you can write performance-critical code at a low level, while still managing the whole system in a high-level language. There are options. Explore them!

<comment><USER3> One of his first examples is additionally absurd and is either the flimsiest of strawmen or he simply doesn't understand when exceptions should be used:

        try {
            ...
            int rc = fx ();
            if (rc != 0)
                throw std::exception ("Error!");
            ...
        catch (std::exception &e) {
            handle_exception ();
        }

Why is he throwing exceptions and catching them within the same function? His "C equivalent" is what he should've been doing in C++.

<comment><USER4> He states how he understood exceptions:

"C++ exceptions just didn't fill the bill. They are great for guaranteeing that program doesn't fail — just wrap the main function in try/catch block and you can handle all the errors in a single place."

This is something i learned in my very first computer science lecture not to do.

To be fair: It's what exceptions can be good for - a last barrier before a crash and a way to handle errors later. But you're absolutely right that he simply could react directly to the error. Or throw specific exceptions and react to them. His described issue has nothing to do with exceptions themselves, just with the way he thinks he has to use them.

<comment><USER5> Though we probably learned this is not the way to use them, I have seen numerous real-world examples where this was the case.

Not only that, I don't think C++ exceptions are necessarily very good at being a 'last barrier' before a crash - they simply can't catch all the errors, because they are good at indicating conditions that might be recoverable, not catching and recovering from logic errors that would cause a crash. There are plenty of ways to hang yourself in C++ without ever throwing an exception.

<comment><USER6> "Though we probably learned this is not the way to use them, I have seen numerous real-world examples where this was the case."

Ah, Java code at my workplace.

       catch(Exception e) {}

<comment><USER7> I believe you mean catch(Throwable t) {}

</comment></comment></comment></comment></comment></comment><comment><USER8> It looks mainly looks like a rant on exception, but nothing forces you to use exceptions with C++. You can even allocate memory in a way that doesn't throw.

We don't use exceptions for the reasons described in the article (and many others), we use boost::system::error_code instead.

But that's for the first half of the article, and the OP admits that he simply gave up on exceptions.

As for the part about half-initialized state, I think the problem is that the author is trying to do OOP in C++ without exceptions. Perhaps a more generic programming approach would solve his "half initialized problem".

Don't want to sound like a snob, but it really looks more like a design problem than a language problem.

<comment><USER9> I agree, this is just a rant on C++.

Coming from Java world, I can tell that it is nice being able to raise exceptions from the constructor.

However, switching from C++ to C is absurd. C++ is (mostly) a super set of C. Whatever you want to do in C, in C++ is also possible.

If there are some C++ features (exceptions, classes, contructors, etc.) that are making his coding task more complicated, he should simply stop using those features and refactor his code.

<comment><USER10> There is one advantage to writing in plain ANSI C and it is that you get it to compile and run on _anything_.

</comment></comment></comment><comment><USER11> This strikes me as throwing the baby out with the bathwater. While the criticisms are valid, and people love to hate C++ for all sorts of reasons (I avoid C++ exceptions altogether), C++ _is_ for practical purposes a superset of C, so if a C idiom works better than its C++ equivalent, you can just use it instead. I've been working on a project which has necessarily been written mostly in pure C (kernel code), and I do really miss C++'s extra type safety. (GCC has some type warnings that help, but it's still not as safe)

Then again, maybe an entirely different language, geared towards high availability, such as Erlang or Ada, might have been a better choice in the author's case.

<comment><USER12> The thing is, if you use the subset of C++ people usually recommend, you're hardly better off than with C. Turning off exceptions means you can't use the STL (alloc errors throw) and you can't do any non-trivial work in your constructor so you have to manually initialize everything anyway.

<comment><USER13> In C++, allocation errors don't need to throw an exception.

      Object* obj = new (nothrow) Object;

If the above allocation fails, obj will have the value NULL. It's tedious, but you could replace the default, throwing allocation with a non-throwing allocation in all places of the STL. However, various parts of the STL throw other kinds of exceptions. But, I think one could have a compromise, where you deal with exceptions from libraries you use, but you don't throw any yourself, instead using C-style error handling.

<comment><USER12> If you replace the STL allocator with a non-throwing allocator how do you know that that vector you just push_back'd didn't actually allocate any new memory?

<comment><USER14> Indeed, you have to roll your own data structures. This is pretty common in the game development world, where exceptions are considered to have unpredictable performance characteristics.

<comment><USER15> That is a pretty tight requirement, considering the internals of Ogre 3D engine. It is full with exception classes (some might argue it is way too overengineered.)

Are custom data structures available as open source that don't use exceptions? Or perhaps can you please name an engine that already has this?

<comment><USER14> There is EASTL, though I've never used it myself. <https://github.com/paulhodge/EASTL>

Valve's Source SDK makes extensive use of their own data structures, however it is very specialized. For example, linked lists are allocated as growing, contiguous blocks of memory to reduce cache misses. The Doom3 source code might be worth looking at, but I'm sure it's the same story. <https://github.com/TTimo/doom3.gpl>

At the very least, there's a lot of great reference out there.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> This describes quite well why I strongly recommend against exceptions in embedded code.

There are ways that you can use constructors, one way is to have an error-code as part of the object that the constructor can set. Another way is to use the empty-constructor/init-method pattern that he talks about and wrap it in a static method (or function) and that becomes your actual constructor. I _think_ you can even make the constructor private which will prevent accidental calling of it.

But this is just another example of why high-reliability systems require considerably more discipline in C++ than in C, since C++ gives you more rope, it's easier to hang yourself.

There is an argument that such a limited dialect of C++ is so close to C (with a good 3rd party data-structures library) that there is no point to C++ in such situations (which seems to be the point the article is making), and I tend to go back and forth on this.

</comment><comment><USER12> I really think the final nail in C++'s coffin is going to be its refusal to play ball in a polygot world. Most languages let you drop down into C pretty easily but C++'s weird name mangling, exceptions and complex, usually nonstandard ABI makes interfacing with C++ a _major_ PITA. In the days when C++ was used soup-to-nuts this wasn't such a big deal but these days you almost always want some kind of higher level language on top.

Just look at all the contortions WinRT has to go through to expose its APIs versus the clean Foundation/Cocoa layering you see in iOS/OS X for a great example.

<comment><USER17> Name mangling is pretty common in any high level language, although people only bash on C++.

<comment><USER18> Can you name some other examples?

<comment><USER17> Ada, Modula-2, Modula-3, Oberon, Haskell, ML...

I cannot give specific examples, but I am pretty sure that you'll have a hard time trying to combine modules generated from different compiler vendors.

Already the first hurdle is that each vendor has its own language runtime that is only compatible its own implementation.

Second, not all languages define a binary ABI on the language specification.

</comment></comment></comment></comment><comment><USER19> Going forward, I think C++ is not a bad choice, but I can definitely see the distaste for exceptions. Unfortunately, as the author notes, simply not using exceptions doesn't quite do it. Fortunately, the hard work has been done for you. Much of Google's code was written in an exception-free manner before newer evolutions of C++ came out. This means that they have banned use of exceptions in their style guide. Luckily, it also means they've developed workarounds for most of the exception pain points.

I would encourage everyone to take a look at the Google C++ style Guide[1]. Most of the complaints are addressed in that article. Constructors can only signal errors through exceptions, so Google C++ allows only basic initialization in the constructor -- all real work is done in an explicit Init() method which can signal an error. I believe the guide addresses the posters other concerns too.

In general, the Google C++ style guideline is a very good resource for writing consistently good C++.

[1] [https://google- styleguide.googlecode.com/svn/trunk/cppguide....](https://google- styleguide.googlecode.com/svn/trunk/cppguide.xml)

<comment><USER20> Agreed, it is a very good guide.

However, the ZeroMQ author goes a lot further than that for his specific application.

He made some reasonable arguments that even the use of OOP/classes in C++ makes catching undefined behaviour unnecessarily difficult for systems programming.

<comment><USER19> His other objections didn't make a lot of sense to me. Destruction doesn't seem like something that can fail. Your object has been deleted or it is going out of scope. You don't even manually call the destructor. It should be about freeing resources. what work is he doing in the destructor that can fail?

<comment><USER21> Well, fclose can fail, for example; it can as part of the closing process flush its buffer and that can fail like any other I/O process. Further, sometimes the error than happened during a previous write(2) call is only detected in the close(2); think NFS and quotas, or check the man page. So already we have errors that occur during teardown that need to be handled somehow.

Similarly one can imagine using RIAA to hold a file lock, or a temporary directory; this is a perfectly reasonable thing to do but there are dozens of reasons why the final rm -rf of the tempdir could fail.

The idea that somehow object teardown is immune to failure is overly naive, and the fact that you can't accommodate it easily in RIAA is quite disappointing and makes the whole paradigm much less useful for carefully coded software.

<comment><USER19> My claim is that object teardown is not what the destructor is for. Teardown encompasses many things that are not resource releasing. Destructors are for releasing resources, not necessarily guaranteeing their destruction.

For example, fclose can fail, but even if it does, the stream given is no longer held. In fact, any further use of the stream is undefined. There is certainly a place for logging in this situation, but if close was a _behavior_ of the class, it should have a separate close function.

As far as locking goes, it is the responsibility of the locking routine (probably a semaphore) to release the callers hold on the lock, but it is not the callers responsibility to ensure that whatever resources are associated with the lock (e.g., a file) actually get deleted. That is the locking object's responsibility.

I agree that some aspects of RAII could be better, but C is not the answer to that. C doesn't even have scope-based RAII.

</comment></comment></comment></comment></comment><comment><USER22> That's awesome, I'm already looking into crossroads-io. I like C because it's that much more readable: There is no magic, you always know where things are and where they are going, in terms of memory and control flow. C++ seems very convenient at first, all the nice standard libraries do have attraction for me but in the end you end up with tons of weird hierarchy magic, friend classes, nested classes, copy constructors and destructors firing at the weirdest places. Now everybody says: "Well you don't _have_ to use those!". Well, true but in practice it doesn't turn out that way.

<comment><USER23> If you're enough of an expert in C++ to use it in failproof ways, then you're enough of an expert to do the same in C, and with far less mental overhead for yourself and everyone who comes after you to read the code.

</comment></comment><comment><USER24> 90% of this thread isn't addressing his core point, which is that even if you use C++ without exceptions, constructors and destructors still make it hard to be strict about error handling, and the extra complexity isn't worth it for projects like his.

Fine to disagree, but respond to the point. So far the relevant objections I've seen are: (a) you shouldn't do anything in a constructor that might fail; and (b) destructors can't fail. Weak. Is there a good counterargument? To be precise: why is the OP wrong to say that, to be strict about error handling, his C++ needs to look like the block of code that follows the sentence, "There's a new 'semi-terminated' state" in the article?

(As for most of the comments, which boil down to "OP is ignorant of basic things about C++ and programming", come on you guys, how likely is that? Who's more likely displaying ignorance here?)

<comment><USER15> Author went from constructors+exceptions to init_foobar()+return value for error handling. When you misuse exceptions, they become unmanagable nightmare, which I believe would have happened with 0MQ. And throwing exceptions in constructors is one really good way to misuse them.

And ranting about it seems like ignorance to me, but that's beside the point.

For me, checking return values is just as, if not more, tedious than catching some exceptions. Return values should be used to guide the flow of the program state (IMHO), and exceptions represent invalid states.

<comment><USER24> You still haven't responded to his point, which is that to deal with the reality that constructors and destructors _can_ fail, he ended up having to write more complex code than he would in C. (Specifically, the code in the passage I cited, which turns each object into a little state machine.) Saying "just make those things not fail" is no answer at all. So, to repeat: how could he meet his error-handling goals in C++ without handling object construction/destruction in that state machine style?

I have no opinion about this, but given that it's the point of the article, that's what people should be addressing.

<comment><USER15> It's not that constructors/destructors can fail, it's about the conscious decision when you make them to. If you choose not to use exceptions at all, you can prevent improper state before object construction, just like you would in C's init_foobar().

</comment></comment></comment></comment><comment><USER25> For careful error handling, my favorite language is Go. It lacks exceptions, so you have to return errors as in C. But it has python-style tuple return, making it easy to return a value or an error from any function.

The fact that errors are explicitly returned requires the programmer to explicitly handle them, which encourages design that considers error handling.

The evil of exceptions is they hide errors until they happen.

</comment><comment><USER26> Exceptions are indeed not the silver bullet to error handling. Handling errors upstream can be useful as catch-all, but when the entire stack has been unwound, it can be hard to recover the error usefully. Also it is hard to make a sensible inheritance hierarchy, and every library chooses its own, generating a forest of different-but-equivalent exceptions to handle.

A fully-fledged condition system (like Smalltalk, CL) would allow for a lot of scenarios where exceptions currently give trouble. They would allow recovering the problem where it happens, retrying operations, and so on. Too bad so few languages have that.

However I don't think the right solution is to use an even more primitive language. C seems simple, but you end up doing everything yourself that would otherwise be done by the compiler, which is a lot more work, bug-prone, makes the code verbose, and generally inconsistent (unless you're very disciplined; forget about it in a team).

</comment><comment><USER27> I wonder what error-monad looks like in C++, or C for that matter.

here's a rough, probably incorrect demo in python: <https://gist.github.com/2653752>

gives you nice, clean, exception-like error handling that doesn't leak to the wrong level of the call stack, and in a statically typed language the compiler can verify your error handling for you. quite similar to checked exceptions. call stack issues can be fixed with some low level C, or you could even unwind the stack with some exception trickery.

</comment><comment><USER28> In C++, if you run into an error and you know how to handle it, you handle it. This is exactly the same as C. Exceptions are only there for when you don't know how to handle an error. Instead of calling exit(), you throw an exception and hope that someone further up the stack can do something useful. By default, your program terminates, just like exit... but all your destructors get called, so you don't leak database handles or locks or other resources. Nice.

I've read the Google C++ style guide and it's basically a joke. At least it was a joke two years ago. The guide even contradicted itself in multiple places. Google bends over backwards to avoid using exceptions and the result is that C++ isn't C++ anymore.

<comment><USER29> I agree with this entirely. Exceptions and errors aren't necessarily the same, i.e. errors aren't always exceptional cases. When errors can be dealt with locally they should be. The problem comes when an error can't be dealt with locally. Then as stated, exceptions can be used to propagate the condition upwards in the stack where some other component may be able to deal with it.

</comment></comment><comment><USER30> I struggled with a similar question for my low-level protobuf library UPB (<https://github.com/haberman/upb>). Here are some blog posts describing my dilemma about this: <http://blog.reverberate.org/2009/11/porting-upb- to-c.html> [http://blog.reverberate.org/2009/12/torn-over-c- question.htm...](http://blog.reverberate.org/2009/12/torn-over-c- question.html) I ultimately chose to stick with C, and I'm happy with my decision.

When people ask me why I stuck with C, it's difficult to give a single overwhelming reason why C is better. The most clear-cut one is that C++ is not supported in the Linux kernel and I want my library to be usable there. But the other reasons why I prefer C are not as easy to quantify.

One reason is that code written in C is more transparent. You can look at some C and know what it is going to do (add some numbers, call a function, etc). Macros are the one exception to this, but good C programs use these sparingly and clearly mark the macro with an UPPER_CASE_IDENTIFIER. C++ is much harder to "see through." Any function call could end up throwing an exception which does a non-local exit from the function. Any addition, assignment, pointer dereference, etc could actually be an overloaded operator. Any function call could be performing a user-defined implicit conversion on any of its parameters. For overloaded functions, the compiler decides what function is actually called by applying non-trivial pattern matching rules. The runtime will automatically invoke any static initialization code (like constructors of global statics) pre-main in an undefined order. etc. etc.

I intend to get a thorough security review of my library once its design stabilizes. I asked Tavis Ormandy (a fellow Googler and security badass) which language is easier to audit for security and he said C for the reasons of transparency I listed above.

People often say that you can just avoid using the parts of C++ that you don't like. That is true, but hard to enforce, especially on a multi-person project. If you're asking others to follow your set of rules, you have to write those rules down in meticulous detail, leading to something like the Google C++ style guide ([http://google- styleguide.googlecode.com/svn/trunk/cppguide.x...](http://google- styleguide.googlecode.com/svn/trunk/cppguide.xml)), and at that point you're asking your contributors to study and internalize a large and complicated list of what is and isn't allowed just for the privilege of contributing to your project. I don't think this approach scales to lots of projects that are all choosing a different subset of C++.

There are definitely things I miss by not having C++'s facilities. Constructors and an implicit "this" parameter are both really nice. Constructors are remarkable in that you can write a single function that gives you three different construction patterns for free (direct construction, heap construction with "new", construction in an arbitrary location with placement new). Automatic upcasts are nice and totally safe. Inheritance and public/private specifiers let you express directly lots of things you can only express with comments in C.

But overall I think that using straight C is the right choice for a project like my library UPB.

<comment><USER31> C is superior for libraries since a lib can then be used from so many other languages. A C++ library that doesn't provide a C API is an absolute nightmare to write bindings for.

<comment><USER32> So true. Binding to Python is such a pain: <http://www.boost.org/doc/libs/1_49_0/libs/python/doc/>. Lua is even worse: <http://www.rasterbar.com/products/luabind.html...>.

Seriously, once you know how to use it, C++ actually makes binding to a lot of higher level languages a lot nicer than doing so with C.

<comment><USER33> ... I am sorry, but that's _very_ untrue.

As it happens, not every language is implemented using runtime written in C/C++, nor does every language modules written in C/C++ to extend it instead of FFI.

Dealing with libraries written in C++ without C API is one of the worst PITAs in my experience, leading to crazy things like KDE's SMOKE (which, to make it funnier, has bad documentation, so I'm still unsure if I can make it work outside Qt's object model)

<comment><USER32> > ... I am sorry, but that's very untrue. > > As it happens, not every > language is implemented using runtime written in C/C++, nor does every > language modules written in C/C++ to extend it instead of FFI.

You did an awesome job tearing apart that strawman, but you are misrepresenting what I said. That second sentence is in no way in conflict with my " _very_ untrue" statement.

To refresh, with emphasis added for the reading impaired:

        C++ actually makes binding to *a lot* of higher level languages a lot nicer than doing so with C.

That you can find a distinct subclass of languages where you believe that it is hard to do bindings to C++, doesn't mean the above statement is even mildly untrue, let alone very untrue. Please review and reconsider:

* There are certainly a lot of higher level languages which don't qualify for your definition. * SMOKE is actually a binding through Qt's MOC, which is generally considered by the C++ community to be something which makes Qt pretty un-C++-ish. You are right to phrase it as "Qt's object model", because it sure as heck isn't C++'s.

Try looking at the LuaBind and Boost.Python libraries. They represent a very different approach to language binding, and it isn't dependent on there being a wrapper C API. While writing binding framework for a given language is a bit of a PITA, once that has been built, it really does make binding to a high level language a lot easier than trying to do it through a wrapper C API.

</comment></comment></comment></comment></comment><comment><USER9> GCC is finally switching from C to C++, and they are actually avoiding exceptions and RTTI.

<http://gcc.gnu.org/wiki/CppConventions>

I salute them on following strict coding conventions.

</comment><comment><USER34> I'm not C++ savvy, but I know from reading Google's C++ style guide that they also disable exceptions. The guide leaves it at that and doesn't say anything more about how to deal with errors. Does anyone here know how these big Google C++ codebases handle errors instead?

<comment><USER35> [The following is speculation: I have no access to Google's code.]

I can't think of any other way to handle errors apart from using return values. Methods return error codes which are handled by the caller or bubbled- up to its caller. This tends to result in lots of duplicated error handling code, and you have to either dedicate the return value to success/fail (which means you have to return non-status data some other way) or use special values to indicate failure.

The Go language (from Google) doesn't have exceptions and allows functions to return a value and an additional error return value [1]. I'd guess that this is inspired by their approach to C++ coding.

[1] <http://code.google.com/p/go-wiki/wiki/Errors>

<comment><USER36> Isn't it possible to fake this with C++ templates? As an example, I created <https://github.com/rb12345/cpp_annotated_return>, which uses a templated struct to allow multiple value returns.

<comment><USER35> Yes, you could do it that way. Personally I'd restrict the error code to always be an int, which makes for a terser syntax as you don't need the second template parameter.

You could also extend it to support multiple non-error return values, like Python does. But this introduces problems with expressing the contract between caller and called (e.g. [1]) and I think the best way to address this might be to extend the language syntax.

I think one of the most interesting design choices in Go is that it intentionally omits _conventional_ exceptions. It does have defer/panic/recover [2] though.

[1] [http://stackoverflow.com/questions/354883/how-do-you- return-...](http://stackoverflow.com/questions/354883/how-do-you-return- multiple-values-in-python) [2] <http://blog.golang.org/2010/08/defer-panic- and-recover.html>

</comment></comment></comment></comment><comment><USER37> This may just be because of when I learned to program, but I find that writing object oriented code makes everything easier to understand. The stuff you need to do with C where you're passing around structs and state and pointers usually looks pretty ugly to me.

Error handling is a pain in any language. "This thing that should NEVER fail just failed, now what?" If you're not in a recoverable state, realistically, what can you do?

I know that constructors _can_ fail, but it's pretty abnormal for that to happen. I like the way objective-c handles it. Since everything is dynamically allocated and you can just see if the object exists to find out if it works. Lots of methods have an extra NSError parameter that you can use if you need more information.

</comment><comment><USER38> His reasoning is bogus. For his C equivalent, he writes:

> There are only two states. Not initialised object/memory where all the bets > are off and the structure can contain random data.

He can get exactly the same effect by mimicking fstream interface: use constructors and destructors as they were meant to and introduce bool operator! to check whether the object has been successfully initialized.

In this scenario, only destructor needs to know about the "fail-constructed" state. Other methods don't need to implement the state-machine; calling them on "fail-constructed" object would be undefined, _exactly as in his C version_ (e.g., calling foo_bar without calling foo_init and checking that it succeeded)!

</comment><comment><USER39> The one advantage of C over C++ is simple: what you see is what you get.

If you have to wonder about what a statement really might mean depending on a bunch of state that was fed to the compiler then that really spoils things.

</comment><comment><USER40> Just to quickly note here: Certain very popular game console does not allow use of C++ exceptions - the underlying runtime / abi / whatever simply does not support it.

Not that you would ship ZeroMQ code in it (it's GPL), but still.

Oh, and I love ZeroMQ, and I even love it more, that the "C" interface was the one being public, not the "C++".

Also good article. I love exceptions in higher-level languages - lisp, lua, etc. - but I prefer error codes in lower-level ones, and I consider C++ as such.

</comment><comment><USER41> I agree fully with the author - exceptions are a problem for software that wants to avoid unexpected behaviour. I noted something similar in [http://tratt.net/laurie/tech_articles/articles/a_proposal_fo...](http://tratt.net/laurie/tech_articles/articles/a_proposal_for_error_handling) and sketched a possible compromise, more to emphasise the point, than as a serious proposal.

</comment><comment><USER42> Interesting read but the problem is not C++ here. The problem is the author's usage of C++ and specifically exceptions. If he does not like exceptions then just implement more traditional error handling while keeping all the other good things that C++ provides.

</comment><comment><USER43> >Now consider what happens when you add inheritance to the mix. C++ allows to initialise base classes as a part of >derived class' constructor. Throwing an exception will destruct the parts of the object that were already successfully initialized with this

which object is he talking about here ? if foo inherits from bar, object foo is not considered a _valid_ object till it's constructor _completes_. so there is no question of destroying parts of objects which were already constructed.

similarly, during object destruction, as soon as the destructor is invoked, the object is in an invalid state.

i guess there are some issues in understanding of object lifetimes and exceptions thrown by it's constructors...

</comment><comment><USER44> The reasoning is very poor. I thought he was going to say something along the line of portability. Nope. It was about exception.

Granted, exception is problematic. I don't use exception for similar reasons. However, given the nature of this project, it should have been clear that exception should not have been used in the first place. Instead, be very explicit about error handling. This is really a poor design choice. How is it the conclusion that the answer is C, rather than "C++ without exception?".

</comment><comment><USER45> C++ exception specifications are worse than nothing. Unlike Java's (controversial) checked exceptions, C++ exception specifications are not compile-time checked. Instead, the compiler generates run-time checks when calling function functions with exception specifications. If the function throws an exception that does match its specification, the program calls abort()!

</comment><comment><USER46> As with most experiments in writing object oriented code in C, this looks a lot like Objective-C.

</comment><comment><USER47> Exceptions shouldn't be used as gotos. Instead of letting every exception bubble to the top, handle them at the appropriate level in the stack where you can recover from the error they representing.

</comment><comment><USER48> Bjarne did it all for us. <http://harmful.cat-v.org/software/c++/I_did_it_for_you_all>

<comment><USER49> A spoiler: <http://www.snopes.com/computer/program/stroustrup.asp>

</comment></comment><comment><USER50> Oh well. It was probably faster and easier to code in C++ initially. And allowed him to beat all the competition to market.

</comment><comment><USER51> looking forward to crossroad i/o. This step will drive the two projects even further apart. But zeroMQ is already established, and its name is more catchy. Good luck.

</comment><comment><USER52> _"First, it's important to take into account that ZeroMQ was intended to be a piece of infrastructure with continuous uptime. If should never fail and never exhibit undefined behavior."_

There is one language/platform[1] I'm aware of designed for this type of system, and which achieves it beyond all others: erlang.

If Uptime is important, how do you handle it when you want to update your software under C++ or C? You have to bring the service down. Erlang supports updating software while its still running.

If exception handling is important (to prevent crashes) how do you handle it when there is a bug? Erlang has supervisors that not only help you manage exceptions but keeps the service going when an unhanded exception causes things to crash.

More importantly, intrinsic to the nature of the way you write erlang code, you eliminate a great deal of the possible errors. In C code you have to check to make sure things are in the right state while running your code. In erlang, your code doesn't run (the function isn't called) if the state isn't right to handle it. It flips this problem eliminating many classes of errors. Further there is OTP support for many types of processing (like state machines) that makes writing these types of solutions much easier.

Erlang is great for making sure no undefined behavior happens. Erlang is also great (as I understand it, this I haven't gotten into) for creating unit tests that can fully exercise the code across all possibilities.

Where does erlang suck? I don't think it sucks anywhere because it has solutions for all of its own problems. For instance, single node performance of an erlang program (which runs in the BEAM VM) is going to be lower than single node performance of a C program... but in erlang you can increase capacity nearly linearly simply by adding more nodes... while this is nearly impossible with almost all C/C++ programs without spending a lot of time working on it.

But where erlang _is_ weak is that single node performance which might be really important[2], and if it is, you _can then write your performance critical bits in C_.

Thus the things that do the real work can be fast and in C but the things that keep the system going and distributed (where performance of this kind is much less critical, but performance of the operational kind is paramount) can be written in erlang.

So, I think the second mistake he made, and is still making, is thinking that the project has to be written in a single language.

If you use the best language for the job, then sometimes that should mean using two languages right?

Erlang is not a hipster language. No hipsters use erlang. It is 25 years old and boring and %99.9999999 uptime. Its ugly. Its not hot and fresh and new. But it is the right language for the job, when you've got a system that need to run across cores or nodes, or have very high uptime.

And really, it doesn't take but a couple weeks of learning. Then the syntax will be gorgeous and you'll be a better programmer for it.

[1] I say "I'm aware of" for a reason. There may be others as well suited when this is the primary goal, possibly even better suited. I don't know all languages. But I do have a pretty good survey started in the days when new languages were as common as YC batches and much more experimental than they are now. My point isn't to bash other languages but to promote one that isn't understood correctly by many people.

[2] I think this is the case a lot less often than people think. People benchmark things on a single node even when they know they are going to build a cluster of machines to run them, and then pick them based on this. Redis is really fast. Is redis distributed? Riak has a fully distributed in memory database (which means 10 32GB nodes means you can store 320GB in RAM if you want, rather than have 10 nodes all storing the same data in a cache, and thus much less data cached for the same number of machine with something like Redis.

<comment><AUTHOR> The article is about undefined behaviour. Erlang won't help much with that.

<comment><USER53> Depends how you write your code. Actually Erlang is pretty good at avoiding undefined states (which can be thought of as undefined behaviour) by putting everything in an OTP framework. There's no custom "I'll just handle this earlier here in a tricky way" - if you stick to OTP you'll have message handlers and state machines. That's really awesome if you're programming network daemons. You can pretty much follow the state machine diagram and make sure that unless some progression is possible, it will not occur in practice.

Testing based on OTP service trees also makes the verification fit the possible transitions in a much closer way than trying to cover all the branches in an OO app.

So yes, I'd say it's actually quite a good response to an "exception handling all over the place" problem. You simply don't do that. Instead your exceptions finish at the FSM level and progress you to one of the error states on your diagram. You know exactly what state you're in at that point so the behaviour is pretty well defined at almost every step.

However zeromq is a library that was supposed to be portable, rather than a daemon itself, so from that perspective, it's a very bad fit for ZMQ.

<comment><USER54> What worried me about Erlang was that when a process dies and gets restarted, the message queue for the old process gets thrown away. Neither the sender(s) nor the new process can tell how many messages were lost.

<comment><USER53> If you care about reliability of the delivery, you can do a number of things: do a single call, wait for response and retry if needed, or store the messages in mnesia and only notify there's something to pick up (pull scenario with ack), or do a number of other possible things.

Lost messages are a fact of life really - the same will happen with any other system - either you persist the message and ack the reception on every stage or you risk dropping the queue.

</comment></comment></comment></comment></comment><comment><USER55> on the exception handler part, i don't think you're forced to use c++'s try- throw-catch, you can still safely use the C-style exception methods, after all, c can be used as a subset of c++, though not 100% of the time.

</comment><comment><USER56> wat?

</comment><comment><USER57> The background made that post unreadable for me. Minimalism done wrong.

<comment><USER58> Try readability.com.

<comment><USER59> Even easier in Firefox: View -> Page Style -> No Style</comment></comment></comment>


Is This Why Twitter Changed Its Replies Policy? - <AUTHOR> http://www.readwriteweb.com/archives/is_this_why_twitter_changed_its_replies_policy.php

<comment><USER2> the twitter execs seem to be off in lala land lately catering to celebs</comment>


Largest all-electric aircraft to make maiden flight - <AUTHOR> https://www.cnn.com/travel/article/first-flight-largest-electric-aircraft-scli-intl/index.html <comment><USER2> Article says nothing of the power source, and I could find nothing about it on any of the partners websites, but batteries are not going to get it very far...

"Electric flight is coming, but the batteries aren't ready"

[https://www.theverge.com/2018/8/14/17686706/electric- airplan...](https://www.theverge.com/2018/8/14/17686706/electric-airplane- flying-car-battery-weight-green-energy-travel)</comment>


How to adopt an "openness" mindset at work - <AUTHOR> https://spin.atomicobject.com/2019/10/06/player-mindset/ <comment><USER2> While I agree fundamentally, I think the blog post is focusing too narrowly which gives me a bad taste in the mouth, and I read it as an attempt to pass blame to employees.

For example, one suggestion is to point out the problem and discuss it openly.

>schedule a meeting with the project stakeholders and product owners ... talk about the pattern of incomplete requirements and make recommendations ...

This is great, and from my experience happens all the time. People speak up to managers all the time, every day. Rarely have I seen someone with a problem not bring it up to their manager.

It's the lack of action from managers following the feedback that's often the cause for developers adopting the "victim-oriented mindset". The direct result of manager inaction is for the developer to think _the issues we have are real and are not being addressed, so my manager is indirectly telling me not to bring issues up next time_ which causes the "victim-oriented mindset".

Mindsets are situational, a developer's mindset reflects the environment they find themselves in. Poor leadership is the number one cause for burnout ([https://news.ycombinator.com/item?id=17849489](https://news.ycombinator.com/item?id=17849489)). Poor leadership causes poor mindsets.

<comment><USER3> The main advice is to focus on solutions instead of throwing up your hands. That doesn't mean every attempt will be met with success. Sometimes there won't be much you can do but most of the time there is.

<comment><USER4> Usually, the best solution to a dysfunctional workplace is to find a job somewhere else. If managers do not act on feedback from the people they manage, that is what they are implicitly telling them to do.

</comment></comment></comment><comment><USER5> I adopted a very similar perspective after years of having a lot of manager churn. I used to get so frustrated that my job was unnecessarily difficult because of them. Now it's become, "this is an opportunity to learn new ways to communicate with a manager who thinks it's 1985." So instead of being frustrated at the statement that my TypeScript and the other team's C needs to use the same headers, I focused on how to communicate, in an economy of words, why this API deviation may be a process problem, not a technical one. And in the years since that, I've slowly gotten better (and regressed at times) focusing on what I can control.

<comment><USER6> >instead of being frustrated at the statement that my TypeScript and the other team's C needs to use the same headers, I focused on how to communicate, in an economy of words, why this API deviation may be a process problem, not a technical one.

The statement actually makes a lot of sense if you don't take it literally. If you programmatically generate both C and TS part from the same common definition (protobuf?) as a part of the build process, API deviation will become an easy-to-see compile-time error instead of a runtime surprise.

<comment><USER5> Totally. That's why I got into talking about a common API schema that could be used to generate the required symbols. That got met with discussion of not using TypeScript instead.

</comment></comment></comment><comment><USER7> There's only so much you can do yourself, take into your own hands, look at from the other perspective, mingle around a problem until at long last you'll end up where you started again: Forces out of your control.

And it's (or should be) OK to blame them, you've done your homework.

But then someone comes along and says "You've been going at this the wrong way! Think positive! Think like a 'player'!". And as you roll your eyes, people label you passive-aggressive.

People like that are probably a minority, but they most certainly exist, too.

<comment><USER8> So there's a difference between blame, and discussing failure.

"The project was not delivered on time because requirements gathering took so long. Here's how we think we can help Product define them more efficiently in the future" is different than "It's Product's fault".

Both are laying blame on Product. One is suggesting a solution and sharing ownership of it; the other is only seeking to point fingers.

I would argue at no place should blame be okay. Because that creates a toxic culture; people begin to be less open and transparent about failure, are less likely to take responsibility, more likely to pre-emptively finger point to try to shift blame, etc, and it becomes political. The fact that you feel you are blameless is irrelevant if they can spin it so that it sounds like you are to blame (and trust me, speaking as a dev, the other departments are going to have way more time and experience in playing politics).

<comment><USER7> I agree with you on most counts, but you're viewing it from my position of not yet having (attempted) to see it from different angles and tackling issues (i.e. yet to do homework).

One should definitely do what you suggest and attempt to be constructive and productive (i.e. do the homework).

But if management shoots everything down and they expect you to build a house out of match-sticks and that thing falls apart at the slightest gust of wind, are you to blame or management for not giving you better building materials? (i.e. homework done, nothing left to do)

I'm advocating for a realistic view of things: Sometimes, oneself is to blame, sometimes it's something else, and sometimes it's forces out of our control, but there is always something at fault, if something goes wrong, hence there is always something to blame in failure.

But seeing oneself to be blamed at all times leads to burn-out.

EDIT: I'm aware you could also take a bunch of match-sticks, grind them to a pulp, and create some type of wood-like cement from it, and then build a house from that, and that might work. So let's say, they just give you five boxes with 20 matches each and it has to be at least 25 square-meters. Some might now argue, that you could go and start trading this until you end up with a house, there's the story of a guy who started trading a pen for something else on eBay, and ended up with a house. So management now insists this has to be done by the day-after-tomorrow. Etc. The question is: When and where do you stop telling yourself you haven't thought of the right solution and instead insist that management is absurd?

<comment><USER8> I would argue that that's a different issue. That's not about blame; that's about management refusing to alter their expectations to meet reality, despite you being open, transparent, and respectful about the state of it on the ground. If they are unable to do so, and respond accordingly, it's a good sign you should quit.

That's different than blame though. Yes, when things go wrong they go wrong due to a reason, but I'm simply highlighting the difference between highlighting what went wrong with a "here are some suggestions on how to solve it", and highlighting it just to place blame.

If the culture is focused on placing blame, to where you feel the need to do it, too, just defensively, GTFO ASAP. There is no way to win. I've seen once technical people who gained a majority of their experience in that kind of organization, and they were a liability everywhere they went.

</comment></comment></comment></comment><comment><USER9> You can not take it on yourself to fix a company especially from a position with no authority. You will end up having negative feelings about yourself and your failures to steer the ship in the right direction. People _will_ hate you for what they see as constant interfering with their decisions. This a recipe for ever increasing stress and eventual burnout.

Please remember this: it is not your company. Not your responsibility. You didn't build it this way. Even if you could fix it - and I assure you that you can't - you would be doing the world a disservice. You would keep sociopaths who only care about short term numbers on spreadsheets in business when they rightfully deserve to fail.

If you find yourself with "negative feelings like unfairness, lack of control, or frustration" especially in the IT sector please remember the job market is booming right now and give a chance to another leadership to make the world a better place.

</comment><comment><USER10> This seems a lot like the concept of "Locus of Control": [https://en.wikipedia.org/wiki/Locus_of_control](https://en.wikipedia.org/wiki/Locus_of_control)

</comment><comment><USER11> This is excellent advice.

</comment><comment><USER12> Since lots of comments had an adverse reaction to this use of the word "player", we replaced it above with "openness", which is the word the article uses to describe a "player".

Hopefully that will help the thread focus on the article now.

<comment><USER13> Perhaps a better option would be: "How to avoid a 'Victim' Mindset at Work?"

"Openness" totally confused me—I thought the article would be about being open to other people's viewpoints, or something like that.

<comment><USER12> That's a good suggestion, but I think the word "victim" is still likely to trigger people into reacting to that word rather than the underlying content.

</comment></comment></comment><comment><USER14> You're either at the table or you're on the menu.

</comment><comment><USER15> Good lord, here is a CEO micromanaging people's feelings. This is incredibly insulting and creepy. It would be more honest if he told people to just shut up and do their jobs.

<comment><USER7> When I first read the article, I thought "Wow, this is perfect for a boss to handout to their employees and shift the blame!".

Realizing now, that this was indeed written by a CEO, does add a bit of flavor, but maybe he doesn't have any employees, and it's just a motivational piece he uses for himself. To be honest, I really don't want to know.

</comment></comment><comment><USER16> If you're going to invent an arbitrary term for workplace assertiveness, maybe don't make it homonymous with a term for an aggressively flirtatious man.

<comment><USER17> It's not an invention or arbitrary term. The more traditional usage of the word player for much of the 20th century was to mean someone with agency and control over their own life and surroundings. The usage evolved (narrowed) with the popularity of rap in the 90s.

<comment><USER18> In my mind they're the same. A player makes plays and rises in the social and economic hierarchies to the point that multiple women are courting him, thus giving rises to the guy "playing games" complaints, "being a player." Pick-up artistry mocks what players do around women to get women (poor motivator) and get seen as "players," kinda like crackers get called hackers. I think rappers still meant it in the histiric sense but mass sales means more simps who don't even know a player to misuse it more with an emphasis on women and pickup artists. In our world, leadership at top companies are the players (and ads are the drug, kinda joking).

<comment><USER19> Leadership at top companies is disproportionately sociopathic compared to the population at large, as well. How admirable.

</comment></comment></comment></comment><comment><USER20> The word 'player' doesn't fit well and has bad connotations [1].

[1] [https://www.urbandictionary.com/define.php?term=Player](https://www.urbandictionary.com/define.php?term=Player)

<comment><USER21> Reading the article makes it very clear that they are not using the word in that sense.</comment></comment>


Show HN: I created my first digital download, you can have it for free! - <AUTHOR>

Hey HN,
I created my first digital download, a printable dual timeline calendar for 2014.
In an effort to create more products this year I'm sharing this in some of my favourite web places in the hope I'll get valuable feedback and learn from these experiments.
While the end product may not be technical, the type of product and delivery method are areas I'm really interested in.
The calendar layout was something I've used myself in pen & paper form and has been more recently inspired by bulletjournal.com, the GTD method and quantified self movement.
It may be of use to those of you interested in design, analog note-taking & tracking metrics/data.
I use it to split work from home, track calories in/out & for income/expenses...
You can also use it as a couples calendar, a single line journal, track your mood, your run times - whatever data you'd like to collect over the coming year!
Use the code hn2014 to make it a free download. Feedback is really appreciated as it will help me to improve my ideas & products.
CalCal - A simple printable calendar - http://gum.co/IEMpg
Thanks guys, hope you'll find it useful! <comment><AUTHOR> Clickable - [http://gum.co/IEMpg](http://gum.co/IEMpg)</comment>


Ask YC: How do you deal with external urls? - <AUTHOR>

Yesterday our team had a lengthy discussion/debate on whether to let users navigate to new pages within an existing tab/window OR open new tabs/windows for external urls. We weren't able to come to a consensus. Hence this question!
The Social News feature we are building for the niche market contains external urls. And we also have other features in the pipeline, that may or may not have external urls. Hence the dilemma!
What do you guys think about this classic web usability problem? <comment><USER2> In general, the safe choice is to open a link in the same window. I can use the middle mouse button to open the link in a new tab if I want, or I can just click on it, read the contents, and press Back. If you make the link always open in a new tab/window, my options are more limited, and I have to close the tab/window when I'm done, then hunt through my tabs to find your site again and continue reading.

I say "in general", because there might be specific use cases where a new tab/window makes more sense. Maybe you expect the user to want to keep both windows on the screen, or maybe you expect the user to spend a lot of time or drill down deep on the external page. It's hard to say without knowing more, but for a regular social news site, my personal preference is for same window.

<comment><AUTHOR> Social News is one of the features as I mentioned and for some users it might qualify as just a Social News site based on the way they adopt it but for others the Social News feature might be one of the features they will end up using. Our problem is how do we identify the least common denominator without having to do extensive A/B testing?

</comment></comment><comment><USER3> I'd say only do it if you are targeting an unsophisticated audience. Computer savvy users can handle their windows themselves, but a lot of people can't.

</comment><comment><USER4> Never open a new window automatically - let the user middle-click.

<comment><USER5> I don't know about "never." I spend a lot of money getting users to my site (I'm not web 2.0, but rather a downloadable software product). I'm not eager to send them elsewhere. That's one of my gripes about xhtml 1.0 strict: target="_blank" doesn't validate. So, my site is all strict except the links page, which has to be transitional to validate.

<comment><USER6> It doesn't validate because breaking my preferences and opening a new window which I didn't ask for is (apart from being an obnoxious thing to do) a 'behaviour'.

The "Strict" standard, rightly, enforces a division between content (XHTML), design (CSS) and behaviour ({Java|ECMA}script).

If you want links to open in external windows, attach a behaviour to the link class with JS. Just make sure that behaviour is off by default, though, because otherwise people like me who know what we're doing won't use your site.

<comment><USER5> I don't use JS on my site, because others won't use the site with JS. The link page is the only page on the site that does this, so I'm going to go with it.

It's not obnoxious if you consider that some people really _don't_ understand how the web works or what the difference is between sites. In that case it's a convenience.

This is an idea which should be left as a "best practice," but allow for reasonable differences.

</comment></comment></comment></comment><comment><USER7> I _hate_ it when links force a new browser window or a new tab. Users are smart enough to hold down shift or control when they click to get a new window or tab, aren't they? Why not have an option people can choose to have external links open in a different window or tab?

</comment><comment><USER8> Never open windows in a new window. Users know how to click the back button if they want to come back to your site they will. I also believe its not part of WC3 validation.

</comment><comment><USER9> A meta-suggestion: avoid lengthy discussions about such issues. Pick one option quickly, then run experiments to test whether the alternative improves your relevant metrics. Some issues are too small to invest time in trying to find 'consensus' without hard data.

On the issue directly: the web default is to open links in the same window. Opening new windows is in Jakob Nielsen's list of the top ten very worst web design mistakes†. (It's #9 as of his 2007 update.) So skip the discussion, go with that, and later run some tests comparing stay-in-page with open-new- window on whatever metric is important to you. (Page views? Non-annoyed users? Return visits? etc.)

† <http://www.useit.com/alertbox/9605.html>

<comment><USER10> Exactly. Spending more than five seconds on this (before you have data), and even worse, involving more than one person, is a recipe for fail.

People just love to argue about silly shit like this.

Homework assignment for everyone who felt compelled to chime in with their well-reasoned opinions:

<http://www.bikeshed.com/>

</comment></comment><comment><USER11> You should open the urls in the same window. Because thats what most of your users will be expecting, considering most other sites do that. So by habit, they'll either use the middle click button or some other way to open it a new tab or window.

</comment><comment><USER12> Here's how we do it.

<http://domain.opendns.com/thejack.humboldt.edu>

With the icon... and some text.

</comment><comment><USER13> Don't override the default - even if it seems broken it may be required for compatibility. To paraphrase Tim Berners-Lee, fix your client, not the web.</comment>


The stock market loves Wednesdays - <AUTHOR> http://www.crossingwallstreet.com/archives/2009/02/market_returns.html

<comment><USER2> ...except when it loves Tuesdays, or Fridays, or perhaps Mondays or Thursdays. I'd bet my portfolio on it.

</comment><comment><USER3> Correction: The stock marked loved Wednesdays _until a couple of decades ago_.

</comment><comment><USER4> I've noticed our website traffic consistently peaks on Wednesdays.

<comment><USER5> When I used to work in a call centre I'd make most sales on Wednesday

And same with the site traffic

Wednesday is the new Saturday :P</comment></comment>


Where did the Microsoft tech stack disappear? - <AUTHOR> https://michaelscodingspot.com/2018/07/30/where-did-the-microsoft-tech-stack-disappear/ <comment><USER2> Excluding 77 of the results because they were PHP and so probably "weren't software at all" is silly, to be polite. I understand the assumption is that they are probably ecommerce frameworks or WordPress sites but a) that's a pretty bad assumption and b) for an eCommerce framework, how is that not just part of the stack like any other framework? They are never off the shelf solutions at that scale, and surely it would be interesting to note that a majority of the top 100 were using a particular framework in the stack.

<comment><USER3> All the more condescending considering some of the biggest software companies in the world (such as facebook) use PHP.

<comment><USER4> What Facebook use these days is a long way away from PHP. Hack is quite different in various non-trivial ways.

The more typical "99th percentile" PHP is not used by any of the biggest tech companies to deliver their core products.

<comment><USER5> > _Hack is quite different in various non-trivial ways_

[citation needed]. In what non-trivial ways is Hack different to PHP?

Of the three distinguishing features highlighted on [https://hacklang.org/](https://hacklang.org/), PHP has two (the exception is generics, which I don't think PHP has added... yet).

<comment><USER6> Hack has async.

</comment></comment></comment></comment></comment><comment><USER7> It didn't, it's the backbone of a lot of enterprise companies and organizations that aren't primarily focused on tech. Like most of the European public sector.

Coincidentally, companies that aren't tech companies rarely share their tech stacks, because why would they? Technology isn't what they are selling and IT people are the guys who tell you to reboot every time you call them, even if that's not really true.

Take the municipality where I work as an example. I manage several software developers, and we've build around 400 minor systems and services over the past decade. Last year when I was working on my masters in public administration I discussed our in-house development with one our eight CEOs. This is the guy in charge of efficiency, which is where my digitization department resides, and while he knows me and what my department does in general terms, he was surprised to learn that we develop software ourselves.

It's different for Netflix and Airbnb, because they are tech companies and I'm fairly certain their CEOs know that they employ actual software developers. ;)

That's the public sector, but look up Volkswagen, Maersk or similar and notice how they don't have entries?

</comment><comment><USER8> It's the licensing. It's always been the licensing. The cost is untenable for startups (and yes I'm aware of the various bizspark and developer offerings). Those special deals are awesome in the beginning but they have nasty teeth when you're two years in and you've just started to get traction and out of the blue you need to pony up for sql server or windows licenses.

<comment><USER9> SQL Server/Windows Licenses costs shouldn't really be a problem if you've factor them into your business plan and expenses. The businesses that get into trouble are the ones that naively assume software is free.

<comment><USER10> SQL Server and Windows licensing are actually major inhibitors, even at large enterprises. We have to manage our VL/CALs conservatively to control costs.

Wanna spin up n VMs for production / distributed computing? For Windows, you have to license each VM, whereas with Linux, the incremental cost of another node is nearly 0.

(Side note: I had high hopes for container support on Windows Server 2016 because unlike OS's, containers don't require individual licensing. Unfortunately Windows Containers are still immature, and are ironically second-class citizens in the Microsoft ecosystem compared to Linux containers)

Wanna spin up a n database servers? A single SQL Server (Enterprise) instance is pretty pricey (and it's licensed per core, minimum 4), whereas Postgres is free for any number of users and any number of processor cores. You want several replicas of your SQL Server? It is $$$. With MySQL, every replica is free license-wise (there are other costs of course).

The cloud has changed these calculations somewhat, but if your infrastructure is on-prem, Microsoft licensing can be prohibitive at scale.

<comment><USER11> Do not forget — Microsoft licence costs also increase with the number of CPU cores in your server.

In addition to costs themselves, Microsoft licensing is a highly complex topic. One of my colleagues who deals with Microsoft jokes that someone well versed with MS licensing deserves a PhD. A lot of people simply don't want to deal with all that when they have a thousand other things to worry about.

<comment><USER12> And because of the cost the accountants demand tight centralised control, which ends up being slow and unresponsive, and you find yourself spinning (emailing, writing business cases, managing and reporting expenditure) instead of doing. It is a huge negative.

<comment><USER11> The horror! Fill gazillions of forms in triplicate and get them approved before we'd let you do anything useful.

</comment></comment></comment></comment></comment></comment><comment><USER13> If one could bet money & not just time/effort/knowledge on tech stacks, Microsoft's would be a great discount right now.

They've been employing large amounts of very well known devs to become dev advocates in every popular language/field out there.

Visual Studio Code has overtaken Sublime & Atom as the most popular text editor in just about any demo I see in most front side web development.

MS is now friends & compatible with many of the other cool tools out there. MySQL, PostgreSQL, Linux, etc. A lot of demos I see use .NET with PostgreSQL on Linux.

If you've never used Visual Studio's Full IDE or Azure or the .NET framework, you're missing out on some huge productivity gains. I use JavaScript more than .NET. I'm better at JS than .NET by far. I really dig hosts like Netlify. That said, if I need to spin up a MVP for a project, it's faster, better quality & easier with VS, Azure & .NET for me at least. Startups really underestimate this one I think.

From what I've heard, it's also a great platform with Xamarin for mobile, with Unity for Games, etc. Add on the experimental work going on with compiling to Web Assembly & the .NET framework has a great chance to be running anywhere & everywhere.

<comment><USER14> > If you've never used Visual Studio's Full IDE or ... you're missing out on > some huge productivity gains.

I've yet to see anything standard Visual Studio does better than Netbeans or JetBrains tools (besides language specific things) but I am yet again willing to be enlightened if someone can explain it to me.

Background: I have months of experience with Visual Studio (more if you count back to school), months on IntelliJ and years on eclipse and Netbeans.

<comment><USER15> Visual Studio / C++ 6.0 (from 1998!) was by far the best C++ environment at least until 2013 came out (The last version I used was VS2012) - You never had to wait for it even in 2000, when I first used it, and definitely not later.

VS2005 (or 2008? can't remember), which I had to switch to because for x64 work, was unbearably slow and unresponsive in comparison -- although the general standards of responsiveness have come down, so today it might not be so bad (see, e.g., Atom, VSCode, everything JetBrains compared to old-guard Sublime)

From my only-slightly-nostalgia-tinted experience, I would correct GP's post to say "If you've never used VC++6 full ide" ...

<comment><USER13> I didn't want to comment on the others because it's been years since I've used Eclipse or JetBrain's IDEs. They were sluggish back in the day but so was Visual Studio. They made me jump to Sublime.

The latest release of Visual Studio has performed very well for me as long as I avoid ReSharper (somewhat ironic). Fortunately they've included a lot of those features in the professional & enterprise versions.

</comment></comment></comment></comment><comment><USER16> My company sells dev tools to software companies. Whenever I have talked to a startup about their tech stack and they reveal they're on .NET, I later find out that none of the founders are technical, and they've outsourced development to Eastern Europe or India.

This is not to say that a startup founded by technical people couldn't be successful using .NET; I just haven't seen it.

<comment><USER17> Is that...bad? I mean, the point of a startup is to start a business, not to write code, isn't it?

I'd bet that there are many startups that don't need technical founders, and many who have them are building technology that isn't really differentiated. One thing that is important is obviously fine-grained control over the business, so I could see how outsourcing might make that slightly harder to manage.

<comment><USER18> Not only fine-grained control, but as they grow they need to consider the cost of growing and maintaining a system built with antiquated tech.

<comment><USER19> Do you mean with antiquated? That the APIs aren't changing on a weekly basis and you can concentrate on developing instead of updating your code?

</comment></comment></comment></comment><comment><USER20> .NET is fine. Visual Studio is the de-facto IDE.

Microsoft's problem has always been Windows. Software made for "A PC on every desk" doesn't fit so well into a wall of servers running the internet. They should have gave away Windows Server for free. Heck they should do it now. It should be as free as .net core.

<comment><USER21> Why would they give away a product that creates a substantial part of their revenue?

<comment><USER20> Why install an Exchange server when I can use Office 365? Even Microsoft is cannibalizing their server offerings. Everybody is moving that stuff off prem. Windows server licensing doesn't make sense off prem.

<comment><USER21> _Everybody is moving that stuff off prem._

Even if that does happen we are nowhere near it yet, there are a lot of servers out in corporate offices and will be for the foreseeable future. If this wasn't the case then Microsoft wouldn't be releasing new versions of Windows Server.

<comment><USER20> I agree we aren't there yet, but I could see maybe a new sku? Windows Cloud Server or something similar. Windows Nano Server supposedly fits this bill, but businesses are going to want the real deal, not the stripped down nano version.

</comment></comment></comment></comment></comment><comment><USER22> .NET is demonstrably a great environment (judging by effectiveness) and licensing is hardly an issue since .NET core. So it must be partly cultural. First of all, unless you have macbooks, you're not really a startup. and if you're a new developer who needs to pad out the CV, naturally you will be attracted to the most buzzwordy tech stack available - if it isn't dockerised scala->graphql->redis->whatever so you can code while you code, nobody's gonna hire you afterwards man.

Also that awkward, sad reaction when you reveal to other burgeoning developers that you work in .NET

</comment><comment><USER23> In 2008, I looked at where the market was going and decided to tie my horse to Microsoft, .Net and enterprise development. It's been a good ride, but it's clear that JS is eating the world. I'm slowly moving over more toward JS and Linux. I am taking a brief detour to Python and AWS though.

I'm not touching Ruby. There are jobs for it but they don't pay well.

<comment><USER24> > I'm not touching Ruby though. There are jobs for it but they don't pay well.

Source? I know I'm an N of 1, but I just got hired to work on a Rails app and the pay and other benefits are pretty competitive...

<comment><USER25> To add to your sample set, I'm a rails developer and also get paid handsomely. My salary is higher than it would be for a C# or Java dev of the same experience. There's a shortage of rails developers in my area I think, but plenty of C# and Java devs.

<comment><USER24> I think that Ruby has lost its "cool" factor whereas .NET is back on the rise due to the release of .NET Core and TypeScript, so a lot of people have moved away from Ruby which leaves those of us who still have an interest in it to fill in the gaps.

It also seems like every year we hear that "Rails is dying", but I don't think I've seen those claims materialize. It's maybe not as popular as it was 5 years ago, but I'm not hearing any death knells.

<comment><USER23> Not saying anything about Ruby in particular but you never want to skate away from the puck unless you're near retirement and want to make some quick bucks - like people still writing COBOL.

</comment></comment></comment></comment></comment><comment><USER26> I am sure if the website included majority of fortune 500 companies, then .NET usage would reflect favorably (it still won't overtake java but it would be up there).

There is a place for technologies and associated stacks where the demand exists. The whole .NET and Microsoft ecosystem is super useful for large enterprises who have plethora of data and somehow need to accommodate employees who are both IT and non IT (think of typical IT Business Analysts and scrum masters and product owners -- they are usually involved with microsoft-based tools as I find it).

</comment><comment><USER27> When people say "Oh but now Visual Studio is free for small scale use, .NET core is officially supported on linux" etc. I really just have to ask one question:

So what?

This whole conversation somehow reminds me of the old iPhone vs Android conversations about 5-6 years ago when Android phones started catching up on iPhone in features such as non-lagginess etc. and people were like "So now Android has it too and you have no more excuses not to change to Android now!"

Well...hahah...it doesn't really work that way. Even if Android could do everything that iPhone could...why would I still change? Why would I see all that trouble just to gain _NOTHING_. It's same with MS tech stack. Why would I change from tools I know and trust to MS stack when it would take time and money, but I wouldn't get anything?

In addition MS has been fucking over people for about two decades and just because they have been seemingly friendly for last few years why would I trust them?

Also if one were a software engineer, more or less experienced, and was thinking what tools to use, what do you think? Would he pick the tools used by top engineers and tech companies or embarrasing enterprise tools designed for senile bankers and municipality sinecures who are afraid of tech and want to use tools made by big company they have been repeatedly told since 1980s?

</comment><comment><USER28> I don't think the MS stack is going anywhere. It's true that startups tend to avoid MS due to the (real or perceived) high upfront costs and its general lowness on the hipster curve, but once you look outside of SF/Bay Area it normalizes out, and you'll find plenty of .NET/C# jobs at tech/software companies in whatever city.

<comment><USER29> Now that .NET Core exists, it is possible to develop on the .NET stack without licensing fees (By hosting on Linux and using an open source database) or using a third party implementation (Mono).

It remains to be seen whether this will help it gain traction with more companies or not though.

<comment><USER30> Yeah but why bother? Unless you have some legacy code and are forced to use c# I wouldn't waste my time anything Microsoft.

</comment></comment></comment><comment><USER31> There's an overwhelming majority of developers who recently majored in CompSci or went to Bootcamps that have never touched a Microsoft development ecosystem, let alone Windows before. Schools/Camps are mostly teaching Python, JavaScript, or Java although that's starting to change now with .NET Core being open-source and cross platform and being one of the fastest frameworks out there on TechEmPower Benchmarks.

I founded a startup on the Microsoft tech stack (.NET Core, VSTS, and Azure). Why? It's an incredibly productive dev/tooling environment that Java/Python/AWS doesn't even come close to. The downside? It's really hard to find good C# talent that isn't stuck in an enterprise development mindset.

<comment><USER32> The flipside is also true; as a C# / MS stack focused developer myself, it's quite difficult to find satisfying work that isn't enterprisey, and it seems to be mostly because Microsoft isn't Cool.

<comment><USER23> The only thing "cool about a company is that they deposit money into my account every two weeks. I don't look for "cool" jobs.

<comment><USER12> Do you like your work boring?

<comment><USER23> After developing professionally for over 20 years and as a hobbyist for 10 years before that, there is nothing "exciting" about software development. I don't hate my job or my career by any means, but at the end of the day, it just funds my lifestyle.

<comment><USER12> That's fine, but plenty of us choose to work on systems we find intrinsically interesting and/or on problems we consider important. Sometimes that comes with a financial penalty. Personally, I'm happy to get slightly less money in exchange for more interesting and meaningful work.

</comment></comment></comment></comment></comment></comment><comment><USER33> Microsoft is doing their darnedest to own JavaScript as a language. TypeScript + VSCode is making inroads.

</comment><comment><USER34> It's weird that the author would include Shopify in a list of companies that don't create their own tools.

Shopify is one of the most prolific technology creators in the tech community. Their CEO was on the original core Rails team and is directly responsible for several common libraries and concepts that have been picked up by other tools.

<comment><USER35> Netflix too. Fairly certain they develop a fair amount of their own stuff in house.

</comment></comment><comment><USER36> I've been developing with .NET since 1.1. The initial appeal of ASP.NET WebForms was due to the fact that you could build software similarly to the way you build Windows desktop based apps. State was managed in an unmanaged environment. You didn't have to worry about varying browser capabilities / quirks due to the lack of standardisation at the time.

Fast forward a few years and all of a sudden you have browser standards and amazing MVVM frameworks. Everything you needed ASP.NET for was no longer required.

I still work on enterprise .NET systems and it's no surprise as to why startups look to alternatives. Sure the tooling is amazing but so are many of the other tools out there. After using simple web frameworks like AdonisJS I see no real reason for building your service layer (let alone your app layer) in .NET.

</comment><comment><USER37> I'm not sure why the author is surprised about Ruby. Rails was the darling of startups for years and is probably still a common choice of backend.

This data is also rife with bias: stackshare isn't representative of startups let alone companies in general.

<comment><USER35> Also, Ruby has Jekyll which is probably close behind Wordpress (php) in terms of usage by blog/ecommerce.

</comment></comment><comment><USER38> More damning to me is that the stack components in a couple examples that aren't languages, such as databases (MySQL, Postgres, Mongo, Cassandra, Elasticsearch, etc), cache fabrics (Redis, memcached), tooling (Chef, Puppet, etc), data pipelines (Hadoop, ELK, etc)...

None of it is written in .NET except for interface drivers. Java, the butt of all jokes, is responsible for a number of the key stack components, and C++ might not be a lingua franca of the startups, but foundational components are written in it.

Can someone name a major OSS project/tool/database/etc that is written in C#?

</comment><comment><USER39> I think a lot of it is that there just aren't as many developers that know it compared to the other tech stacks.

Part of the reason for that is that if you're starting out as a web developer trying to build stuff for fun, you're probably not picking .NET as your tech stack when there are options that are freer (both as in beer and in speech), easier/cheaper to deploy, and have a more active online community that can help you if you get stuck.

And ultimately, if you're a company that is picking a tech stack, you ultimately need to hire people to work with that stack, and it's a lot easier to find people that know Node/PHP/React/whatever than it is to find people that know .NET.

</comment><comment><USER40> .Net Core is fully supported on Red Hat Linux.

If it gains serious traction, that could change the development landscape for a fair chunk of Enterprise development.

</comment><comment><USER41> Why are Javascript and Node.js different here? Especially considering this is back-end only. Who is using Javascript on the server without Node.js and how? I think they should probably be combined and if so, you would see absolute dominance by Node.js

</comment><comment><USER42> C++ is alive and well at all those companies, yet the bar chart shows zero. This immediately makes the rest of this "data" suspect.

<comment><USER43> You were downvoted pretty quickly, but I agree with what you're saying: I don't trust this data. Out of curiousity, I searched up Apple. Of course I got Xcode, Swift, and Cocoa…but not much else. No mention of the hundreds of technologies Apple uses to keep its services (Maps, Siri, iCloud) running, no mention of even _Objective-C_ , which probably outnumbers lines of Swift code ten to one. It seems like this website is just a collection of public perception about companies' tech stacks rather than being an accurate source.

<comment><USER44> Not sure if you need to work at a company before you can submit the data, but it also seems like this scans the website and GitHub repos you give it to identify the stacks.

This seems like a bad source. Specially if anyone can submit a company they don't work for and only use the url scan feature.

</comment></comment></comment><comment><USER45> As a Microsoft and all the closed-source software hater, I feel reassured

<comment><USER46> I understand the hate on Microsoft given the recent abominations they produce (Windows 10, "improved" version of Skype, etc) but why the hate on closed- source software in general? People need to eat too.</comment></comment>


Denmark tackles youth unemployment with university cuts - <AUTHOR> http://www.west-info.eu/denmark-tackles-youth-unemployment-with-university-cuts/ I thought it was interesting with this discussion in mind: https://news.ycombinator.com/item?id=8394136
As other countries have shown some socialist movements in recent years (Obamacare, weed legalization, Germany making universities free etc), we in Denmark, praised for equality and happiness, are tightening the screw. We are not studying for knowledge anymore, but for profits.
Though I am Danish, I am not trying to complain or be overly emotional. It just seems very interesting that we're all, globally, moving towards the middle.
Yes, I am painting with _very_ broad strokes. Pressed for time to find more evidence. Will update. <comment><AUTHOR> I thought it was interesting with this discussion in mind: [https://news.ycombinator.com/item?id=8394136](https://news.ycombinator.com/item?id=8394136)

As other countries have shown some socialist movements in recent years (Obamacare, weed legalization, Germany making universities free etc), we in Denmark, praised for equality and happiness, are tightening the screw. We are not studying for knowledge anymore, but for profits.

Though I am Danish, I am not trying to complain or be overly emotional. It just seems very interesting that we're all, globally, moving towards the middle.

Yes, I am painting with _very_ broad strokes.

<comment><USER2> At some point in time the University stopped being the place to gain knowledge and instead became a trade school to gain a job. It's a reflection of society's values: money and the things it buys is more important than knowledge. Maybe it always was and we were just kidding ourselves thinking we ever really valued knowledge. Anyway this will be interesting to see how it plays out.

<comment><AUTHOR> It just seems strange to me that despite swaths of evidence, people in position of power _still_ think in short terms.

Though we all agree computer science is very important these days, who can deny the societal importance of philosophy, psychology etc despite the job market being narrower. Even fringe studies such as eskimology (the study of Eskimo's, and yes, you can study that in DK) will certainly have value in some way or another, same as going to the moon.

Knowledge for knowledge's sake is important _exactly_ because we _don 't_ know it's importance or value.

<comment><USER3> "It just seems strange to me that despite swaths of evidence, people in position of power _still_ think in short terms."

Are you kidding me? There's an election every four years and under the current government there's been umpteen reshuffles. Politicians have to respond to incentives, I mean opinion polls.

As a fellow Dane I am not surprised at all that our politicians, many of whom are only partway through (the same) degree when they are elected, would take the short view of things.

<comment><USER4> Does that mean the inability to think for the long term is a fundamental limitation of modern democracies?

<comment><USER3> Well, I don't know if it's fundamental. I hope not. Perhaps you could change the constitution somehow. You could mess with term lengths or limit someone's tenure.

Or you could have a part time parliament like in Switzerland. That way the politicians need normal jobs and are not dependent on the voters for a livelihood.

The question is, once you have the current system, how are you going to get the incumbents to vote themselves out of work?

</comment></comment></comment></comment></comment></comment><comment><USER5> Doesn't supply and demand dictate that keeping population constant and limiting career options will lead to an increase in supply in the still available career paths? This will either be met by a decline in real wages or, if real wages can't adapt due to regulations, an increase in unemployment in those fields?

This seems a lot like trying to cure a symptom without understanding the actual sickness.

</comment><comment><USER6> I am for people choosing whatever major they want and taking on as much debt as they feel comfortable. However, that freedom comes with the responsibility of dealing with the job prospects attached to that major and the financial burden of repaying those student loans.

Many students seem to think they should be able to choose a major with poor job prospects, take on a lot of debt, and then complain to government and society to fix their unemployment and debt woes. Well, this kind of policy is what that leads to. If people want the government to insure they have a job and absolve them of their debt, they should be prepared for a world where the government also dictates what they can study.

<comment><USER7> That is exactly the problem.

There is a generation of young people who grew up believing that education is a right rather a privilege and are now complaining that they spent all this time educating themselves and now there are no jobs.

You would be surprised how much airtime this kind of entitlement gets in the press in Denmark.

The sad truth is that education isn't what it used to be because educating one-self in a world where new information is added in ever increasing quantity is a never ending process. And so if you only think you need to really learn and study when you are at the university you couldn't be more wrong it starts in your childhood.

This unfortunately is lost on most.

<comment><USER8> You know, those students didn't get that idea out of thin air...

</comment></comment></comment><comment><USER9> So the 15000 students will be forced to join the courses in demand and that will dry up due to increased supply. Then what? Will they keep moving courses around every year? What happens to the teaching faculty for some course that goes away and comes back?

<comment><USER7> Denmark have had a longstanding issue with too many students choosing humanistic fields and going straight out to unemployment.

It's a welcome decision.

<comment><USER10> It is at least a perceived longstanding issue, how large a problem is it really? How large an economic impact does it have? I suspect that the government did not actually investigate those factors.

Denmark's unemployment rate stands well below the EU average, better than Finland, France, Estonia, Belgium, and comparable to the Czech Republic.

Fixing possible non-problems with solutions that may have long-term negative consequences is usually bad policy. No one knows what the future of employment is going to look like.

<comment><USER7> It's not a non-problem its a big problem especially in a country where education is free.

Unemployment is low because the public sector is huge and take a lot of those people in. But a smaller and smaller percentage of the population pays for that and so they can't continue growing it. This is the main reason why they are cutting down.

With some of the highest taxes in the world and also free health care plus very liberal social welfare model this is unsustainable.

And you could might as well turn it around. How big a problem is it really that they minimize their approval of humanistic applicants.

Denmark is doing bad when it comes to building companies. It's very easy to start a company but growing it is extremely difficult and not financially as rewarding. They need more people to start doing stuff not just getting hired.

And then we haven't even touched on the more fundamental issue with the way Denmark thought and still think about education.

<comment><USER10> Sounds like a lot of vague arm-waving to me. How is Denmark's government debt to GDP ratio? Private debt to GDP ratio? Employment rate? Workforce participation rate? Economic growth?

How do all those things compare to its peer group? You can't look at Norway's petro-fuelled prosperity and decide they have the answers for you, look at nations with similar economic structures.

What evidence is there of _actually_ unsustainable things in the economic model of Denmark? Where are the symptoms?

Legatum's prosperity ratings have Denmark at #6 in the world overall and one of the lowest in business startup costs _in the world_. (#2 in the world in the entrepreneurship and opportunity category!) By every objective measure it seems like a wonderful place to start a business!

<comment><USER7> Arm-waving?

I am from Denmark. are you? I had a company in Denmark with 70 people did you?

If you are really interested in answers to your own questions may I suggest you get educated on the matter before you decide to make any haste judgment on what I am telling you.

<comment><AUTHOR> That is a poor appeal to your own authority. Thom, I'm Danish and entirely disagree with pretty much everything you've said in this thread regarding analysis and solutions, and I'm really sad that you discuss as if your words are gospel.

Buzz phrases like "... it's unsustainable!" really don't belong here. They're impossible to argue for or against as the data is really clouded.

<comment><USER7> Compared to who I was discussing with i HAVE authority.

Fine that you disagree now make your case.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> From what I further read about this issue, was that in south denmark, more directly "University of Southern Denmark" was being cut by up to 50% in some courses, but the unemployment in that area only being about 5-10%.

What I don't understand is that the danish government didn't plan the cutdown with any specialists or people already working with the problem.

<comment><USER7> I am not sure what you mean. Danish government is cutting down primarily in the humanistic fields around 4000 chairs all in all. A lot of people who live in Copenhagen go to "University of Southern Denmark" it's not so important where it happens.

Denmark have way too many people in the humanistic field and they are rightfully cutting that down.

Also keep in mind. Education is 100% free plus you get subsidized when you take education.

<comment><USER11> I just think theirs a higher chance that you'll stay in the area where you took your education. so in that regard some areas might go short on workforce in a few years.

Apart from that you are all right. I get "paid" for studying, which of course comes at the cost of my earning being cut in half or well less for the rest of my life, do I decide to work in Denmark.

I think and have thought for a long time that you should lend the money instead, so that you won't have any people just studying to "leech". But maybe that's a discussing for elsewhere.

<comment><USER7> Everyone is moving to Copenhagen. Denmark is a small country. Even people who live in southern Denmark work in Copenhagen the drive is 1-2 hours max

I actually left for the US but I am more or less autodidact so I didn't leech :)

<comment><USER11> You are right that Denmark is a small country, I've been to USA too, and I talked to a lot of people working in cities 2-3 hours drive away. So by that yes.

However, and I might be somewhat wrong, but I've seen more people beginning to crowd around either Odense, Aarhus or Aalborg the last few years. This is however my own observation from students who finished their education that I've run into.

<comment><USER7> Yeah the bigger cities not just Copenhagen. But it doesn't change the fact that location isn't that big of a deal.

</comment></comment></comment></comment></comment></comment><comment><USER12> In Scandinavia, the universities are generally almost 100% tax-funded, so one might say it's right for the government to demand a higher "Return Of Investment". Surely there could also be private tuition-funded universities and/or tuition-funded programs in public universities for those who can and want to finance a decree in a purely humanistic field.</comment>


How the jet stream is changing your weather - <AUTHOR> https://www.ft.com/content/591395fe-b761-11e9-96bd-8e884d3ea203 <comment><AUTHOR> > The impact of the jet stream on climate change, and whether it will shift in > the future, is hotly debated by scientists. It is seen as one of the central > issues that will determine how weather patterns across western Europe, in > particular, will shift as the planet heats up.

> "This is a critically important part of climate science, and one of the > least well understood," says Prof Williams. "We know the climate is getting > warmer, and this is settled by now, but it is the consequences of that > warming — like the jet stream — that we are just starting to explore."

> "We think the rapidly warming Arctic is making these wavy patterns happen > more often, and as a result we are seeing weather patterns themselves become > much more persistent," she [ Jennifer Francis, senior scientist at Woods > Hole Research Centre] adds, meaning that weather such as heat or storms can > be trapped in place for longer.

> Other scientists predict the opposite could happen: climate change could > cause the jet stream to get stronger and move toward the poles. Atmospheric > models — the complex simulations that run on supercomputers and forecast > long-term weather and climate — tend to support this view.</comment>


ISIS has an annual report, with an infographic [pdf] - <AUTHOR> http://www.understandingwar.org/sites/default/files/ISWBackgrounder_ISIS_Annual_Reports_0.pdf <comment><USER2> Well, if downloading this doesn't get us all on a government watchlist then I don't know what will.

<comment><USER3> This isn't the actual IS report though, it's a report by the Institute for the Study of War on the IS report.</comment></comment>


Honey Game Engine Tutorial – v0.01 – Windows and Libraries - <AUTHOR> http://www.friendsonmountains.com/blog/2018/06/30/lets-make-honey-version-0-01-windows-and-libraries/ <comment><AUTHOR> Ayo! I'm making a game engine and writing a tutorial about it!

In the second post, I'm making Honey into a library and using the SDL to make a window. Simple stuff, still very early in the process.</comment>


A different approach to building DOM - <AUTHOR> http://www.andrewluetgers.com/2012/12/04/loot-js-dom/

<comment><USER2> The earliest templating in this style I'm familiar with is FlyDOM. I made a variant SuperFlyDOM. HAML was around and HAML-JSON was not far off, IBM's JXON, jQuery's DOM creation object shorthand... probably more exist.

It makes a lot of sense compared to the antiquated longhand and inflexibility of XML element declaration. Templating in the browser has been done to death and usually string concatenation is the fastest. However, JS frameworks like Enyo/WebOS and Titanium Mobile use JS element creation, so having a shorthand for those is not significantly slower.

HAML is nice because it removes the computer cruft of braces and brackets, but building JS objects with CoffeeScript is just as quick. IMHO the only reason not to use the actual language is so that less technical UI devs can build the templates.

<comment><AUTHOR> totally agree, thanks for listing some of the other similar approaches

</comment></comment><comment><USER3> Yep I've run into that same frustration with templating too. I expressed it as:

"Templating languages are pretty cool because you get to use a declarative language to make some DOM elements. But they either don't give you the full expressiveness of a decent functional language, or they do and it's a bunch of arbitrary stuff stuck in some ugly tags - which I am still way too lazy to learn, when I already have a decent functional language (JavaScript)."

My solution is about the same - <https://github.com/pidge/h></comment>


Lol You Have a Zune - <AUTHOR> http://sondry.com/posts/LOLYouHaveaZune-2Kdbn-02-21-2014

<comment><USER2> whats going on with the layout of that article?!</comment>