Show HN: Paths.js – Generate SVG paths for geometric shapes - <AUTHOR> https://github.com/andreaferretti/paths-js <comment><USER2> Looks nice, but I would really prefer the samples on the sample-site to be in plain Javascript.

Coffescript isn't for everyone, on the web Javascript should be considered the lingua franca.

By all means, keep the Coffescript if you like, just don't limit it to _just_ a non-standard language web-wise. I can test JS in my browser, with coffescript... Not so much.

<comment><USER3> All of the example code appears to be JS?

<comment><USER4> Parent is referring to the "demo application", though I personally disagree that one should worry about it on the demo app. The docs sure, but the demo app is readable enough even if you're not a coffeescript aficionado.

</comment></comment></comment><comment><USER5> Inexplicable hostility towards this post. It's quite a handy library.

</comment><comment><USER6> Your documentation needs images (or, you know, actual SVG).

<comment><AUTHOR> Hi, you can find a working demo on

[http://andreaferretti.github.io/paths-js- demo/](http://andreaferretti.github.io/paths-js-demo/)

It is mentioned in the README (How does it look like?) but maybe it is not apparent enough

<comment><USER7> I reccomend changing the title of that section to either "How does it look?" or "What does it look like?"

"How does it look like" is a minor but grating error to native english speakers.

The rest of the document looks good, as does the library.

<comment><USER8> Interestingly, I've been hearing a lot of native speakers making the same mistake lately. Maybe it's because I live in San Francisco, and we hear foreigners make this mistake all-day-long - now it's rubbing off on people.

</comment></comment></comment></comment><comment><USER9> Hm.

I just recently wrote something that does the lowest layer of this (generating SVG path strings) and didn't consider it "Show HN" worthy... [https://github.com/akx/gravelly.js](https://github.com/akx/gravelly.js)

(And no, this isn't an attempt at an underhanded sneaky "Show HN", just a thought.)

</comment><comment><USER10> Any core differences between Path.js and D3?

<comment><AUTHOR> Well, there are a few. The main one is that Paths.js only builds a descriptor of your path (the string that goes into the "d" attribute of the SVG path tag), and leaves to you the actual rendering. This has, for me, a few benefits:

\- it is easier to integrate into frameworks like React or Angular (because both these frameworks and D3 think they have control on what goes rendered in the page)

\- you can use templating, which leads to a declarative approach, instead of the imperative approach of D3

\- it only involves pure functions (no side effects) which makes it easier to unit test your graphics

\- not doing the rendering means you can use Paths.js also on Node

Of course, D3 is more mature and complete at this point, and it is easier to find examples and documentation. I hope eventually to fill the gap, at least partially.

Another difference, although minor, is that D3 includes a lot of utilities (parsing CSV, doing Ajax requests, working with dates and much more...). This may be a benefit for you or not. I prefer to have small building blocks, and Paths.js is only concerned with generating paths.

<comment><USER10> Thanks! make sense. I have observed that lot of JS based SVG libraries having memory leaks and slowing down browser over the time, how paths.js behaves in this context?

<comment><AUTHOR> Well, I certainly hope Paths.js does not have memory leaks. Since it is made of functions without side effect, with the ultimate purpose of producing a string, every intermediate result should be eventually collected.

SVG itself is certainly not the fastest technology around, considering that the browser has to adjust the layout of the HTML and SVG together. Still it seems to work just fine for a few charts.

The only exception to the above is the Graph chart. That one is currently hideously slow, and one of the tasks for release 0.4 is to optimize it. The algorithm does not look too bad to me, but probably I am producing a lot of intermediate garbage which slows down the whole animation. I will have to look into some form of object pooling.

</comment></comment></comment></comment><comment><USER11> This is a brilliantly conceived library. It does one thing well and even within that, decomposes into clear layers of abstraction. I've been using it at work and found the experience much nicer than the various high-level charting libs built on top of d3.

There's a nice example of using it with a declarative templating library like react or ractive.js here: [http://mlarocca.github.io/01-22-2014/pathsjs_ractive.html](http://mlarocca.github.io/01-22-2014/pathsjs_ractive.html)

Only complaint is that some of the charts are a bit lacking in features (no stacked bar charts, for example). But it looks easy to hack on, which I'd take over a zillion different options.

</comment><comment><USER12> If this is viable for making dataviz, it will be a great relief to get away from D3's disorganized mishmash of data wrangling and dom manipulation code!

</comment><comment><USER13> This is OK, but it would be a lot more useful if the low level API used the standard names from CanvasPathMethods for compatibility with Canvas and Path2D: [http://html5index.org/Canvas%20-%20CanvasPathMethods.html](http://html5index.org/Canvas%20-%20CanvasPathMethods.html)

</comment><comment><USER14> So is the primary purpose of the library to save you from having to type "M 0 0 L 1 0 L 1 1", instead letting you type "Path().moveto(0, 0).lineto(1, 0).lineto(1, 1).print()"?

<comment><USER15> Consider, why do people use SQL query builders when you could just use a string?

<comment><USER2> Not sure you actually meant it as a question, but just to spell it, in case someone might actually consider it a genuine question.

SQL query builders can have the capability that they make queries _composable_.

Sending a string around will require you to do double and tripple check for parameters, logical combinations and what not in every step of a composable action.

Besides that, most SQL query composers assist you in isolating parameters from query, and this protects you from SQL injection.

</comment></comment></comment><comment><USER16> Hey, this is actually pretty useful. Thanks</comment>


Tesla Model III to challenge BMW 3 Series - <AUTHOR> http://www.autoexpress.co.uk/tesla/87867/tesla-model-iii-to-challenge-bmw-3-series-world-exclusive <comment><USER2> A $35,000 price (before presumed tax rebates) would really make this car a very much more main-stream vehicle rather than a "Luxury Car".

If they can pull off the whole charger network expansion thing, this will be Tesla's bread and butter car for a while.

<comment><USER3> This model will certainly allow Tesla to access a new and much larger group of potential customers, but I doubt it will be a "main-stream" vehicle. $35,000 is decidedly in the realm of high-end luxury cars (this car is still going to be far more expensive than the entry-level models from Mercedes, Audi and other prestige brands) and is still inaccessible to the vast majority of buyers, albeit not necessarily as exclusive Tesla's previous supercars.

Now, Tesla is no longer an "I need to be a millionaire" brand and instead an "I need to be a lawyer or engineer" brand.

Although this is a really exciting vehicle, I still think Tesla ultimately wants to target the proletariate with cars in the $18,000 to $22,00 range (possibly with a different brand to preserve the elite reputation of the Tesla name). That segment is far more lucrative than the limited luxury market for high-end cars. As soon as Tesla ships a car that can be afforded on an average income, things will really get interesting...

<comment><USER4> People shop on monthly payments. Say that gas is $5/gallon in three years (and I'm pretty sure that's conservative). For 1500 miles a month at 30 mpg, that's $250 a month in gas. Subtract that plus maintenance from your payment and you're getting into econobox territory. I think $35,000 will be a pretty big deal.

<comment><USER5> If you are going to consider the gas savings, you still need to remember that there are also electricity costs as well.

<comment><USER4> Yes, totally. Take off about $25 for the electricity. The numbers don't change too much.

</comment></comment></comment></comment></comment><comment><USER6> I thought for a minute that the site was an Onion-esque parody site considering the first couple paragraphs deal with how they tried to name their models after the word 'sex'.

<comment><USER7> Nope, that's just Elon for you.

Another example: the code name for SpaceX's future Mars launch vehicle is `BFR`.

aka, Big F*cking Rocket

<comment><USER8> And the test stand

BFTS the big fucking test stand.

<comment><USER9> And they said naming is hard.

</comment></comment></comment></comment><comment><USER10> _FYI, the Model 3 images used by @AutoExpress were mock-ups based on their own speculation._

[https://twitter.com/TeslaMotors/status/489200528908226561](https://twitter.com/TeslaMotors/status/489200528908226561)

<comment><USER11> I can't imagine that the real Model III would anything like this. I doubt that Tesla would make another car that looked so much like the Model S. I expect it to look far more distinctive.

</comment></comment><comment><USER12> Another step in the master plan:

 _Almost any new technology initially has high unit cost before it can be optimized and this is no less true for electric cars. The strategy of Tesla is to enter at the high end of the market, where customers are prepared to pay a premium, and then drive down market as fast as possible to higher unit volume and lower prices with each successive model.

Without giving away too much, I can say that the second model will be a sporty four door family car at roughly half the $89k price point of the Tesla Roadster and the third model will be even more affordable. In keeping with a fast growing technology company, all free cash flow is plowed back into R&D to drive down the costs and bring the follow on products to market as fast as possible. When someone buys the Tesla Roadster sports car, they are actually helping pay for development of the low cost family car._

[http://www.teslamotors.com/blog/secret-tesla-motors- master-p...](http://www.teslamotors.com/blog/secret-tesla-motors-master-plan- just-between-you-and-me)

</comment><comment><USER13> Tesla Motors twitter links to this, but what's going on with revealing the name and Roadster plans in some British car magazine?

<comment><USER14> The Model S was launched in the UK last month - given the number of marketing emails I'm now getting from them, they appear to be doing a big sales push here.

<comment><USER15> Then wouldn't this be them Osbourning themselves?

<comment><USER14> No. This car isn't targeted at the luxury market, and is 3yrs away.

</comment></comment></comment></comment><comment><USER16> I had a chance to drive a Model S down Mt. Evans in CO at an owner event. We need to buy a new car in August but have a hard time justifying the price of the Model S. We're looking at some fairly nice traditional vehicles (335xi, IS350, X3, Q5, etc) and it literally feels like we're buying obsolete technology. While other cars are advertising 9 speed transmissions I'm thinking why should I feel a car shifting? Why should the torque curve be non- instant and non-linear? Why should we ever go to gas stations?

In fact, I'm pretty tempted to just drive our oldest car into the ground and wait until the 3rd gen comes out as I can't imagine wanting anything else.

<comment><USER17> I was right there with you. Earlier this year, my high miles Camry started to have problems, and so I had to do something. I went with a new car that would be a good hand-me-down for my kids when they reach driving age, expecting some nice Telsa-like vehicles to be ready in a few years. This news fits nicely with that plan.

</comment></comment><comment><USER18> I'm keeping my fingers crossed for a 4-wheel-drive Tesla model for those of us who live where it snows copiously... but that price tag might be a game- changer regardless. That's going to open up a whole new demographic for them.

<comment><USER19> If it snows a lot, wouldn't you also have battery life problems because of the cold?

<comment><USER20> Gasoline cars have batteries that die in the cold too.

Which is one of the reasons you have to plug in a gas car in cold weather as well, the other being the oil freezing in the crankcase, a problem a Tesla doesn't have.

<comment><USER21> iirc the Tesla battery pack has liquid heating and cooling.

</comment></comment></comment></comment><comment><USER22> I surely hope Tesla will get this car to market on time. The timeline of 2016-2017 seems very aggressive given the Gigafactory has not even found a location let allow begun producing batteries. Elon has noted that a big issue with the "cheaper" Tesla was getting battery cost down aka building the factory to produce them at huge scale. Combine this with producing a more easily purchased vehicle due to lower price and I could see a battery shortage issue.

My second hope: that the Model III won't have a 3 month lead time like the Model S currently does.

</comment><comment><USER23> If it's going to be called "3", then 3 horizontal bars mimics the numeral as well as resembling the letter E enough to still allow the SEX joke/marketing/whatever.

<comment><USER24> That's what Musk said himself. I think it's pretty funny, if a little juvenile ;)

</comment></comment><comment><USER25> If the Tesla Model E was going to be sued by Ford for their E-Series vans, won't the the Tesla Model 3 get sued by BMW for their 3-Series cars?

<comment><USER26> No, it's Model "III" not Model "3" #wink.

</comment></comment><comment><USER27> I really hope they make a compact pickup for the industrial sector, Ford pulled out of that market with the Ranger.

</comment><comment><USER28> Jaguar also just announced a car for this category: [http://www.topgear.com/uk/car-news/jaguar-xe-small- saloon-20...](http://www.topgear.com/uk/car-news/jaguar-xe-small- saloon-2014-07-15)

<comment><USER29> I just can't get it up for any new car that isn't electric. ICE is just so broken. It's like CDs in age of digital downloads or new a PHP framework in age of sanity.

</comment></comment><comment><USER30> If you notice, III is 'E' rotated counterclockwise by 90 degrees - subtle but genius response to Ford's "hey Tesla, you cannot use Model E. If you do, we will sue you!"

<comment><USER31> Are you sure it's not rotated clockwise?

</comment></comment><comment><USER32> I don't know how many people own a 3 series here but as a person that owns one I feel that this title should be more about the fact that this competes with a Prius more than a 3 series. If it has $35k price point it makes it cost ~10k more than a stock Prius or the same price as a Prius with most of the options. It would cost about the same as if the $7,500 is extended, which I think will be extended. Helping Tesla allows speaks to both parties ideals. It helps the environment, is an example of the american dream and can be framed as a reason for cutting taxes.

<comment><USER33> They're comparing it to the 3 series because that's the market they're going after. They don't want it to be perceived as the latest eco-mobile but rather competitive with the "ultimate driving machine." It should have the performance, handling and quality of a premium sports sedan, not a econo box.

</comment></comment><comment><USER34> Missed opportunity to have another Model T, since that comes directly after S.

<comment><USER35> If Ford is suing them for Model E, they would undoubtedly sue them for Model T.

<comment><USER36> The Model T is over 100 years old now, surely Ford can't have a monopoly on a name that long right?

<comment><USER37> Trademarks don't expire as long as you keep using them - and you don't have to use them in necessarily very conspicuous ways (that's the reason all iMac boxes have "Think Different" in small lettering on the side[1]). I wouldn't be surprised if Ford still maintained the Model T trademark.

[1]: [http://en.wikipedia.org/wiki/Think_different#Product_packagi...](http://en.wikipedia.org/wiki/Think_different#Product_packaging)

<comment><USER38> And Ford actually sued another company in 2000 for trying to use the name "Model E":

[http://www.autonews.com/article/20130822/OEM04/130829966/tes...](http://www.autonews.com/article/20130822/OEM04/130829966/tesla- seeks-model-e-trademark#axzz2oeLNxWDG)

</comment></comment></comment></comment></comment><comment><USER39> It's entirely possible the naming decisions are being made by Musk himself. If they are not, I find this article an irritating exemplar of the CEO-centric view of the world that many articles -- and many CEOs -- seem to take. If they _are_ , well, that goes double.

<comment><USER40> Musk isn't _just_ a CEO. He's their Steve Jobs -- co-founder and visionary. He's chief product architect. And he's also the money. I think he deserves the right to have a CEO-centric view of his company.

</comment></comment><comment><USER41> What's the purpose in announcing this three years in advance?

</comment><comment><USER42> shut up and take my money

</comment><comment><USER43> Got to drive a Tesla last weekend. If this car is anything like the one I drove, even remotely close, Tesla wins. And I'm not even talking about the electronics panel.</comment>


Things I Enjoy in Rust: Error Handling - <AUTHOR> https://blog.jonstodle.com/things-i-enjoy-in-rust-error-handling/ <comment><USER2> It's interesting to see modern languages tackling checked error handling. Particularly in the light that Java's checked exceptions are widely considered to have been a failure. Yet I wonder if Java had better support for things like union types etc. if it would have turned out differently. After all, it did offer at least potential to achieve what everyone is after: you can write a piece of code and know for sure that you handled every possible type of error.

The most painful aspect of Java's (original) exceptions was how the only mechanism to handle multiple errors as a single case was using inheritance in the exception hierarchy. The result was that they propagated through interfaces and broke downstream code and it became pretty much impossible to design and maintain a stable API without wrapping exceptions excessively which in turn destroys the utility of the exception hierarchy, making the whole exercise futile.

The article seems a little superficial though. Immediately exiting with 'panic' does not seem like a real error handling approach for any realistic application. It doesn't show how you could handle different types of errors (eg: file not found vs I/O error reading file) with different cases. The case it does present is easily handled elegantly by nearly any error handling design.

<comment><USER3> I think the biggest problem with Java exception specs is that they're not composable. In other words, I can't define a method X that calls another method Y - potentially via dynamic dispatch - and has an exception specification of "whatever Y throws, plus E".

This manifests almost immediately. For example, suppose you wanted to implement a key/value database with disk storage. The logical core interface for it would be java.util.Map, except for the fact that its methods are declared as non-throwing; thus, you cannot propagate IOException from the underlying storage layer, unless you wrap it into unchecked RuntimeException.

Conversely, java.lang.Appendable is a very generic interface for appending characters or sequences of characters to something. But because its designers knew that _some_ of its implementations would be backed by I/O, all mutating methods in that interface are declared as throwing IOException. Thus, any generic code that tries to work with Appendable has to always assue that it can throw, and has to declare itself as throwing the same exception to propagate. And now the user of that generic code passes a no-throw implementation of Appendable to it, but still has to "handle" IOException that they know will never actually happen.

Or come up with some convoluted scheme, like java.util.Formatter does. This one wraps Appendable, but swallows all I/O exceptions to avoid having to propagate them in the most common case, where the wrapped Appendable is a StringBuilder. But since there are other possibilities, it still has to expose some API to examine such exceptions, which it does by providing a method on Formatter that returns the last swallowed exception that was thrown by Appendable. Of course, now you have to remember to actually check it, and you will silently get an incorrect result if you do not, which is worse than unchecked exceptions in the same scenario.

This all gets especially bad one you start working with HOFs, because their contracts are largely defined in terms of the behavior of functions that are passed to them. The old Java lambda proposal by Neal Gafter noted this, and proposed extending the syntax for generics to cover exception specifications (via union typing, indeed). In the end, they added UncheckedIOException to the standard library, specifically so that stuff like Stream.map() can be implemented on top of files, and propagate exceptions, without declaring them.

<comment><USER2> That is a very nice summary!

Some of these tensions seem unresolvable though. At some level if I want to toss a Map around everywhere and be able to transparently back it with a database, I'm going to have to accept that operations might fail. I can't have it both ways. In the end, the abstraction is "leaky". I don't really see how Rust or anything else can make that go away.

I feel like the closest I can get to have my cake and eat it too is by having the compiler transparently infer all the exceptions / errors that can be thrown by the calls I am making (like type inference for variables), but leave them out of the type signatures. Then I can opt in to enforcing the checking of them when I want to, so something like

        check {
           doSomething()
        }
        catch(...) { // every error now has to be handled
            ....
        }

I guess this is something like what Rust is achieving through the ? operator.

<comment><USER3> In the case of Map, since some maps fail and others don't, and those that fail can fail with different errors, it would be reasonable to express in in the type itself - i.e. instead of Map<T>, you have Map<T, E> (and then you also need union types to properly express E being a list of exceptions, and a unit type to express an empty list). Then any code that handles generic maps can also be generic wrt E, propagating whatever is thrown, and possibly adding its own errors, or catching some specific ones. And, conversely, you could only accept Map<T, Unit> for code that expects non-throwing maps, and then you don't need to catch or propagate anything in that code. Add defaulted generic parameters for convenience - e.g. Map<T, E=Unit> \- and now API clients don't have to care about E if they don't want to, and are happy with things as they are.

Alternatively, you can just say that map is something that never throws, by definition. But, of course, that reduces the utility of the interface, by making it less generic than it could be. In some cases - especially with HOFs - the reduction in utility can be so substantial that it negates any gains from code reuse.

</comment></comment></comment></comment><comment><USER4> I've shown Rust's Result type to folks on occasion because I like it so much. The other aspect I like is the `?` operator, which allows for easier error propagation.

[https://doc.rust-lang.org/book/ch09-02-recoverable-errors- wi...](https://doc.rust-lang.org/book/ch09-02-recoverable-errors-with- result.html#a-shortcut-for-propagating-errors-the--operator)

<comment><USER5> `?` isn't really that great - for all but toy cases you have to jump through hoops - especially if you are trying to handle different error types from separate in a unified way.

Not a fan of Result, either - it ties together the error type and the type of the desired item - these should be separate concerns.

<comment><USER6> > Not a fan of Result, either - it ties together the error type and the type > of the desired item - these should be separate concerns.

How so? 'Result' is just a generic variant record with two variant cases, for the "success" and "error" condition. It's the exact same as the `value, err` pattern in Go, except that it additionally enforces proper semantics and handling of the outcome.

</comment></comment></comment><comment><USER7> One of the more interesting semi-recent additions to stable rust is the question mark operator. It's not covered in this Rust Error Handling article, but it's got some of the early-exit appeal of exceptions without too much unwind magic.

Unfortunately I haven't been able to get the question mark operator to work yet with my code, but it looks appealing. It's not 100% obvious to me what qualities my Result type needs in order to be able to make it work. Or whether it's bound in practice to the Result type(s) defined in std. I'm sure those details are all in the docs somewhere but I spent the time to look yet.

<comment><USER8> One thing you may be missing is that the `Result::Err` in your return type must implement `From` for the `Result::Err` type where you're using the `?` operator. That's already covered if those `Err` types are identical (`From<T> for T`), otherwise you need to implement the conversion.

        impl From<QuestionError> for ReturnError {
            fn from(error: QuestionError) -> ReturnError {
                // TODO
                unimplemented!()
            }
        }

<comment><USER7> Oh yeah, that's likely it. Thanks!

It it safe to just put a noop in there? What's From-ness? Is QuestionError defined in std? Where do I read more?

EDIT: oh I see, I didn't read carefully. I just need to provide a conversion. Your example is very clear.

<comment><USER9> It's how you explicitly cast from one type to another. To use the ? operator with a custom error type, it needs to be converted to the std error type.

<comment><USER10> It needs to be converted to whatever error type the function returns. That can be anything.

</comment></comment></comment></comment></comment><comment><USER11> I'm kind of contemplating a career switch since in mobile JavaScript cross- platform seems to become pretty big and I just don't feel very warmly about becoming a JavaScript specialist.

What are the possibilities for somebody that's pretty heavy iOS senior to transfer to a role building applications or services in Rust (or Elixir, for that matter)?

<comment><USER12> AFAICT, 99% of the Rust jobs out there are just crypto startups. So at this point, not that great.

<comment><USER13> Any job is a Rust job if you're in charge of deciding the language.

<comment><USER12> It's a tough sell to manglement considering there's almost no developers who know it, and it's not something you can ramp up on quickly like Java to C# or Ruby to Python.

<comment><USER14> I remember that in the past, early 00s, this was true for Python as well.

One had to make an active effort to pick Python to be a tool for the job.

I remember being in one of big government project pitch session and the project manager asked "What this Python language? Sounds like some toy."

Times will change. However Rust sweet spot is system programming. Even though one could build e.g. websites with it, Rust loses its edge and becomes verbose, a too heavy hammer.

</comment></comment></comment></comment></comment><comment><USER15> I am a full time Go developer learning rust on the side for more low level things, and one of my side projects is writing an OS.

Rust's error handling really feels the exact same way to Go's in my opinion, the only difference is, so far in my admittedly newcomer viewpoint, using unwrap to get to the error value, or returning an error value and doing an if err != nil check.

This isn't to say anything other than agreement that I indeed like this style. I like to handle my errors as values and program around them.

The thing I don't get is why all the bikeshedding and hate around "if err != nil" spam I seem to have seen here often and on other blogs. Go seems to get this "criticism" (I don't really believe it is a valid critique, for what it is worth) heaped onto it plentifully, while Rust seems generally immune to it, otherwise praised for the approach -- but it is the same approach! In fact you even have a builtin panic func in go!

Can someone tell me what I may be missing?

<comment><USER16> The best parts of rust's error handling are the try!() macro (aka `?`), as well as From/Into error types allow the compiler to wrap types or convert between error types. This eliminates almost all of the go boilerplate `if err != nil` and you only handle the error where you actually need to with pattern matching and destructuring, instead. It is much nicer. Go's error handling is pretty primitive, in my opinion.

<comment><USER17> >The best parts of rust's error handling are the try!() macro (aka `?`),

Go's way of providing try!() macro is less magical but almost as useful.[1]

> From/Into error types allow the compiler to wrap types or convert between > error types

error is an interface in Go which can be easily cast/checked for the underlying type.

> Go's error handling is pretty primitive

I wouldn't call it primitive, I would call it simple. I like the comparison i read on a blog on HN.

Rust is the 'new' C++ and Go is the new C

[1] [https://blog.golang.org/errors-are- values](https://blog.golang.org/errors-are-values)

<comment><USER18> > error is an interface in Go which can be easily cast/checked for the > underlying type.

Yeah it's done during runtime and the compiler won't be able to help you with it if you fail to do exhaustive type checking. It's a problem anytime you refactor your code. ADTs and pattern matching is pretty much the bare minimum language feature i expect from any statically typed language.

</comment></comment></comment></comment><comment><USER19> I don't particularly like the solution presented.

1\. The Rust community is biased against the usage of "unwrap". It was supposed to make prototyping easier. It should not have been there and should not be used.

The correct way will be to "evaluate" the function and either return a result or "propagate" the error to some part of your application that will handle "all" the errors. Whether they are your code errors, or errors thrown by other libraries.

2\. The code will look even more succinct with the "?" operator:

> let value = some_operation_that_might_fail()?;

3\. If the function fail, the program should handle the failure. By design, a failure should not result on setting a "default value". That's not an error but more like an "option".

The correct type the guy should have used is the Option type. Or more like an option inside a result. The option could return a value or not. If not, you set a default value.

<comment><USER20> > 1\. The Rust community is biased against the usage of "unwrap". It was > supposed to make prototyping easier. It should not have been there and > should not be used.

I'm a little confused on this point you are making. You say the Rust community is biased against `unwrap` which makes it sound like you think that is wrong but then you proceed to say it shouldn't be there, making it sound like you agree.

`unwrap` has legitimate uses in product code as an assertion. Normally I recommend `expect` instead so that the assertion is self-documenting but there are times where the the scope of the assumption you are making is so small, it is obvious and doesn't need a comment, for example if I partition a collection based on the result [0]

[0]: [https://doc.rust-lang.org/stable/rust-by- example/error/iter_...](https://doc.rust-lang.org/stable/rust-by- example/error/iter_result.html#collect-all-valid-values-and-failures-with- partition)

> . If the function fail, the program should handle the failure. By design, a > failure should not result on setting a "default value". That's not an error > but more like an "option".

From the function's perspective, it errored, but from your perspective, it failed and you want to fallback to a default value.

Yes, someone could express this instead as an `Option` or a `Result<Option, _>`

\- Sometimes you just don't need that extra boiler plate \- Sometimes you want to provide context for why something failed in case the user considers it an error as well. You can't express that with `Option`.

<comment><USER19> > I'm a little confused on this point you are making. You say the Rust > community is biased against `unwrap` which makes it sound like you think > that is wrong but then you proceed to say it shouldn't be there, making it > sound like you agree.

Nope. I think unwrap shouldn't be used without understanding the error handling capabilities of Rust. It also shouldn't be used for deployed software. The problem is that most people introduced to Rust would like to see something working now and Rust has higher barrier to entry than most mainstream languages. They'll likely keep the habit.

> From the function's perspective, it errored, but from your perspective, it > failed and you want to fallback to a default value.

That's not my point. My point is that a failed function should not return a "default value". A default value is not a failure but rather a design decision. Should the function fail, it returns an error.

<comment><USER21> > It also shouldn't be used for deployed software.

This is equivalent to saying that `&vector[i]` shouldn't be used in deployed software, since it's just syntactic sugar for `vector.get(i).unwrap()`. It's also equivalent to saying that `assert!(...)` should never be used in deployed software. Or `unreachable!()`. Or any number of other things.

unwrap is perfectly fine for use in production. Stating a requirement in terms of unwrap doesn't make sense outside of niche scenarios. It's too specific and not really actionable in a lot of cases. A better way to put it is that programs that surface a panic to end users of the application have a bug. If the panic is from inside of a library and not the result of documented preconditions on a function, then the library has a bug. Otherwise, the bug is in the application.

</comment></comment></comment></comment><comment><USER22> While I too love Rust's error handling, this explanation of it seems incomplete without discussing the ? operator and its interaction with the From trait. The convenience methods on Result itself are nice of course but they aren't really the main mechanism of error handling in my opinion.

</comment><comment><USER23> So what do you do when you want centralized error handling, which is the whole point of try-catch idiom?

 _> he second side effect is that it forces you to think about how to handle possible errors._

Java does this with throws E and (at least in Java) it sucks and I very much prefer C#'s implicit throws. In fact, I don't think it goes far enough. If you have complex error recovery, the language should allow you to completely separate good executions paths from the bad paths. Scope guards are a step in the right direction.

How would Rust code looks like if the error handling logic was something like "try X, if it fails try again, if that fails schedule another attempt via a queue, log a warning; if scheduling fails log a fatal error"?

Sure, handling this stuff with try-catch looks horrible. But I've thought long an hard about how to simplify it and using tricks like .unwrap_or (which you can simulate in C# to some extent) does not cut it, because error handling often requires to operate on method-scoped variables (e.g. for logging).

<comment><USER24> Depends what exactly you're looking to do. You can propagate errors with the `?` operator. And you can match on the specific error at a higher level.

The docs[0] do give a more complex example of error matching:

        fn main() {
            let f = File::open("hello.txt");

            let f = match f {
                Ok(file) => file,
                Err(error) => match error.kind() {
                    ErrorKind::NotFound => match File::create("hello.txt") {
                        Ok(fc) => fc,
                        Err(e) => panic!("Tried to create file but there was a problem: {:?}", e),
                    },
                    other_error => panic!("There was a problem opening the file: {:?}", other_error),
                },
            };
        }

Although they also provide a slightly simpler alternative for this particular case.

[0] [https://doc.rust-lang.org/stable/book/ch09-02-recoverable- er...](https://doc.rust-lang.org/stable/book/ch09-02-recoverable-errors-with- result.html)

<comment><USER23> Doesn't look that much cleaner than try/catch, to be honest.

What I would _really_ like to see in C#:

      public int DoThing(int y)
      {
        //logic
      }
      catch (SomeException e)
      {
        //handle things
        return 0;
      }

This would remove a lot of useless syntactic garbage without the need for any radical changes in the language. (It would translate to try-catch that wraps the entire body of the method.)

But so far I gave up on syntax-level error handling of any complexity. Generally, I just write multiple "agents" and all the error handling, retries and recovery is simply done by separate agent(s). The agent that tries to perform the initial actions simply records that it failed in some persistent storage and terminates or goes on to do something else.

<comment><USER25> > It would translate to try-catch that wraps the entire body of the method

It would not not be the same unless you change how scoping works in these instances, and that can introduce other complexities, e.g. how to limit scope so that some things are inaccessible to the catch block.

<comment><USER23> This:

      public void DoThing(){
         //code
      } catch (Exception x){
      } finally {
      }

would simply be syntactic sugar for this:

      public void DoThing(){
        try {
          //code
        } catch (Exception x){
        } finally {
        }
      }

It's consistent.

<comment><USER25> Yes, and that only works by changing how scoping works. Unless of course you don't care about the variables created inside.

i.e.

        public void DoThing()
        {
           var someVar = SomeStaticClass.FooFunc();
           someVar.DoSomething();
        }
        catch (Exception x)
        {
           // Scoping rules will need to change
           // to put someVar in scope:
           _logger.Log($"{someVar.GetId()} is invalid");
        }
        finally
        {
           someVar.Cleanup();
        }

And this also implies that there's no way to make a variable declared inside the method inaccessible to the catch block without additional changes to the language.

<comment><USER23> _> Unless of course you don't care about the variables created inside._

In majority of cases I really don't care about the variables created inside. If I can't handle an error just by looking at the exception and method arguments I usually refactor. In my view, error handling should not be intertwined with the "happy path". It makes reasoning about non-trivial code much harder.

For other cases the old syntax will still be available.

And yes, the value of "finally" in such a shorthand is dubious. I just added it to make it clear how the rewrite rule would work.

</comment></comment></comment></comment></comment></comment></comment><comment><USER26> TensorFlow has a StatusOr C++ class that allows functions to return a value that can be first checked to be result.ok() (no error), and then the actual value can be unwrapped. It's Google's way of not using exceptions.

[https://github.com/tensorflow/tensorflow/blob/38c762add3559b...](https://github.com/tensorflow/tensorflow/blob/38c762add3559b3292139c1d839c706a1695e2fc/tensorflow/stream_executor/lib/statusor.h)

</comment><comment><USER27> Designs like Java which have NullPointerException simply ignore null. Modeling T instead of T | null is just too convenient. It's a lazy design.

I'm fine with most of those new ways of error handling, although some feel better and the others feel a little bit awkward. If some concept exists (exception/emptiness/async), model it, handle it. Instead of just ignore it and leak the responsibility to the users.

</comment><comment><USER28> Not being familiar with Rust, the article was interesting, but I felt like it lacked examples. The Result<T, E> is also available in other languages, even in TypeScript you could have `function x(): number | Error {}`, it is just a consequence of being able to return a union of data types, why is Rust's case special? (apart from being able to handle it nicer with "match")

<comment><USER29> Rust's is a tagged union so you can have Result<number,number>, something you can't have in Typescript.

<comment><USER30> You can have `Result<number, number>` in both.

You generally have to treat `E` as an error because of the semantics of `.map()` in every language, though, because you have to essentially ignore one of the sides. `map<Result<T, E>>` is untypable for any practical scenario where both sides matter equally.

Also, just to clarify how you can have essentially the same thing you would in f.e. Haskell but in TypeScript:

```

        export type Result<T, E> = Ok<T, E> | Err<T, E>;

        interface Ok<T, E> {
          type: "Ok";
          unwrap(): T;
          map<B>(f: (x: T) => B): Result<B, E>;
          toMaybe(): Just<T>;
          or(errorValue: T): T;
          apply<U>(f: Result<(x: T) => U, E>): Result<U, E>;
          bind<U>(f: (x: T) => Result<U, E>): Result<U, E>;
        }

        interface Err<T, E> {
          type: "Err";
          unwrap(): E;
          map<B>(f: (x: T) => B): Result<B, E>;
          toMaybe(): Nothing<T>;
          or(errorValue: T): T;
          apply<U>(f: Result<(x: T) => U, E>): Result<U, E>;
          bind<U>(f: (x: T) => Result<U, E>): Result<U, E>;
        }

```

<comment><USER31> Right, but in Typescript you can't match on the type at compile time, you have to add a "type" field with a string tag and match on it at runtime.

<comment><USER30> Well, the compiler constrains the type automatically as far as it can go, so a `switch` on the `.type` property will constrain it down to the specific case in the union. Practically speaking it's not all that different to f.e. Haskell, except you're manually tagging the different cases. You get exhaustiveness checks when checking cases by adding a `assertExhaustive(value: never)` in your `default:` case, which will only match if you handled all the cases.

For development purposes this is all essentially the same as proper sum types, _with worse ergonomics_.

My point was mostly that practically speaking you can have a full featured `Result<T, E>` type that is certainly good enough. What TypeScript lacks is what most halfway languages lack; higher-kinded types, etc., and good ergonomics that follow, such as type classes. These are also not a given in more esteemed type system circles: OCaml doesn't have them either (and most features that are "coming soon" in OCaml are bordering on vaporware).

Most nice type system features you can get by way of combinations of 2-3 distinct type system features in TypeScript. In terms of end results the only things that differentiate TypeScript from languages with more traditional type systems is that you have to use `TSLint` to absolutely eradicate `any` from usage completely (wheras you don't have it at all in a better type system) and the ergonomics for functional programming just aren't that great in JS.

This isn't the TS part of the syntax that's the issue, it's just that anyone who's used a ML descendant in the last 40+ years will have noticed that (automatic) currying is a massive boon to functional programming (and on top of that C-syntax is just about the worst for FP with all the noise that comes with just calling functions). Even something small as not being able to define operators is pretty disruptive to nice code. People like to rag on languages that let you do this, but there are many patterns in FP that absolutely are best encoded via well known and generally accepted operators.

</comment></comment></comment></comment></comment><comment><USER32> Really nice! The Result reminds me of Validation from Scala.

In Scala you return a Validation that is either a value or an error, and can pattern match on it. Also: trySomething().orElse("Default value")

</comment><comment><USER33> To be fair. The idiomatic C# would be:

        if(TrySomeOperationThatMightFail(out var value))
        {
        }

But even with that I often wish it was more like the Rust example

<comment><USER34> Except 99% of methods are async in a web app where the out variable does not work.

</comment></comment><comment><USER35> This is an extremely common pattern in Erlang and is super useful so it's nice to see Rust embrace it.

</comment><comment><USER14> The article is a good opinion, but lacks necessary wider discussion in the context of all programming.

1) Is Rust error handling somehow better than in a programming language X?

2) Is it because of Rust or because standard libraries or something else (developer laziness, writing silent exception eating)

3) Why other programming languages choose to do it other ways?

Now the article reads like Rust education, which is good, but other commenters here find it very subjective.</comment>


The SEO Rapper Gives You Advice On Improving Google PageRank - <AUTHOR> http://www.badassdigest.com/2011/02/15/the-seo-rapper-gives-you-advice-on-improving-google-pagerank

<comment><AUTHOR> I wasn't sure what to expect when I watched this video but it turned out to be the same good advice that Google gives you except it's put to a beat.</comment>


Tesla Turns Power Back on at Children's Hospital in Puerto Rico - <AUTHOR> http://www.npr.org/sections/thetwo-way/2017/10/25/560045944/tesla-turns-power-back-on-at-childrens-hospital-in-puerto-rico <comment><USER2> wasn't this same story at the top of HN yesterday?

<comment><USER3> A TechCrunch article on the same topic received 52 points, 18 comments from 2 days ago:

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

</comment></comment><comment><USER4> I hope I'm not being naive about this (as corporations often have a way of making you regret your words), but this is the way - find a need, make it happen, get it done. I am really glad Tesla et al are doing this. They are having a direct impact and they may even reap some nice rewards themselves down the line, even if that wasn't the biggest driver.

I wonder if they could look into outcome-based contracting [1] for these projects, should the discussion of paying ever arise. Seems like it might be a good fit.

[1] [http://www.enme.umd.edu/ESCML/Papers/Sandborn%20Contract%20E...](http://www.enme.umd.edu/ESCML/Papers/Sandborn%20Contract%20Engineering%20-%20TES%20Conf.pdf)

</comment><comment><USER5> Tesla is amazing at marketing. Elon also seems like a genuinely good person, which helps.

<comment><USER6> I think this is a social responsibility regardless, although some people prefer to do good work either anonymously or behind the camera. Either way is fine.

<comment><USER7> If you see the adoption of sustainable technology as a social good, then it would be a missed opportunity to _not_ publicize this event. It's a great advert for solar power and battery storage.

</comment></comment></comment><comment><USER8> One problem with Solar I hadn't really thought about is how robust they are (not) in storms. The picture at the top of this article shows how a grid on Peurto Rico was destroyed.

[https://spectrum.ieee.org/energywise/energy/the-smarter- grid...](https://spectrum.ieee.org/energywise/energy/the-smarter-grid/should- a-devastated-caribbean-leap-forward-to-renewable-power-and-microgrids) links to: [http://www.theweatherjunkies.com/single- post/2017/09/28/Puer...](http://www.theweatherjunkies.com/single- post/2017/09/28/Puerto-Rican-Solar-Farms-Heavily-Damaged-By-Hurricane-Maria) which shows some that are built more robustly.

Looking around there are lots of panels with hail damage and catching fire etc, its not as simple as I thought!

<comment><USER9> I too am curious how this is superior to electrical lines in a storm. The best I could come up was that the grid is now more distributed such that storms could take out some but not all systems. I suspect getting certain critical assets back online would necessarily be easier since additional nodes aren't necessary to interlink power from a central system. Can anyone provide other benefits?

</comment></comment><comment><USER10> Some good news after the layoffs and news of a shitty working environment.

</comment><comment><USER11> The amount of Elon Musk hate I see online is crazy. It seems like people are hellbent on hating this guy. When he announced that Tesla could help Puerto Rico, the number of snarky and demeaning comments was huge. Now, so quickly, they've actually accomplished something good. I wonder if any of those snarky people, most of which probably did nothing to help Puerto Rico, will care.

<comment><USER12> All I can say is I saw this headline and breathed a sigh of relief. I haven't heard anything good coming out of PR at all.

For what it's worth, while I like the idea of solar power as the revival of PR's power grid, I would not be breathing such a sigh of relief if the feds had helicoptered in with the kind of energy they reserve for invading countries and restored power and set up relief for villages far from the port.

</comment></comment><comment><USER13> _Tesla 's image of the project's solar array, in a parking lot next to the hospital, has been liked more than 84,000 times since it was posted to Instagram Tuesday._

Tesla should be paying the hospital.

<comment><USER14> _Tesla should be paying the hospital._

Beyond donating the panels? Other people are free to donate goods and services to help Puerto Rico recover, I will do my part to ensure they're recognized regardless of partisan affiliation.</comment></comment>


Earth Will Likely Be Much Warmer in 2100 Than We Anticipated, Scientists Warn - <AUTHOR> https://motherboard.vice.com/en_us/article/xwvx5q/earth-will-likely-be-much-warmer-in-2100-ipcc-projections?utm_source=mbtwitter <comment><USER2> > Last week the US Senate passed a bill allowing oil drilling in Alaska's > Arctic National Wildlife Refuge as part of a sweeping tax overhaul bill. > However oil prices would have to substantially higher to make it profitable > to drill there. "It will be interesting to see who wants to go there," said > Sanzillo.

So who is advocating for this legislation and what is the incentive to pass it?

<comment><USER3> Cynical long-term prediction ahead:

The powers that be have wanted this for years. Energy interests from the time when oil was MUCH higher priced, politicians from the favor it would curry with their lobbying interests, etc. The trump administration has simply given them a wide open window to push it through, even if it's not immediately useful. In the long run, given legislative trends, it will likely be harder to unwind any of these decisions, so they've "locked in" their gains, so to say.

Look at the broader scope of anti-reserve legislation; many reserves are being shrunk in a manner that will lead exclusively to states selling off public land to private interests. There's 0 compelling public benefit from this other than deriving a small amount of revenue for the states in which they're located; (/s since the US is clearly lacking usable land, _of course_ the answer is to lay claim to some of the more precious unused land we have /s) ignoring even a potential decline of sport/tourism dollars. All of this seems like a bunch of maneuvering to trade American natural heritage for a small amount of political favor and economic benefit for handfuls of empowered/aligned entities.</comment></comment>


Suppress, an HA component. - <AUTHOR> https://github.com/chrisdew/suppress#suppress

<comment><USER2> This is intolerant of network partitions.

<comment><AUTHOR> Yes, it is.

Can you suggest a better design?</comment></comment>


Would you need any engineering help? Hardware or software? - <AUTHOR> https://www.nastry.com/ <comment><AUTHOR> Hi All,

Would you need any engineering support for your company? How much would you like to pay? What do you need?</comment>


Can Silicon Valley Save the World? - <AUTHOR> http://www.foreignpolicy.com/articles/2013/06/24/can_silicon_valley_save_the_world

<comment><AUTHOR> Google Link sans paywall:

[https://www.google.com/search?q=Can+Silicon+Valley+Save+The+...](https://www.google.com/search?q=Can+Silicon+Valley+Save+The+World&safe=active)

Felix Salmon comments:

[http://blogs.reuters.com/felix-salmon/2013/06/25/can- philant...](http://blogs.reuters.com/felix-salmon/2013/06/25/can- philanthropists-be-ruthless/)</comment>


Testing Microservices the sane way - <AUTHOR> https://medium.com/@copyconstruct/testing-microservices-the-sane-way-9bb31d158c16 <comment><USER2> _> The Vagrant repo itself was called something along the lines of "full-stack in a box", and the idea, as you might imagine, was that a simple `vagrant up` should enable_ any _engineer in the company (even frontend and mobile developers) to be able to spin up the stack in its_ entirety _on their laptops._

This is honestly not that hard to get working, if you have Docker and good tools. For simple cases, "docker-compose" will work well enough. For complex cases, my employer open-sourced a tool for exactly this: [http://cage.faraday.io/](http://cage.faraday.io/) This extends docker-compose with the idea of multiple pods, staging/production environments, etc.

For testing, we have plenty of unit tests, and we've been experimenting with pact [https://github.com/pact-foundation/pact-js](https://github.com/pact- foundation/pact-js), which turns microservice consumer mocks into provider contracts.

But at the end of the day, it appears to be absolutely necessary to have end- to-end tests that run in a staging environment whenever a service is updated. Otherwise, something inevitably falls through the cracks. It's a nice idea to think that you can develop each microservice in isolation, but _somebody_ ultimately has to watch site-wide quality.

<comment><USER3> It's easy at low scale. It breaks down hard with dozens of services +.

<comment><USER4> Why?

<comment><USER3> A variety different factors. More moving parts == more stuff that can break. Knowledge about a specific service becomes less widespread, so issues take longer to resolve. Also, just hardware scaling becomes a problem. It also really sucks to have to have 50 people rebuild dev environments because you bumped a system dep in a container that your app now depends on. At some point, just building and bringing up all those containers becomes really slow, and you're going to have to build more and more systems to aid in that.

There's also all the stuff that's tricky to automate - say you're using AWS Lambdas, step functions, SQS queues. Translating that across different developer envs is a challenging problem.

I'm very much on the monolith-first approach. There are cases for microservices for specific business functions when you have few engineers, but in general it's far more of a scaling layer for engineer count. Single-app workflows are typically much more productive compared to microservice workflows up until a certain point.

</comment></comment></comment></comment><comment><USER5> Perhaps it's just me, but if you can't run your stack locally for any reason but space or metadata, you're too tightly coupled to your platform. This is doubly true in this age of Docker. Of course, Amazon and Google and Azure love tightly coupled applications, but it's not good for creating portable code. And portable code is something that's good for your pocketbook as well as your code quality.

I'll admit, I'm not a fan of testing in production, especially when you're doing that testing against paying customers. I've just seen it go poorly too often, with the common result of lost customers. When you're B2C, it's bad since you're now having to acquire more customers not to grow, but to remain even; a death-knell for VC-backed startups. When you're B2B, the loss of customers signals a coming winter for the business. I've been through a couple of layoffs due entirely to lost customers.

Remember that your product is most likely a fungible asset - your service easily replaceable by a competitor - and if you piss off your customer base by allowing out blatant bugs, you will lose customers. The sheen of newness has worn off tech companies, and customers are not going to be as forgiving of their time being wasted as they once were.

<comment><USER6> A pretty pithy response would be that any time you're deploying new software to your production environment, you're testing against real customers. While you should have comprehensive pre-production testing, there's no good substitute for making sure the thing going into Prod is working by running tests when it is in Prod.

Looking at her list of production tests, her list generally falls into 3 categories:

* instrumentation of code for observability * staged rollout of new software to observe issues on a subset of traffic/hosts against the rest of Prod * simulating failures in Prod to test against possible random failure scenarios

Of those, the first should have zero impact on your customers, the second should be making your customer experience better by reducing the blast radius of a bad deployment, and the third should be making your service more resilient to failures over time for your customers. Would you rather find out that you can't survive an availability zone outage when you can easily return that AZ back to healthy in a minute, or when you have to wait for recovery for an hour? Honestly I think its disrespectful to your customers to gamble on what might happen in the future rather than asserting that your service can handle the wide array of known failures that can happen in this world.

<comment><USER5> If there's any question of how something is going to respond to production load or production data, there's a missing step somewhere in the release process.

WRT the three points you bring up:

1) Instrumentation is a part of any good deploy, regardless of where, when, or why. Instrumentation _is not_ a replacement for testing.

2) Staged rollouts are a good thing, but they don't prove the new object being rolled out is production ready. They can cordon off major failures, yes, but see my comment above about missing steps when it comes to major failures.

3) Not all companies can afford the Netflix model of having multiple fully redundant data centers at all times. I'd even hazard a guess that _most_ companies can't really afford to triple (or more) their infrastructure costs in addition to the higher development and maintenance costs. Ultimately that's one thing that testing is good at: ensuring your disaster recovery plan works without honking off customers when you discover gaps in that plan.

None of these three strategies will replace pre-customer testing. At best full adherence to the policies (in the absence of end-to-end testing) will only limit the amount of damage major bugs can do. The question to me is: why are we OK with just limiting the damage of otherwise findable bugs?

</comment></comment></comment><comment><USER7> I'm going to have to re-read the post a few times, but my thoughts on this topic are that cross-system automated tests are futile because, by definition of being "not your system", you can't easily and deterministically control the input state (of the combined your system+not-your-system), so any tests you build on top of this will be like building on quick sand:

[http://www.draconianoverlord.com/2017/08/23/futility-of- cros...](http://www.draconianoverlord.com/2017/08/23/futility-of-cross-system- integration-testing.html)

My preferred solution, that I haven't had a chance to actually flush out at scale, so disclaimer/YMMV, is for all services to ship with stubs:

[http://www.draconianoverlord.com/2013/04/13/services- should-...](http://www.draconianoverlord.com/2013/04/13/services-should-come- with-stubs.html)

Where the stub is an in-memory version of the service that its authors maintain (not the client), so you can achieve the proverbial "deploy all systems on your local machine", but since they're stubs, they're extremely quick to boot/reset/etc., and also with allowances (again since they are stubs) to let you set the per-test input data of any stub your system talks to.

I believe this would work best with homogenous/noun/REST-based services, e.g. all entities in your corporation have a strict/unified CRUD API, so then "integration" tests (e.g. the proposed stub/no-actual-wire call tests) can define their input data in terms of entities and be fairly oblivious about which stubs/systems those entities actually live in.

<comment><USER8> Good thoughts, Stephen!

I was recently reading about Hypermedia HAL APIs[1] (TLDR: add metadata to API responses, helps w/ discoverability etc) which could conceivably play a role in solving this kind of problem.

[1] [https://sonalake.com/latest/hypermedia- apis/](https://sonalake.com/latest/hypermedia-apis/)

</comment></comment><comment><USER9> Discarding the "full stack in a box" idea, _in general_ , just because of past experience with a poorly implemented vagrant setup seems naive. A good "full stack in a box" implementation (docker-compose, swarm, kubernetes etc.) can be a useful tool in testing/developing microservices.

<comment><USER10> Well there is obviously a point at which it will no longer work (way before Google scale). But the point is to stop testing services in a coupled way, the whole point of microservices is to make decoupling real, not to build a distributed monolith. Testing in a decoupled way helps this enormously.

<comment><USER11> Yeah, excepts it doesn't. In those microservices setup more than not the change in the data to accomplish a client request is 3 or more services of "distance". Still, it needs to be accomplished. If you don't coordinate all the services involved (all with different developers team, maybe from different contractors) AND if you don't do an end-to-end test, how can you be sure to do the requested change?

<comment><USER12> > In those microservices setup more than not the change in the data to > accomplish a client request is 3 or more services of "distance". Still, it > needs to be accomplished. If you don't coordinate all the services involved > (all with different developers team, maybe from different contractors) AND > if you don't do an end-to-end test, how can you be sure to do the requested > change?

You're doing it wrong. If these services are really so deeply entangled that you can't change and test them one at a time, they shouldn't be independent services. Merge them, or otherwise rethink your service boundaries.

</comment></comment></comment></comment><comment><USER13> My company is in the process of building out an integration test suite for our microservices platform. A few pain points:

1\. The tests themselves are housed in a separate repository, so you can't update the tests alongside your service. This means every change to a service has to be backwards compatible. Hello, multi-step rollouts.

2\. Our environments must be highly configurable, so that every permutation of versioned services can be integration-tested. This is forcing us to adopt an unnecessarily complex container orchestrator.

3\. Service owners are not excited about setting up and contributing to yet another project. We end up with a lot of out-of-date integration tests. Lots of noise, if you ask me.

I think a combination of contract testing (e.g. using Swagger, Pact) with monitoring, canary deployments, and automatic rollbacks would be easier to maintain and just as effective at catching bugs.

<comment><USER3> Once you dive into SoA, you see how much sense single-source-repository starts to make. Developing features between <n> different repositories is tedious, and the single-repo gives ample benefits. Having easy-to-work with interface layers like protobuf in a shared repo makes tons of sense, for example.

It's interesting to see how things like Golang may well have evolved out of this problem. Calculating a golang app's dependencies is as trivial as a grep or two, so it's easy to know what tests to run when libraries change.

<comment><USER13> At the very least, this experience has made me question the conventional wisdom that microservices = good and monolith = bad.

<comment><USER14> That's conventional wisdom? Outside of loud naive bloggers preaching that microservices solve the world's problems, most engineers I've chatted to IRL have been pretty skeptical of the overall utility of microservice architectures because of the high complexity they add.

</comment></comment></comment></comment><comment><USER15> the discussion about the difficulty of testing microservices makes me wonder how the programmers in 20 years will look at the currently modern systems that are being built now. Let's say the system has been in use for 10 years, everybody has moved on and now you have to make extensions or bug fixes to a legacy cloud/microservice/multi-language/multi-server/distributed/queuing/ system. At first look this makes updating an old COBOL system where you have one big codebase in one place look easy in comparison.

<comment><USER16> Won't the fact you need to only replace some parts with well-defined interfaces help?

In my company, we had a legacy PHP system that seemed to me excessively layered and cut too thinly. In reality, it allowed to completely replace that system with Python and Java piecemeal, without ever stopping it.

<comment><USER15> Now imagine in 10 years someone comes in and has to figure out how all these services written with outdated libraries fit together and how to fix bugs.

<comment><USER16> HTTP does not get outdated for quite some time already. The standard connection points with extremely late binding is what makes microservices somehow easier to update, as opposed to rebuilding a monolith.

Fitting together is an aspect that becomes _easier_ when you decompose your app properly microservices or not. When a component has clear responsibilities, it's easy(-ier) to understand, modify, and replace. When a component is reasonably small and isolated, it's easy(-ier) to analyze and understand, even if it's written in an ancient language using dust-covered unmaintained libraries.

</comment></comment></comment></comment><comment><USER17> A lot of interesting content in this article, but think it could benefit from some editing. Maybe an article half the size, or two or three separate articles breaking out the various topics covered.

<comment><USER18> She's currently writing a book on the subject. I believe these blog posts are teasers for the final product.

<comment><USER17> That would make sense! Seems like an early book draft.

</comment></comment></comment><comment><USER19> > Ultimately, every individual team is the expert given the specific context > and needs.

Most companies don't have specific needs. They think they do, but 90%+ of the companies out there are either building run of the mill CRUD apps or something barely more technically difficult.

<comment><USER19> Does the downvoter care to explain?

I have spent a good chunk of my life explaining companies why they don't need any special hand rolled platform - leaving hundreds of thousands of dollars on the table.

I guess parroting buzzwords is always more popular in this industry.

<comment><USER20> Managers in an organization often have more incentive to make the problems they work on look difficult, and therefore important, rather than fixing their problems quickly, cheaply, and reliably, which can make them look less valuable to leadership.

</comment></comment></comment><comment><USER21> Seems a little bit inflated - yes, docker-compose et al, are a problem if you have dozens of services all using different databases. But then, that's a level of complexity and scale that most applications / organisations won't reach. And if you do reach that, then you probably can afford to invest in something more sophisticated to solve the problem (service mocks, etc).

For situations where the true overall complexity is manageable, I think that making sure that the environment can be entirely replicated and bootstrapped easily is actually very good discipline for keeping complexity under control.

</comment><comment><USER22> No mention of mocking out service dependencies, which seems like the obvious way to go. Does anyone do this?

<comment><USER23> Absolutely. We have several front end layers, then nested service layers and then nested repo layers, all get mocked depending on the level of object we are testing. We then have separate integration tests that test the repo against an actual database. We design the integration tests so they are largely data independent (we load the data we test rather than just mock data).

</comment></comment><comment><USER24> Is the conclusion to monitor incremental rollouts of microsevice updates?

</comment><comment><USER25> Article makes me want to scream "just fire up rails/Django and build the dang app already!!!"

<comment><USER26> So the article makes you want to address totally different stacks for totally different needs and assume they only used multiple microservices because they are idiots?

</comment></comment><comment><USER27> tl;dr though I thought I'd mention that Postman's monitors is saving the day for me. You can go further and script white box tests in its little embedded JS language.

<comment><USER13> Postman can be handy for quick and dirty HTTP tests. Unfortunately, I find the Postman GUI unintuitive. The alternative -- working with minified JSON -- is equally painful.

Edit: English

</comment></comment><comment><USER28> TL;DR</comment>


What parents worry about vs what they should worry about - <AUTHOR> http://www.npr.org/blogs/health/2010/08/30/129531631/5-worries-parents-should-drop-and-5-they-should?sc=fb&cc=fp <comment><USER2> This is a huge pet peeve of mine. Prompted by news of an abduction in Missouri a while back, I wrote this: <http://messymatters.com/strangers>

Excerpt:

I love this quote from security expert Bruce Schneier:

       Remember, if it's in the news don't worry about it. The
       very definition of news is "something that almost never
       happens." When something is so common that it's no longer
       news — car crashes, domestic violence — that's when you
       should worry about it.

The truth of that hit home recently when I saw a news feature on the abduction of a four-year-old girl from her front yard in Missouri. Candlelight vigils, nation-wide amber alert, police blockades where every single car was stopped and questioned, FBI agents swarming the house. I think the expected reaction from parents is "oh my god, I need to be so vigilant, even in my own front yard!" My reaction was the opposite: Wow, this sort of thing really does essentially _never_ happen. Let the kids run free!

[EDIT: It goes on to compare to a non-abduction story...]

In summary, a toddler got separated from her caregivers and wandered off, where a passerby saw her. Seeing no one else around, his first instinct was to scoop her up and take her with him. But he decided that that was a big risk to himself — what would people think? — and continued on, reporting it later.

The girl then fell in a pond and drowned.

<comment><USER3> As a parent, one of the things I fear most is DCFS. I live on a large area of land with many natural resources and my children are free to do many things. I inform them of dangers and protect them from realistic dangers. But not every other parent thinks that way or agrees with it. It only takes one fearful parent to place a call into DCFS about their opinion on your parenting style. Once DCFS is involved you are at their mercy with little or no oversight.

So beware implementing some of the ideas presented here as things you shouldn't fear. Because not everyone will agree with you, and those other people can make your life very difficult.

<comment><USER4> if someone like the DCFS wanted to take my kids, i'd get the urge to poke them off my property with a loaded gun. i mean, US citizens have the right to bear arms, for the exact purpose of defending themselves against the government, or what was that?

<comment><USER3> Believe me, I hear what you're saying. But DCFS has no oversight. If you have guns in your house with kids they will take a very keen interest in you. There are DCFS rules for what you can/will/should do with guns in your home that may exceed what you would do. If the DCFS agent finds your gun not locked by an XYZ lock your kids will be taken from you. I am not joking either.

Every attempt you make to establish your rights will lead you further down the path of their goal. Take heed from the stories above and you will see how it works.

</comment></comment></comment></comment><comment><USER5> These fears seem to stem from the illusion of control and detectability.

Ask most folks if they would be able to tell if their child is depressed or suicidal and you'll get a variation of "Of course I'd know if my child was suicidal" or "My child isn't depressed!"

Ask then if they could tell if a school sniper is going to target their school or if a terrorist attack was going to happen. You won't find a similar confidence in the detectability of the outcome.

And that produces fear.

Unfortunately, car accidents, abuse, and suicide are in fact more prevalent because they have false detectability. The very same human factors that contribute to people answering with confidence about their child's emotional or mental state also cause us to overlook subtle warning signs.

That's in part why people so often express surprise when there is a suicide attempt or familial abuse. You don't often hear parents or relatives say "yeah, I saw that coming." It's more often "Johnny tried to kill himself? What a shame, I would not have seen that coming , he was always such a bright/happy/etc child".

</comment><comment><USER6> "Things that kill children" is not identical with "things parents should worry about". For example, immediate mortality is probably not parents' major concern with drugs (#5 on the list).

<comment><USER7> I came to say this same thing. As a parent, I really don't worry about 1-4 on the "shouldn't" list, but drugs is a real issue, especially in a family with evidence of a predisposition towards addiction.

There are also things I can do things about and things I can't, and that impacts what I worry about. I can't control a drunk that decides to cross four lanes of traffic, so beyond driving defensively, I don't worry about that.

On the other hand, I can teach my kids simple things in a way that doesn't have to panic them to keep them safe from unlikely chance they run into "stranger danger". We live in a low crime area, yet there have been a couple of very creepy incidents involving adults following/bother kids walking home from school.

I do wonder about where they got that list, though. I've never heard a single parent I know (and I know a lot of parents) who has said "I sure Johnny makes it home from school today and that the snipers don't get him." WTF?

<comment><USER8> How likely is it that your child will die from a random drunk crossing four lanes of traffic vs. merely taking a ride with a friend who is unsafe? Or, for that matter, drunk?

Drivers aged 16-19 have auto fatality rates _four times_ higher than other drivers. That's not because they are magnets for middle aged drunk drivers.

1 in 4 teens killed in auto accidents were under the influence of alcohol.

Children are more likely to be molested by family members and friends of the family than by strangers. They are also more likely to die by stepping into the car of a friend than by being hit while driving alone. It's important to instill in your children the skills necessary to deal with the actual threats they are likely to encounter. Indeed, as a ridiculous example, if you told your children that they are not allowed to ride with friends but they are free to hitch-hike with random adult strangers chances are they'd actually be safer.

<comment><USER7> I could also fireproof and earthquake proof their rooms and never let them out, make sure they constantly wear rubber suits in case they trip, and only feed them formula through a stomach tube so they won't choke.

Yes, teenage drivers are scary. I'm scared every time my son backs out of the driveway (for him and everybody on the sidewalks). We have laws here that prohibit a new driver from having friends in the car without parents, which I think is great. I wish there was more we could do to make people safer and greatly applaud companies like Mercedes who are using technology to help with that.

However, I won't cripple myself or my kids by living for the worst case. I will try to teach and coerce so they worst cases won't happen, but I refuse to be a helicopter.

<comment><USER8> Yes, quite so. My point wasn't that you should coddle your children, but rather that it's important to understand what the real dangers are _and empower your children to deal with them_. Being overprotective of your kids from real dangers is a problem too, but being overprotective based on imaginary dangers is just plain dangerous.

</comment></comment></comment></comment></comment><comment><USER9> "It makes no sense to worry about things you have no control over because there's nothing you can do about them, and why worry about things you do control? The activity of worrying keeps you immobilized." - Wayne Dyer

<comment><USER10> That's one of the founding principles of stoicism[0], as I understand it. The general idea is to change your emotions about external events, since you can't change the events themselves.

I'm told it's rather helpful for POWs.

[0]: <http://en.wikipedia.org/wiki/Stoicism>

</comment></comment><comment><USER11> This article pretends that both lists are mutually exclusive. Maybe combined they equal most parents' top 10 list of worries, and the ones that happen rarely are simply the ones that are most effectively prevented. I rarely die, but I don't consider the time I spend preventing it to be wasted.

<comment><USER12> How much time do you spend preventing sniper attacks? (#2)

<comment><USER13> My sons play MW2, so they're well well trained in handling sniper attacks. They're also well versed in fending off campers and noob-tubers, in case either of those are #6+ on the list.

<comment><USER14> I hope they are well stocked with smokes and not stun grenades when the snipers come looking. Lets hope they have cold-blooded pro as a perk too.

</comment></comment></comment></comment><comment><USER15> School snipers is kinda ridiculous, but if you define "worry" as "fret due to a lack of control over the situation," then you can expect these kinds of results.

You're asking the vast majority of reasonably conscientious parents at large. What they "worry about" is the list of risks which they have not found a practical way to mitigate.

They're not being asked about how they think other people's kids might be killed, which would make comparing the two lists a valid exercise.

So these are heartening results. If parents are "worrying" about their kids dying by gunshot instead of actually locking up their handguns, you have a _major problem_.

<comment><USER16> Was the point about school snipers referring to actual gunmen picking off kids, or kidnappers grabbing a kid as they came out of the gates before their parents could pick them up?

Surely the gun-toting variety wouldn't be that common, even in the US?

<comment><USER17> I'm really curious about the survey methodology. If I ask a parent "Hey, are you worried about the fact that _right this moment_ somebody might be shooting your child with a sniper rifle for no good reason?" I'd probably get the response "Well, yeah, now I am..."

</comment></comment></comment><comment><USER18> This list is about how we fear the rare events that terrify us (terrorist event) over the more common events we just accept as risks of life (car accidents). Nothing to do with parenting.

</comment><comment><USER19> Since car accidents are number one cause of child fatality, and since it's on topic, I'd like to remind you people that rearward facing car seats protect better in an accident.

[http://www.youtube.com/watch?v=sssIsceKd6U&feature=relat...](http://www.youtube.com/watch?v=sssIsceKd6U&feature=related)

Also, _"Child occupants seated in the center had an injury risk 43% less than children seated in either of the rear outboard positions."_

[http://pediatrics.aappublications.org/cgi/reprint/121/5/e134...](http://pediatrics.aappublications.org/cgi/reprint/121/5/e1342.pdf)

</comment><comment><USER20> There are social factors that magnify worrying about children. For example, in the UK over 0.5% of children are in state care.

Thus parents also worry about what other adults think of them.

</comment><comment><USER21> similar issues are discussed regularly on the Free Range Kids blog: <http://freerangekids.wordpress.com/>

</comment><comment><USER22> I'm a parent and I worry tons about drowning and car accidents. I also worry about kidnapping, though, just because it's such a horrible thing. I have never yet to lose a minute of sleep over terrorists or snipers though -- it sounds they surveyed the Fox News paranoia generation with those responses (assuming this is an American audience. Those are obviously real threats in some parts of the world).

</comment><comment><USER23> I don't think so. My parents worried about the things in the list that gets kids killed, and not about the things in the that doesn't get kids killed. Which parents really worry about snipers and terrorists?!

<comment><USER17> Exactly. When I was a kid my parents put a lot of emphasis on making sure I crossed the road safely. When I was slightly older they put a lot of emphasis on making sure I rode my bike safely. And when I got old enough to drive, they damn well put a lot of emphasis on making sure I drove safely.

As far as I know they never worried too much about me getting shot by a sniper.

</comment></comment><comment><USER8> There are real costs to being worried about the wrong things. How many kids today have been raised in over-protective environments? Not allowed to travel around the neighborhood or the city alone, for example. How does that affect them when they become adults? How does that impact their ability to be self- reliant, inquisitive, adventurous, confident, self-starting?

</comment><comment><USER24> Slightly related, leading cause of death in my age group is accidental poisoning. This got no traction when I posted it, but I'll try linking one more time.

<http://news.ycombinator.com/item?id=1505903>

<comment><USER25> It's an interesting topic, but I found it a confusing article. I read quickly, but really didn't get a sense of how many of the deaths were due to what, what this implied, and what could be done about it. And I'm sure the required password certainly didn't help people read it. Post again when you find a clearer article that's out in the open!

</comment></comment><comment><USER26> I recently gave a talk at Ignite Boulder along these same lines. It's not just parents, we are all guilty of being scared of the wrong things:

<http://www.youtube.com/watch?v=AtyydlDsS5I> [video]

<comment><USER27> Great point. There is a lot of fear mongering in our society and this is only perpetuated by the media which focuses mostly on bad news rather than good news.</comment></comment>


Two More Things to Unlearn from School - <AUTHOR> http://www.overcomingbias.com/2007/07/two-more-things.html

<comment><USER2> >I recall reading, though I can't remember where, that physicists in some country were more likely to become extreme religious fanatics.

i gave up at this point. or is he being sarcastic? i think he broke all the rules in the above paragraphs in that one sentence.</comment>


How hard would it be to keep the Moon from drifting away? - <AUTHOR> http://www.askamathematician.com/2018/02/q-how-hard-would-it-be-to-keep-the-moon-from-drifting-away/ <comment><USER2> There is another possibility you could try and that is employing an electrodynamic tether.

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

As the earth's magnetic field reaches the moon a lunar space elevator tether could be constructed to intersect this planetary magnetic field. This giant wire then acts as a dynamo to convert the kinetic energy of the moon to electrical energy. By slowing down the moon you can create direct electrical current. How much current is dependant on how long the tether is and it's internal resistance. Try the back of the envelope calculations. This would be a rather large figure.</comment>


Antibacterial Cannabinoids from Cannabis Sativa: A Structure−Activity Study - <AUTHOR> https://pubs.acs.org/doi/abs/10.1021/np8002673 <comment><AUTHOR> > _All five major cannabinoids (cannabidiol (1b), cannabichromene (2), > cannabigerol (3b), Δ9-tetrahydrocannabinol (4b), and cannabinol (5)) showed > potent activity against a variety of methicillin-resistant Staphylococcus > aureus (MRSA) strains of current clinical relevance._</comment>