Telling a lie is not illegal by itself. Telling a lie with the intent of harming someone, especially their reputation, is another story.
2,755 karma · joined March 19, 2008
Blog: http://drhod.es Follow me on Twitter: http://twitter.com/danielrhodes
YC Badge: 0x43f54fe5ce1f8aaf134dba11ee94cdccb047b892
I agree transmission should receive extra protection. But there is no case where moderating every piece of content that flies across the internet is economical nor even feasible given the volume and how insanely difficult it is to create repeatable one-size fits all rules. However, given the amount of public discourse that exists online now, we would only see a chilling effect from changing these rules. It gets even harder when you think about something like Mastodon.
Is the current state of the world ideal? By no means. It wasn't ideal before either when media and public discourse was controlled and channeled by only a few entities. And we should expect to see evolutions in the future as well - we haven't found the happy place yet.
At the very least, it seems reasonable if large public platforms were required to be more transparent about their moderation efforts and rules so at least we can see what is behind the curtain. The lack thereof has created a lot of distrust.
My reasoning for wanting to use React Native is primarily because I think the iOS ecosystem is a real mess right now. SwiftUI is not mature, and UIKit is antiquated compared to the needs of today. If you’re just starting out, the force multiplier you get from RN is almost too difficult to ignore.
1) Even in the last couple years, React Native has gotten much better. The performance gap is not noticeable anymore. In fact, in some cases I think it has been easier get better performance in RN than using native.
2) It does feel like there was a wave where tons of libraries were created and then abandoned. But overall there are lots of libraries which are good and well maintained.
3) Native is still better if you need really tight experiences, but this gap is also closing. Since you can easily drop down to native, this issue shouldn’t be a big deal.
A few that come to mind:
1) AWS services are not easy to develop with locally. This incentivizes a lot of testing in production, which in turn can slow down development speed and increase defects. Yes there are some wrapper libraries and helpers, but it's not 1:1. (This same thing applies to Cloudflare workers as well).
2) Lambdas have constraints such as execution time limits, and a lack of fine grained control over resource usage. This makes it hard to use things like long lived requests and web sockets. But it can also mean you could end up paying a lot more compared to a fixed price setup, such as an instance in EC2. The flip side is also true: it can be an incredibly good deal as well.
3) There's a lot of tooling and knowledge around Lambda which takes some time to learn. You have to be quite careful around things like DB connections, logging, concurrency, and so on. This overhead might ultimately make things more complicated than a more traditional setup.
4) There is a maximum package size for a lambda. When you include all your dependencies in NodeJS and so on, it can become very tricky to keep things under this size in even a medium sized code base. A larger size also effects your cold start time. There isn't a lot you can do to change this.
5) Lambda's easy integration with other AWS services is both a blessing and a curse. AWS is not cheap, and given how trivial it can be to add on services, it can require a considerable amount of time to reduce spend. Lambda's integration with non-AWS services is very hit or miss (e.g. Kafka). You only find this out by getting very burned.
6) If you require anything like C libraries, be prepared to spend a lot of time working on builds and deployment - or sometimes it just magically works. You are operating inside a somewhat opaque environment, and it can require a lot of fiddling. Additionally, using tools like CloudFormation do not scale very far, and can sometimes result in quite bad outcomes. This stuff can steal a lot of time.
7) There are hidden costs everywhere. For example: Are you being a good engineer and adding a lot of visibility by logging and using tools such as CloudWatch? Be prepared to pay an extraordinary amount relative to the value you get.
8) Using lambda as a processing pipeline? Easy to get started, hard to get reliable. AWS does not have good inexpensive tools to manage these well, and you can end up with a very leaky and expensive system.
9) You would be surprised at how many bugs and weird behaviors exist when these AWS systems play together. In some cases, the only recourse was to delete the entire stack and redeploy because something got stuck. That could be quite bad depending on the use case.
10) Using lambdas over data engineering tools (e.g. Kinesis Data Streams vs Spark) might actually be more complicated. You should hopefully be familiar with and have some experience in this these tools before making a decision when its time to build.
They don't go down when there's a big ticket sale. If you've ever used these alternative ticket sites, they will struggle under the load.
The reason it is hard is because there is a flood of people all hammering your site at once, all doing credit card transactions. There's bots. There's people hitting refresh constantly.
They are lame for a lot of reasons, but they don't suck in this department. And I imagine that is important for a lot of people.
However, the reason to use JS in particular is because when you have a lot of I/O blocking calls (DB calls, web requests) it really is a lot faster. But if you do anything with numbers, JS is the wrong language - it's so limited here that it's almost laughable. Same with dates. That makes it a very bad choice for data science.
Office 365: Regardless of how you feel about Microsoft products, this is actually a fully featured online version of Word, unlike Google Docs which has a subset of the features and layout.
Notion/Airtable: A good portion of the use cases for Google Docs/Sheets (at least in your run of the mill tech company) are better served by Notion in terms of better structure, components, templates, and so on. The hacks that I have seen people do to get around limitations in Google's suite of products just to do something fairly conventional is a shame.
However, notice that Google has not said they are compliant with any regulation.
I haven't used the feature, but from reading the blog post it is sad to see how poorly Google executes on products, even at the beta stage.
Some context:
I've built such a product before and eSigs are more simple than they seem as long as you do a few things. 1) You need to verify somebody's identity. Sending them an email with the request is a valid way of doing this. 2) You need to make the final signed document easily accessible (e.g. emailing all parties a copy of the signed document. 3) You need to not obscure what the person is signing (they need to be able to easily see the entire document if they wish) 4) You need to make it possible for all parties to verify the validity of a signature, which is done with an audit trail appended to the back of the document. 5) Some types of contracts are not valid to be signed with eSign. 6) The parties need to agree to do business electronically, but this is mostly up to them.
You do not need to create fake wet signatures, cryptographically sign a document, or do encryption beyond what is necessary for normal compliance. Those are all UX or marketing features: they don't hurt, just that according to experts I have spoken to, they aren't a factor when going to court.
And then we have what Google is offering:
From the screenshots, I think it is only a fake wet signature. I'm not sure how valid that is.
Apparently you cannot ask for an eSignature from non-Gmail users right now. But how are you supposed to know they are Gmail users? Can Google not send people a simple email with a link? This alone makes the feature almost worthless, and for something that seems so trivial.
They also said they will only be adding an audit trail later this year. This is really sketchy because I believe it means you, nor anybody else can actually verify if it has been signed. Again, this is quite trivial: you store the audit trail in a database, and you append the log as pages onto the back of the PDF document.
At some point you may need to buy a new washing machine. If you knew nothing about washing machines, you might have no information to work from.
However, maybe you saw an LG commercial at some point. So now when you walk into the store and see an LG washing machine, that recognition leads you to consider it. Maybe because of that commercial, you saw a feature. Now when you look at the Samsung washing machine and it doesn't have that feature, you consider that model to be lacking over the LG machine.
A personal anecdote here: Amazon now has so many different brands and sellers with product lines I've never heard of before. Their ratings have long since lost meaning. I often find it very difficult to decide on even simple purchases because I don't have enough information to know what is good.
> Aligned with what is actually best for the consumer
This is a classic straw man.
Who said it needs to be? They are simply educating you on the existence of their product. But marketing doesn't remove your agency to decide if you want to drink them or not, or whether that product is good for you. There are products that I am aware of due to marketing that serve no purpose to me, but I am not helplessly buying them anyways. I agree that in some scenarios (like we saw with cigarettes) this can go awry, and maybe advertising should be restricted for certain types of food. But in general, most products are not like this.
> You paid them with your attention and they helped you find solutions to your problems.
If Google didn't solve a problem for you, you would likely stop using it. You wouldn't continue to use Google simply to see their ads. Their advertisers would disappear if you weren't there, so first and foremost they must deliver a good product to you.
Most people do not have a birds eye view that lets them see all the problem spaces and all the solutions. Marketing is increasing the likelihood you are aware there is a solution out there, and sales is the part where you become convinced the solution offered is the right one.
If you are in the lucky position where your company's solution is considered the standard and is widely known, marketing becomes all about maintaining that perception.
To get around this, companies do a couple things to increase the likelihood of hiring an underrepresented person into a role:
1) They will quietly try to fill up their candidate pipelines with people who match the criteria they are looking for to increase the likelihood they wind up hiring a candidate who matches.
2) They will apply the "Rooney Rule" which says at least one person from an underrepresented minority group must be interviewed for a position before a hiring decision can be made.
First, businesses aren't in the business of leaving money on the table. That is fine for a non-profit, but ultimately they need to weigh money making with customer satisfaction and growth. It's crazy to think a business should not optimize here.
Second, you're conflating venture-funded consumer businesses with B2B businesses. Consumer businesses with venture funding are typically going to fuel growth/momentum by doing things which don't scale. But eventually push comes to shove. B2B business models are usually more transparent about what is a promotion and what is not. Consumer businesses don't always know how the business model is going to play out to even offer that transparency.
Third, if your business model is advertising and data is your moat, then when you give away your data via API to promote distribution, yes you run into an issue later on when you need to advertise or you have underinvested somewhere (in Reddit's case it was mobile). For Reddit or Twitter, these mobile apps were profiting off their users/data while taking on none of the costs (infrastructure, moderation, etc.), and limiting their means of monetizing themselves. You don't need an investor to tell you that isn't in your long term interest.
Emotional vulnerability and openness is predicated on trust. If you can't trust your partner to be there when you express yourself, then you have a serious problem. Trust is the cornerstone of any relationship.
Ultimately we were making architectural decisions to please Hasura, not because it was in the best interests of what or how we were building.
My understanding is that this might have been what Apple originally planned to do. However, the popularity of the App Store, IAP revenue, and the focus on services disincentivized them from pushing this route further.
How is it different than a person reading several books on a subject and giving a speech based on what they’ve learned? Obviously if the speech was repeating verbatim what was read, this would not be acceptable. But that is not the case here.
Likewise, should the authors of books a child learns to read with be able to claim copyright over all works and language the child produces afterwards simply because their material formed the basis for that child’s neural network related to reading and writing?