seeekr

Svelte support in the Jetbrains family of tools is great (IDEA, Webstorm etc). There are a few issues, but they're all minor. Started using Svelte for serious work a few months ago, very happy with it, best frontend framework I've worked with thus far.

2 weeks is probably not enough, right? Assuming that it would be feasible for everyone to stay home for 100% of the time, that would still leave everyone in contact with N (avg number of people per household) minus 1 people, so for the isolation period to be able to eradicate a disease, in the worst case of each of those N people getting infected one after another instead of in parallel or all at the same time, that period would need to last for (N - 1) * (incubation time + period of possible infection), or something along those lines.

EDIT: grammar

What you're asking for already exists. The certbot package already takes care of that [1]. No need to develop anything extra for nginx. [1] https://certbot.eff.org/lets-encrypt/ubuntuxenial-nginx

Not a mirror, it was forked initially from that repo 2 years or so ago when the codebase had just roughly 20 commits, and it the contributor graph shows it is indeed basically just Dustin working on this.

While looking at the tool I've realized that I've built something similar many years ago. I wonder if it's worth digging up the source code, polishing and publishing it. Does the market need more of these tools? Are there features in this type of tool on the market that seem to be completely missing or inadequately implemented?

And it's likely that running these as a server-side application is ultimately more appealing than this simpler (to implement) automation inside the user's browser, right? Seems that many companies providing similar (server-side) scraping tools have been successfully sold off... Is that an indication of (still existing) high demand for these?

EDIT to add: The tool and the accompanying website look fantastic, by the way. Congratulations on the 1.0 launch, Amie!

"Be the first to experience Burnout before everyone joins in." -- Brilliant! I hope it indeed turns out to be satire...

Does someone know what the state of the RN rearchitecture effort is? And is there likely going to be a smooth upgrade path forward without much breakage across the ecosystem?

It feels like he could have said that about any of the relevant frameworks. They're happy they've started down the cross-platform path using one of the solid available alternatives -- good on them!

Note for others also unsure of this: `rustup update` also does the self-update step, only after it first updates the toolchains.

IntelliJ IDEA actually just collapses them into lambdas by default. And it also auto-generates them for you so you don't have to type them. At least that was the state of things a couple of years ago, can only have gotten even better since then.

First sentence in the introduction:

> Hi, we are a team at Microsoft called Bling (Beyond Language Understanding), we help Bing be smarter.

This RFC has an explanation of Higher-Kinded Types that enabled me to understand what is meant by HKTs for the first time. Unexpected & awesome! Thanks for linking!

Worth noting though that Figma is developed in C++ and compiled for the web, and they've stated that they're using Electron for the native apps for now, but it would certainly be thinkable and straightforward to switch to properly native apps.

A notable and reasonably thorough investigation into the state of the C++ lifetime checker as of June 2018.

What I took away from this is the impression that the work on the lifetime checker is incremental and the tool was able to deal with a certain complexity of cases, but beyond that backed off and produced either false positives or negatives.

Roughly speaking, the author found edges of the checker implementation around code "hiding" from the checker in functions (ie. missing inlining capabilities), or const& in combination with either typedefs or vector operations, temporary value lifetime extension rules, and some others.

It seemed that in general the lifetime checker was already working in terms of the fundamentals of the C++ language, but it needed more work in order to be able to "see" through all intermediary function calls and as such also be able to handle cases involving standard library types, which any user of the tool would expect to be understood perfectly.

The more you build, the more you realize how many more things haven't been built yet and you might want to build after the current one(s)... ad infinitum.

The README says:

"Cranelift is designed to be a code generator for WebAssembly, but it is general enough to be useful elsewhere too. The initial planned uses that affected its design are:

WebAssembly compiler for the SpiderMonkey engine in Firefox. Backend for the IonMonkey JavaScript JIT compiler in Firefox. Debug build backend for the Rust compiler."

If anything, then the complexity is getting less, not more, as the team as well as the ecosystem are very much focused on making things simpler and more approachable and are very aware of any existing, potentially unnecessary complexity. As an example, the borrow checker is currently undergoing a major (internal) revision and will allow you to write some things in the future (and even now, at least on nightly Rust) that its old implementation was not so sure about and thus complained about. Another example: async/await syntax is coming, along with improved futures, that will make it much easier to get started with async/io programming.

And it was originally developed by ThoughtWorks and looked fairly geared towards Enterprise and was not Open Source, originally. They open sourced it in early 2014 [0].

[0] https://www.gocd.org/2014/02/25/go-moving-to-open-source/

I'm currently working on this tool as part of moving a set of semi-legacy services from what my client calls "puppet hell" to a well-structured, easily manageable k8s deployment. The goal is for the client, not being a k8s nut themselves though having decent devOps experience, to be able to understand and manage all relevant aspects of the setup completely themselves.

For our current uses the tool is almost sufficient, and generally works, but it is nowhere close to being fininshed in terms of what I envision for it.

The state of documentation is very rough (ie. basically nonexistent for all practical purposes), but if there's interest AMA and I'll respond and write up more documentation. Just not sure how much interest there is for that at this given point in time.

Re LOC: Found the 988k LOC number hard to believe, so I checked. If you count the vendored dependencies, then it's indeed a lot, about 1M LOC. Traefik itself though is comparatively a lot less at about 60k lines of Go code with another 8k or so of scripts, config etc.

(2013)

Correct :) The release of headless mode for Chrome is what inspired the whole service, which the name aims to reflect.

Wasn't their public reaction as it was due to liability concerns? i.e. if they admitted that something was wrong with their chips, they may have gotten into significant legal / financial trouble?

I believe it is quite clear to many of us familiar with the space that Microsoft is not some small-time backer of the Linux Foundation and other, related organizations. I certainly did not feel the least bit of an attempt to downplay MS' financial contribution in light of the subject of the conversation.

Hi HN friends,

I've built a little tool [1] that makes it easy to create screenshots and PDFs of your own websites/webapps. It's a use case I've found in a friend's web project, decided to SaaS-ify it for them in order to lower the operational burden of yet another service that they would otherwise need to run. I decided to keep it completely CLI-only in terms of its interaction model from a user's perspective, even though I could have made a website and a login and some kind of dashboard etc -- intentionally keeping it lean and focused, trying to make the UX as simple, automation and gitops-friendly as possible, excited to see how that's going to go.

Please give the service a try if it's something you think might be useful to you. Your feedback will be highly appreciated!

[1] https://github.com/hdlss/hdlss

fly.io is aimed at very different use cases. It is essentially a programmable CDN, and priced like a CDN, too ($0.10/GB traffic). You would not enjoy the bill for trying to serve all of your video content through it, and you also don't get disk-based storage from them, as far as I can tell. They only have memory-based caching, which could be fine for caching the hottest of the hottest of your video (or images), but for anything else paying $6 for 100MB of cache, or $60 per GB per month, would make for insane costs.

Vimeo is not an appropriate solution for the use cases that I have in mind. I don't think Vimeo would be fine with serving dozens of TBs of traffic for you, or storing many TBs of video content. Vimeo is aimed at professionals and companies who use video as basically a marketing tool, or communication tool, or who produce very little but very high quality video that may be shown to lots or few people. But it's not meant to be something like a platform for you to build something like your own Vimeo/Youtube, where your users upload (lots of) video and also consume lots of it. Case in point: Their "business" offering website speaks about a total of 5 TB of max video storage that you get, and you get tools from Vimeo to manage that video manually. But if you're building a video platform then you need APIs first and foremost, as well as basically unlimited video storage, ie. pay by use or similar.

But if you still want to compare apples and oranges here -- yes, cheaper, or at least comparable in price, just aimed at a different (much larger scale) use case.

Hetzner for storage and traffic, Scaleway for serving additional traffic for free, to stretch the dollar further. At 5TB you probably don't need anything but the raw file system yet, but if you do want some redundancy you could add something like Gluster on top. I'm building out a video + image processing + CDN-like aspects solution on top of such a setup and plan to offer it as SaaS in the not too distant future. Idea is to make something a lot cheaper (order of magnitude?) than currently exists on the market -- for a lot of ideas and opportunities I come across using any of the non-budget clouds/hosting providers is just not feasible financially.

So that means that the synchronization cost would only be paid when making a new copy of the Arc and releasing each of those. Ok, that extends the set of use cases where it's acceptable to use Arc then. Thanks for clarifying.

EDIT: wording

But isn't it an anti-pattern to wrap something in an `Arc` when some of your use cases for it are purely single-threaded, and as such you're wasting a certain (potentially very significant) amount of performance on upholding memory visibility and such even when it's not needed? I have only dabbled in Rust, so I may be misunderstanding the implications of Arc and how it is implemented, and how it behaves in the absence of multiple threads. To me it feels a bit like some of the relatively early Java days when even the Standard Library was using `synchronized` (which is of course way worse than `Arc`) in lots of places like StringBuffer (used for String concatenation), just to be safe in case anyone ever wanted to use that code in a multi-threaded context. Only later folks began to realize that maybe that's not such a great idea and that you need to be able to not pay any synchronization costs when you know you're not going to be sharing a data structure across threads.