naiyt

I disagree, I don't want my project to successfully build at all if I have type errors.

Wow, this is fortuitous for me. I've been wanting something like this for quite some time, and was literally just thinking about it this morning. I've had a lot of ideas for certain small side projects that have ended up dead in the water, because I really didn't want to even risk being liable for the type of user data I would be storing.

This solution is perfect for an application that's targeting privacy focused users. I often don't sign up for services these days because I don't care for the possibility that the maintainer of the site is just casually reading through my data.

Some great use cases could be journaling, note taking, a private wiki, etc. For note taking, I actually use Standard Notes (https://standardnotes.org/) precisely because of its end to end encryption.

For me the lack of password reset is a non issue (especially with modern password managers), something that I gladly trade for the peace of mind that some random developer with database access isn't reading through my private stuff. Obviously if you built something on top of this, you would need to properly educate your users on the tradeoff they're taking.

The real downside to beetus is having to think about it constantly, IMO

Pretty much this. Obviously needles and finger pricks are a bigger deal for some people, but most diabetics get used to it fairly quickly. The hard part is the constant mental drain of having to be your own pancreas. It's like you're constantly flying a plane where you have to manually maintain a certain altitude, because you'll crash and die if you fly too low or too high. It's exhausting.

Thanks for details. Here's my response to most of them (some of this is definitely anecdotal of course).

- Slow debug cycle due to increased compile time. If using TDD, it takes longer to run tests. The delays adds up.

I've not personally encountered any significant compiling overhead in comparison to a regular Babel ES6 transpile. Obviously depends on project size, but there are a lot of tweaks that you can do to speed it up. I've had good luck with ts-loader.

- Sporadic source mapping issues/bugs which makes it hard to fix things (I had an issue with Mocha tests last week where it was always telling me that the issue was on line 1). I've worked with TypeScript on multiple projects across different companies but every single time, there has been source mapping or configuration issues of some kind.

Are you advocating ES6 instead of TypeScript? It seems like all modern JS hits a transpilation stage before it hits the browser these days, and I see the same source mapping issues whenever I use ES6/7 with Babel + Webpack.

- Type definitions from DefinitelyTyped are often out of date or have missing properties/methods. It means that I can't use the latest version of a library.

Fair point, although I haven't run into this much myself.

- Third party libraries are difficult to integrate into my project's code due to conflicts in type names or structural philosophy (e.g. they leverage types to impose constraints which are inconsistent with my project requirements).

Not sure I follow, do you have an example?

- Doesn't guarantee type safety at runtime; e.g. If parsing an object from JSON at runtime; you still need to do type validation explicitly. The 'unknown' type helps but it's not clear that this whole flow of validating unknown data and then casting to a known type adds any value over regular schema validation done in plain JavaScript.

I mostly agree with this, which is why my strategy is just to do regular JS style schema validation where necessary, and then cast the object, rather than relying on `unknown`.

- Compiler warnings make it hard to test code quickly using console.log(...); I'm more reliant on clunky debuggers which slows me down a lot and breaks my train of thought.

Not sure I fully follow. If your code compiles to the point where you can use the debugger, you should have been able to use a console.log as well, right?

- Whenever I write any class/method, I have to spend a considerable amount of time and energy thinking about how to impose constraints on the user of the library/module instead of assuming that the user is an intelligent person who knows what they're doing.

If you're writing code used by others, you need to be clear about what your API expects and allows anyway, so why not be explicit about it, in a way that the compiler can enforce? An intelligent person makes mistakes, so why not see if you can give the computer the ability to catch some of those for you? And TypeScript still gives an intelligent user the ability to supersede your type restrictions if they absolutely need to.

- It takes a lot of time think of good names for interfaces and they are renamed often as project requirements evolve. It's not always clear whether similar concepts should be different types or merged into one. It often comes down to what constraints you want to impose on users; This adds a whole layer of unnecessary mental work which could have been better spent on thinking about logic only.

I don't think coming up with good interface names is more difficult than good class or method names. And I'd argue that thinking about the constraints you want to impose on users is important for developing maintainable code -- whether you're doing type checking or not. And ultimately those constraints still have to exist in some manner, but without type checking the "constraint" will be the code breaking in some undefined way. By doing so you save yourself and others the mental overhead of trying to figure out what types you're dealing with at any point in your code base, or what types you're expected to pass into any given function. The initial overhead of thinking about your types pays off quickly.

- Setting up TypeScript is a pain.

Anecdotal, but I've never had much of a problem with it (for React users, I believe you can get it for free in create-react-app now). And it's a one time setup cost anyway.

Have you used TypeScript 3.0? They improved the type errors a lot. I'd highly recommend giving it another shot.

One interesting thing about Dark Souls is that there is quite a bit of ambiguity around what the "age of dark" actually implies, and there's a lot of hints that it might actually be a beneficial state for humanity.

Personally I found Bloodborne to be even more hopeless. It's all based on a Lovecraftian view of the universe, where we're completely insignificant next to these higher order beings and concepts. There are also almost no happy endings for any of the NPCs, which contrasts with Dark Souls a bit. But again, that's a really good translation of Lovecraft into video game form!

Yes, but you still need insulin on keto. In fact, starting keto can be dangerous for a T1D at first until you find out what your new, lower, requirements are. You put yourself at risk of hypoglycemia, so you have to be extra careful with dosing while you're figuring it out. Because of that, a closed loop artificial pancreas could be incredibly helpful for a T1D going on keto as well.

The article WAS focused on type 1, though, where there is no cure, from diet or otherwise. It's absolutely revolutionary for those of us with type 1.

The era of the intelligent cloud and intelligent edge is upon us.

I still have no idea what "intelligent edge" is supposed to mean.

For me it would have the same things that make Typescript appealing:

- Full access to a large and mature ecosystem (one that Crystal doesn't quite have)

- The ability to gradually add typing to an existing Ruby codebase. No need to rewrite an entire application. Just gradually add types to new code and during refactors.

If I was starting a new project I would definitely be considering Crystal, but I still feel like something like this would be great. Typescript has been a godsend for my frontend development life, and I would love to have something like this for my backend Ruby development.

i fail to see the benefit of a language like Crystal.

For me it's a Ruby like language with static typing. For my typical use cases I don't really need the extra performance, but those two things are enough to make me interested.

I've been a fan of Ruby for about 5 years, but lately I've been leaning a lot more heavily towards statically typed languages. Which is why Crystal is at the top of my "want to learn" list. Ruby inspired syntax and statically typed? Yes please. The speed is just a bonus for me.

5% for conservative and 7% for aggressive would have been better choices...I know the goal was to make this calculator simple, but those values should have be configurable with saner defaults.

Busy busy busy

I'd recommend trying out create-react-app if you want to learn React without having to worry about all the build tooling craziness. Eventually you'll have to start fighting with those if you build some real life stuff, but create-react-app is great for just getting up and running so you can learn the actual library (the fun stuff) first.

Good point, I wasn't really thinking about styling 3rd party components. styled-components makes it sort of okay, but still feel hacky.

styled-components are actually really nice, so I don't think it's fair to say "styling is React's worst part". This seems like a more general criticism of React's agnosticism when it comes to so many things. React falls more heavily on the library spectrum than the framework one. It's rather un-opinionated about a lot of things: styling, state management, routing, code organization, etc. Definitely not something that's unique to styling.

On the one hand this offers a lot of flexibility to do things the way you want, but also makes the learning curve a lot steeper. Honestly I would love for somebody to build a more full fledged framework around React that makes most of the decisions for you. A sort of "good for 90% of use cases" setup. (I guess create-react-app is sort of like that? You still have to make too many decisions, I think.)

two way data binding

Maybe it's better in Vue than it was in AngularJS, but this seems like a downside to me.

This is the first I've heard of it. What, in your opinion, makes it so much better from a developer experience perspective?

Believe me, I'm more than aware of the negative side effects and potential dangers (especially with Xiidra, which is a new medication without long term studies). Xiidra is costing me about $200 a month, after insurance. But in my case it was literally the last ditch measure, because I had tried everything my ophthalmologist suggested as well as every "home remedy" out there. (When you have severe dry eyes stuff like yawning is not going to help.)

For me, Xiidra has been the only thing that's given me relief. The side effects have been fairly minimal (stinging for a minute or two, somewhat blurry vision for up to 20 minutes) and my life is mostly back to normal now. But the cost and lack of long term studies of the medication prevent me from recommending it unless you and your ophthalmologist have determined that there are no better options.

Nope, never took Accutane. I got a full examination from a specialist (including a LipiView analysis) and the conclusion was that I don't have MGD. My glands look mostly fine, and my issues stem primarily from inflammation as a result of the factors I mentioned (working on the computer, dry climate, diabetes).

I've had a lot of issues with dry eye, largely related to my computer usage. (Although it's sort of a combination of 3 factors: I work on the computer, I'm a T1 Diabetic, and I live in a dry climate. All contributors to dry eye.) At times it was bad enough that I could barely read what was on the screen, or I would leave the building and have to sit in my car for 5 or 10 minutes before driving home because the sunlight was causing enough pain to keep my eyes closed. It was impacting my life significantly.

Here's everything that I tried, along with a comment about how well it worked:

- Switched from monthly contact lenses to dailies (Helped moderately, but at that point my eyes were getting worse fast enough for me to not notice a real difference

- Switched from contact lenses to glasses (Helped with comfort once I got used to glasses again, but not with dryness)

- Various OTC eye drops (Retaine MGD is still the best for my eyes, but overuse seems to make it worse)

- Eye doctor prescribed a 2 week steroid eye drop regimen. (So no difference)

- 10 minute warm compress on the eyes twice a day (This helped a lot when done consistently, but my eyes were still really bad throughout the day)

- Omega 3 supplements (Seemed to help a bit when I was consistent with the dosage)

- Various eye exercises (helps a lot, but I HAD to be consistent for multiple days before seeing results)

- Restasis (no benefit after 3 months)

- Xiidra - okay, so this has given me the MOST relief out of anything, even consistent eye exercises. My eyes actually feel normal again, and I saw results after just a couple weeks. Using a new medication kind of makes me nervous, and it's incredibly expensive (even with insurance), but I got to the point where I was willing to take the risk because I was getting desperate. Having severe dry eyes can negatively effect every waking moment.

I'm hoping that after a few more months on Xiidra my gland inflammation and tear composition will be in a good enough place that I'll be able to stop using the medication (which I'll be following up with my eye doctor about soon).

If you're just getting started with a career on the computer START TAKING CARE OF YOUR EYES NOW. Take frequent breaks and perform frequent eye exercises. Hopefully that will help prevent you from getting to the place I did, where it takes a significant amount of work and money to get back to having healthy vision.

They addressed this argument in the article, and why smartphones are inherently different than TV (or any number of other distractions that people have worried about in the past).

After reading that it sounds like they just haven't been able to reproduce the process of making it, not that it's an alloy that they don't understand the composition of.

Have you considered audio books? That's the main way I consume fiction these days. I love listening to audio books while doing other things (commuting, cleaning, going on walks, etc). It's a good alternative (or companion) to listening to music or podcasts. Looking at my Audible library I've listened to about 27 books in the past few years (most of them fiction).

Yeah, I also got misdiagnosed as T2 (at 23). Too many doctors still immediately jump to a T2 diagnosis if you're not a kid anymore. There's a reason we don't call it "child onset diabetes" anymore.

I'm glad she got that full story posted on Vice, I hate having to scroll through long Twitter chains to get a story.

If people can be productive and efficient with VSCode or Atom then it's not the wrong tool at all.

There's a serious lack of engineering accumen among the users of Electron

I'm not a fan of Electron, but I don't see this correlation at all.

The distinction is absolutely significant. It's all about expectations. The originally promised "HL2:Episode 3" didn't need to be some huge revolutionary product, just a satisfying conclusion to HL2 and its episodes, while setting up the scene for the next game. As soon as people start saying "HL3" they expect some grandiose, ground breaking product.

The story laid out here by Marc is much closer to what you would expect from Episode 3 rather than HL3.