All of the points made in the post mentioned are still true.

Neovim is still developed actively and the community is stronger than ever. You can see the latest releases with notes here: https://github.com/neovim/neovim/releases

Vim’s BDFL ultimately caved and released his own async feature that is incompatible with Neovim’s design that has been in use by various cross-compatible plugins for years (no actual reason was provided for choosing incompatibility despite much pleading from community members). Some terminal support has also been added to recent Vim. IMO both implementations are inferior to Neovim’s, but that doesn’t matter much for end-users.

There are still many additional features in Neovim that haven’t been begrudgingly ported to Vim.

At this point, I choose to use Neovim not because of the better codebase and modern features and saner defaults, but because of the difference in how the projects are maintained and directed.

Strong +1. Been using Bitwarden for 1.5 years now and it’s everything I hoped it would be.

• It’s open source, which is a must-have for a password manager for me.
• I used it on ~every platform (Linux, Mac, Windows, Android, iOS) and it’s more than functional–a pleasure to use on most. More than I can say for any other password manager.
• It’s a tiny team (of ~1?) but it’s very active and has solid contributions from random people. Responses to issues are prompt and effective.
• There are several independent backend implementations (in Rust, Go, Ruby that I’ve seen, probably more now).
• I’ve read through big chunks of the code and it seems solid–something I could contribute back to. My only complaint was that the sync API was designed to do separate requests per entry, so some metadata about the number of entries does leak unnecessarily. I haven’t checked if that was fixed, but it’s fairly minor.

Overall the experience has only improved. I’m sure it has a bright future.

Thanks for introducing me to this, it’s about what I am looking for. Time to ditch manually synced (& merged, of inevitable forks) KeePass.

Can also recommend Bitwarden, I have not tried the desktop application, but the mobile version on Android and browser extensions have worked without any issues for me so far across different browsers and operating systems.

Edit: Apparently, I posted the same comment twice, my mistake.

Is this one open source?

I think it would be simple to use this tool in conjunction with S3/Cloudfront. I use Jekyll to build a local version of my site and then s3_website to push it to AWS. I like that the tool I use for building the site doesn’t tie me to a particular hosting strategy. (AFAICT the linked script only uses rsync to build the site locally in a target directory, not to deploy it to some remote host.)

+1 to Hugo, I’d say “pretty fast” is underselling how ridiculously fast it is (at least compared to other popular static site generators).

Re: why not S3+Cloudfront?

I started with this a while ago. The problem is you end up using something like Route53 to get your custom domain and TLS, which ultimately ends up costing you $2-3/mo per domain altogether, which adds up pretty quickly when you have a bunch of domains. Not to mention the ordeal of managing AWS and their massive dashboards and weird config syntax.

These days I use Github pages + Cloudflare for DNS/TLS in their free tier. If I were up for migrating again, I’d consider using Netlify which is great by all accounts and supports some basic dynamic forms that are handy for static sites (contact form, etc).

Very much by design. Then chat layer is built on top of a networking layer that is basically a DHT of nodes. I based this part of the project on the design of the Mainline DHT outlined in BEP 5.

The network layer is self-bootstrapping, and self-healing. It provides a minimal interface to send a “packet” to any address in the network. It only guarantees that it will deliver that packet as closely to the intended recipient as it can. All the relaying, message acknowledging, etc lives in the chat layer on top of that.

Glad you could recognize the design. Thanks for looking!

I encourage you to make this suggestion on https://github.com/golang/go/issues/19412 which was recently marked as “For Investigation” which suggests someone is collating ideas.

Which you get with a (full) RSS feed.

The built-in Firefox Reader mode is a godsend. I feel much more comfortable reading long texts in the same font, page width, background color + the scrollbar on the right now gives me a pretty good estimate of reading time.

RSS, lightweight versions (light.medium.com/usual/url ?), heck even gopher, perfectly does the job! we need these things.

People often include google analytics without really thinking about the privacy implications, just because publishing blind is so annoying I suppose. Is there a better alternative?

I’ve been using Bitwarden for about a year now and it has been great. Works on all platforms and it’s open source—and people are actually contributing. The code looks reasonably clean, well organized, and the author is quick to respond and fix any problems.

While it’s not quite at feature-parity with 1Password, it’s well beyond an MVP password manager, and new features are added regularly.

Overall, I recommend it.

Very nice! Are you putting together a proposal to get some of this merged into x/crypto? (I saw some discussion on golang-dev.)

Hopefully yes, but the goal is to get people using this first

Somebody was mean and “fuzzed” by shoving dev/urandom into it.

Damnit lobsters, this is why we can’t have nice things. >:|

I dont think the person who sent the PR did anything wrong. Guy was just ready to blow.

I hope he doesn’t start getting more comments like this. Guy gives away free work for like almost 5 years (based on git commit logs), and some random person (with an amazon wishlist as their github homepage link no less!) comes out of the woodwork to inform him how he should feel. eye roll

I respect that you feel that way, and if you think I’m spreading FUD you should highlight it and point it out. Waving your hand and calling it all FUD is disingenuous (EDIT: I see you stealth edited your comment to add an example, see next reply). When I said Mike was spreading FUD, I substantiated it with reasoning.

Likewise, if you feel I’m being one-sided, feel free to point out anything that I’m ignoring or not addressing.

Finally, perhaps you missed the comment, but I have no intention of bringing this issue up anymore since the threat seems to have subsided and all that’s newsworthy has been said.

I wouldn’t have downvoted if you hadn’t invited me to, but if that’s how we’re collecting views this time…

I don’t really want to share an opinion, but I disagree; @itistoday’s campaign has been informative and helpful. To the extent that I’ve felt pressure to take a side, it’s been from the other one, but actually Lobsters has been pretty good at keeping this polite. Maybe my expectations are calibrated weirdly as a result of caring about the culture tag; I don’t know.

This post dismisses lightning.network without good reason for doing so.

That’s not true, he addresses it specifically and links to a more fleshed-out article he wrote on the topic in May. Quote with emphasis added:

The so-called “Lightning network” that is being pushed as an alternative to Satoshi’s design does not exist. The paper describing it was only published earlier this year. If implemented, it would represent a vast departure from the Bitcoin we all know and love. To pick just one difference amongst many, Bitcoin addresses wouldn’t work. What they’d be replaced with has not been worked out (because nobody knows). There are many other surprising gotchas, which I published an article about. It’s deeply unclear that whatever is finally produced would be better than the Bitcoin we have now.

It doesn’t seem like he’s completely opposed to a solution like the Lightning network, it’s more that he doesn’t believe that raising the block sizes is mutually exclusive with the implementation of an off-blockchain payment channel solution. The biggest complaint is that it’s not plausible that such a solution will be ready within a reasonable timeline, compared to raising the block size which is addressing a relatively imminent concern.

I’m a total outsider, but he mentions that lightning has yet to be fully worked out, and says that those familiar with capacity planning in this domain are strongly urging rapid action. I don’t know how relatively hacky the alternatives are, but in the short summary you linked to it seems that none of them are without drawbacks.

According to him, SOME action is required in the short-term to stay alive. How much relative support do the approaches you mentioned have, and how soon could they be implemented to prevent short-term network breakdown?

By fork, it means that—if accepted by the 75% super-majority—it’s going to “split” from the existing ledger. At that point, balances on both forks would be identical but any transactions on the respective blockchain will diverge henceforth.

If the fork goes through, then anyone still using the old blockchain will be getting data that is no longer accepted by the new blockchain.

Aside: The Bitcoin XT client is structured in a clever way such that if you do upgrade to using Bitcoin XT but the fork does not pass, then it continues to be in-sync with the original blockchain and there is no interruption. The interruption scenario only happens if you stay on the Bitcoin-core client.

Ok it collapses the root comment as well.

It’s a tough book, but a lot of fun. I think the reason why it’s not completely graphics oriented is because the first part was taken from his other book “The Zen of Code Optimization”. Later on in the book it focuses on graphics programming.

The threat is the persistent and pervasive burnout amongst people working on projects that are OMG-level critical to the tech sector. A lot of people are starting to step back from major projects like Python, Postgres, Django, Ruby, etc, and that’s going to have an impact. Most of the people leaving are the ones that feel like what used to be a hobby is now a full-time, unpaid job. If we don’t figure out a better way to support those people, we’re going to have a bad time.

It’s worth considering that today much of open source is created largely by people in a very substantial position of privilege. People like myself who can afford to be self-employed or not even get paid at all for extended periods of time. Some maintainers are those who got lucky with an employer who permits them to spend some amount of their time on open source work.

And the effect? We in a position of privilege gain yet more privilege. Because of my open source work (and the ability to do it), I get way more interest from eagerly-hiring companies than any of my friends without a Github repo. I gain more public respect and recognition because I can afford to do this. It gives me the luxury of being a lot more picky.

Free software may be flourishing, but who are the maintainers and contributors who are flourishing with it?

Having more options for funding open source enables a greater diversity of people to participate, and I think that’s a good thing for both software and people.

Thanks - exactly my own feelings on these topics, but I’ve tried and never been able to say them very well.

None of this new stuff is really well documented at this point (so forgive me if I make a mistake) but as I understand it, the runtime is spawned on its own thread(s) the first time the library is called into, package init runs (but main is not executed), and then the called function is executed. The runtime will manage goroutines across threads (‘P’s in the runtime nomenclature) like normal, and these continue executing independently of Rust threads. I also have a hunch that each time Rust makes a Go call, some kind of thread context switch is required so that the function can be called on a new 'G’ (goroutine) the same way it currently works when Go code makes a C call using cgo.

I did get a simple toy program running that used a channel returned by Go to receive integers and print them from Rust. I added the following Go functions:

//export CounterTo
func CounterTo(max int) <-chan int {
        c := make(chan int)
        go func() {
                for i := 0; i < max; i++ {
                        c <- i
                }
        }()
        return c
}

//export RecvInt
func RecvInt(<-chan int) int {
        return <-c
}

And here was the Rust code: http://sprunge.us/jUVi

All of the usual memory management caveats apply. Memory allocated by Go cannot be safely passed across the C boundary without retaining a reference to prevent it from being collected and causing a use-after-free. I made this mistake with my channel example (and it’s a good thing I had not pushed that code yet), since the counter goroutine would exit after the max was reached and the channel could be collected, making recv unsafe to call on the Rust side.

Another bummer for me is that these new execution modes only seem to be supported on linux/amd64. This is unfortunate in my case, as I had wanted to use this to integrate Go code into a .NET Windows GUI application. Since I believe Go 1.5 is in feature freeze at this point, something like this may have to wait until 1.6 or later.

I thought I’d post my standard readme, btw. :) I’m particularly proud of the “except for the parts that aren’t” wording.

Experimental Code

This source-code repository is published here in the hope that it will be useful or at least interesting, but is very likely to be in an unfinished state, and not necessarily a consistent one, either.

The sole representation is that (except for the parts that aren’t), this code is authored by me - Irene Knapp.

If the repository contains information about its own licensing, that information is normative; otherwise, all rights are reserved and it is provided for information only.

If you do something that requires me to write a better disclaimer, I will be very irate.

I feel like “hand crafted for awesome” is a promise that the code will be a psychedelic experience, which is pretty much the opposite of a promise that it adheres to principles of quality engineering. :)

Here’s a thing, maybe it works: https://github.com/choongng/objc-tidy

I posted it earlier but in my exuberant rebasing I accidentally deleted the source (now fixed). The thing that would make me happiest is if someone put this functionality into clang-format but in the mean time if you have an Objective C codebase the combination of the two can help tidy things up.