"Perfection is Achieved Not When There Is Nothing More to Add, But When There Is Nothing Left to Take Away"
With the specter of 1.0 approaching, it seems everyone is keen on squeezing their favorite feature in, but it seems to me that one would perhaps be better served by removing any and all failed experiments and bad ideas first - so here's a thread celebrating the cancers that should, with the benefit of hindsight, not have seen the light of day and that still can be removed nice and cheap (you can be sure it's cheaper now than it will be later, tutorials, stackoverflow and books notwithstanding)! Even half-baked ones are cheaper to remove and readd than to keep and remove later - that gut feeling is right and you'll end up not readding them anyway - when writing the following post 5 years from now, do you really want it to be full of things you knew about but didn't act upon? [http://www.informit.com/articles/article.aspx?p=2425867](http://www.informit.com/articles/article.aspx?p=2425867) I've started the party with [https://github.com/nim-lang/Nim/pull/7669](https://github.com/nim-lang/Nim/pull/7669) \- the dead code elimination _option_ is indisputably useless. Here are a few more, just to get the discussion going * bitsets - why are these even in the language and not a library? * exceptions - this dinosaur leftover from the dark ages introduces all kinds of hidden costs and after decades of trials and experience, gets the downvote * reasoning cost - you totally lose the ability to reason about what the code will do, because critical information is hidden and execution may break off at any time * api/abi cost - when the errors change, the api doesn't so if a library you're using changes, the compiler can't help you * performance cost - error handling (always) has a cost but this is not reflected in the code you write * the most loved language doesn't have them ([https://insights.stackoverflow.com/survey/2018/#most-loved-dreaded-and-wanted)](https://insights.stackoverflow.com/survey/2018/#most-loved-dreaded-and-wanted\)), so it's safe to say they're useless for love * languages that have them (C++!) are scrambling to get rid of them (specifiers deprecated, better options being introduced, like [https://github.com/viboes/std-make/blob/master/doc/proposal/expected/p0323r3.pdf](https://github.com/viboes/std-make/blob/master/doc/proposal/expected/p0323r3.pdf)) * the stalwart of reliability, Erlang, shuns them * here's a nice post on error handling that Araq pointed me to at some point: [http://joeduffyblog.com/2016/02/07/the-error-model/#retrospective-and-conclusions](http://joeduffyblog.com/2016/02/07/the-error-model/#retrospective-and-conclusions) \- no love for exceptions there either.. * a huge standard library - the library is arguably one of nim:s weakest points with lots of inconsistency and poorly maintained parts - cutting it down to a bare minimum would: * free up time to maintain the core parts better * incentivise spending time on making nimble work (well) through dogfooding * provide an upgrade path from bad ideas * provide a playground and staging area for things that _could_ or _should_ actually be in the core library - moving them in there only when they passed the tests of time and quality * manually formatted code - it's 2018 and programs can format code and optimize it for human reading better than humans - no one cares what the format is really, as long as it's consistent What else would you kill off?
