tuxychandru

> now I only touch nano when I need to de-crappify a vimrc file

You can start vim with --clean to fix your vimrc.

Apple gets a cut of the payments made through them and yet they provide this option to the consumers.

The FTC or the govt can force (?. I'm not a US resident and know nothing of US regulatory bodies' powers) card networks and banks to make this possible. This is exactly how things work in India, as I mentioned in https://news.ycombinator.com/item?id=36709947.

This is what Netflix's Terms of Use says, "If a payment is not successfully settled, due to expiration, insufficient funds, or otherwise, and you do not cancel your account, we may suspend your access to the service until we have successfully charged a valid Payment Method.".

A customer will be well within the bounds of the contract if they cancel their mandate through the bank, as long as they also don't expect to have continued access to Netflix.

Even in the US, there is nothing stopping the customer from closing their credit card account, except that it is an unreasonably inconvenient for the customer. It is far simpler and IMO sensible to be able to revoke consent for specific purposes through my payment instrument. So why doesn't the banking system in the US provide this as an universal option to customers? After all, this is exactly what Apple facilitates albeit at a high cost.

Why is it still the norm in the US to allow companies to charge their customers whenever they please, without the customers having any control?

In India, businesses are required to get a consent, at the time of subscription, to charge the customer on a recurring basis. This is called an e-mandate and requires multi-factor authentication to create. The card holder can cancel the mandate online, through their bank, without having to rely on the business doing the right thing. The business cannot charge the customer beyond that point, without obtaining a new mandate.

If the primary concern is the lack of a common packaging format/app store, please consider publishing to https://flathub.org/. It should solve these for you across all distributions.

Testing should also be simpler as most of your dependencies will bundled and testing in one distribution should suffice.

Signal desktop runs as multiple processes. Did you add up all their memory consumption? On my Debian laptop, Signal processes consume about 700 MB of RSS in total, immediately after starting.

This will mean a virtual memory allocation of 800 GB. Such large allocations can fail, even if virtual, depending on over commit settings.

What is the collective noun for programmers?

Merge conflict.

You can format code as "Verbatim" (Ctrl+T), and it will not be interpreted as wiki text.

Can you share some details or point to articles describing the design issues with NATS streaming?

What's the best way to get patent encumbered media working with Fedora for non Americans?

apt install ubuntu-restricted-extras, does it in Ubuntu.

This article points to an attack that applies to AES-256, but not 128.

https://www.schneier.com/blog/archives/2009/07/another_new_a...

I tried rust on this. https://github.com/tuxychandru/golang-challenge-rust/tree/ma...

It was shorter in LOC than my go version, mainly due to try!, but the lines themselves were longer. The one difference in correctness was that I forgot to close the files in Go, but RAII took care of it automatically in Rust.

How do sum types make error handling safer (without also adding exhaustive pattern matching) or easier (without adding do notation or macros)?

The point I am trying to make is that adding some features from other languages doesn't provide sufficient value without also adding other features. Adding all of them can make the language significantly more complex that you wonder whether the benefits gained are worth it.

I said 2 things in very first comment. I never claimed rust doesn't have select. This is quoted from my very first comment in this thread,

AFAIK, rust also doesn't allow selecting between a send and receive on channels. It only allows selecting over a set of receivers and even there it doesn't offer something like the default clause of Go's select statement.

Perhaps you should try to read my comments in their entirety before making accusations.

Yes I missed sync_channel, but if that is all CSP was, Java does CSP too. It has Threads and SynchronousQueue exactly like rust 1.0 will.

No the select statement of go. It is way more capable that rust's select macro.

The tone of your previous comment made me feel that this thread is going in an unproductive direction, so I'll stop here.

I was referring to select statement, not async messaging support.

I was wrong about synchronous communication. Since most rust example use async channels, I missed the existence of sync_channel.

However, even if that exists, rust's concurrency doesn't follow CSP as much as go's. Like I mentioned in my previous comment, it doesn't have a way to do everything the select statement in go does. This is not necessarily a bad thing, but rust definitely doesn't share the same concurrency concepts as go. It offers everything that Java/C++ does along with data race protection.

Speaking of data race protection, the current type system rejects a lot of very common "non-racy" code too. There is work in progress to address some of them and may be most of them will be addressed eventually.

Yes, that's what I meant when I said it not clear whether goroutines can be replicated as a library in rust "without compromising rust's core values". In fact, I mentioned no-GC and zero-overhead C calls.

Since libgreen did have massive stacks and one could not spawn 100s of thousands of tasks without changing system limits like overcommit, it was not really a comprehensive duplication of goroutines.

Rust's multi-threading most certainly is not CSP. CSP requires communication to be synchronous. Rust documentation states that send() will never block and channels have infinite buffer.

AFAIK, rust also doesn't allow selecting between a send and receive on channels. It only allows selecting over a set of receivers and even there it doesn't offer something like the default clause of Go's select statement.

Rust does have interesting features to prevent data races but it's concurrency model is very different from CSP and Go. Since the author praises Go's concurrency in the context of writing servers, it is entirely reasonable to prefer goroutines over OS threads as the unit concurrency.

This is a good read on the Go scheduler. http://morsmachine.dk/go-scheduler

Whether goroutine-like mechanism is possible in rust without compromising its core values is not clear, since libgreen attempted it and failed.

Something like async..await is in the cards and I guess rust does have plans to implemented it sometime in future, but that will require compiler support and can't be done just in libraries like you claimed in the first comment of this thread. While it will not have same runtime characteristics of goroutines, it'll provide similar benefits to program structure.

All that said, rust definitely offers a lot. I'm only contending the claim that the language is flexible enough to implement something similar to goroutines purely as a library.

It is not about whether goroutines need to be pooled. Goroutines work very differently from how OS threads. They are scheduled at the user-level by using non-blocking system calls to perform network IO on multiple OS threads. They are also partially pre-empted on function calls.

Whether goroutines need to be pooled depends on the application. For example, the default HTTP creates ones per connection and seems to be used without any problem in production at a lot of places. Creating them is much cheaper than creating OS threads. In fact, libgreen threads were faster to spawn than libnative ones in rust when it existed.

Rust and Go have different trade-offs when it comes to concurrency and each has its benefits and drawbacks.

All those deal with threads. Rust 1.0 will have multi-threading just like C++, Java, etc. It is very different from how Goroutines work and do not offer similar benefits at all (specifically for network services).

libgreen while it existed scaled very poorly and consensus among rust developers seemed to be that, it cannot be improved without compromising some of the core features of rust like no-GC and zero-overhead calls to C libraries.

Which library provides goroutine like concurrency in rust?

May be a faster safe version should be contributed. The current state is that unsafe rust takes half as much time as a safe go program in this benchmark. That is not very interesting because the benefits offered by rust are being given up to perform better, for a problem that doesn't really need unsafe memory access.

Same is the case with spectral norm. It is unsafe rust beating safe go there too.

The reverse complement program certainly doesn't need unsafe code, but the safe rust version[1] takes 3x the execution time of the unsafe rust version[2]. By comparison the fastest Go version[3] is fairly idiomatic Go without unsafe memory management and takes just 2x the time of the unsafe rust version.

Also, which benchmark did you have in mind when you said unsafe code is mandatory?

[1] http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...

[2] http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...

[3] http://benchmarksgame.alioth.debian.org/u64q/program.php?tes...

Are you referring to compiler plugins like the one providing regex! macro or is it something else?

JSON parser does return an error on empty string.

http://play.golang.org/p/DE0soRRRBp

If I have a bunch of records that need to be fetched together often and can't be dumped in a hstore of JSON column, how can I ensure data locality on disk in postgres?

Since primary key is clustered in MySQL, I choose an appropriate key. Is there an equivalent mechanism or is periodically running the cluster command the only option?