Hacker Newsnew | past | comments | ask | show | jobs | submit | greentrust's commentslogin

I'm a member of the beta. The Slack group regularly sees influxes of hundreds of new customers, many of who seem to have signed up from the waitlist.


What if, and bear with me, strong AI poses real dangers and open sourcing extremely powerful models to everyone (including malicious actors and dictatorial governments) would actually harm humanity more than it benefits it?


And now its restricted to only the malicious actors and dictatorial goverments that can buy it!


This is exactly the defense I kind of expect them to use when AGI finally is realized (whether or not it ends up true).

"Oh, we said we're open but this is too dangerous to publicly release; we'll be licensing it exclusively to approved customers instead."


> (including malicious actors and dictatorial governments) would actually harm humanity more than it benefits it?

I'm really glad that weapons aren't open source. Imagine every dictatorship would get their hands on weapons. Luckily, it's hidden behind a paywall. /s


Facebook is the creator and maintainer of the most popular web framework in the world (React). This certainly doesn't mean they should do cloud computing, but let's not downplay their favor amongst developers.


React is a piece of code that is versioned which the developer has full control over. A cloud service would be entirely controlled by Facebook, meaning your business can be bricked by Facebook on a whim, as has happened to many Facebook-hosted apps in the past. There's a reason why few take Facebook seriously as a developer platform these days.


Frameworks and Infrastructure tend to get chosen by different people with different requirements though.

"Move fast and break things" is okay/great if you can control the deployment of code and use tests to make sure it still works how you expect it to. It's less great if the infrastructure keeps failing (it's not failing, it's changing!) and you can't test before the roll out.


Ubiquity of a library/framework doesn't translate to trust or favor among developers. Just look at Oracle.


Oracle has a very significant cloud business:

$26.7B in 2019

https://www.forbes.com/sites/greatspeculations/2019/06/21/or...


Yes, they do, but not because developers like them. They are infamous for their super strong targeting of C-level for sales.


The correct statement is some developers don't like Oracle. As for their business tactics, every business has to find viability in its own way. Obviously Oracle is providing services of value if they are able to consistently turn a profit on revenue in the tens of billions per year. This doesn't really answer the question why Facebook is not in the cloud business.


> Obviously Oracle is providing services of value if they are able to consistently turn a profit on revenue in the tens of billions per year

Not obvious; Oracle is known for underhanded marketing and lock-in. Or if you prefer: Successfully selling to the C-levels doesn't mean that you provide actual value.


Right, because C-level types are just spending $30B a year on Oracle services for zero value added. You shouldn't take your own opinions on a provider's services too seriously. No doubt there are some practices that are subpar but like any competitor in a crowded marketplace, there are going to be trade-offs between cloud providers. If the trade-offs between price, features, and value align with the needs of an organization, they will choose Oracle. That C-suite and devs have different needs shouldn't surprise you. There's always going to be some tension between those two groups, because their perspective on the business is filtered from a different set of parameters. That tension, by the way, will necessarily create a demand for different services and functions in the marketplace. You may not personally like Oracle, but don't pretend that some people don't, and don't imagine for one moment that it's purely out of ignorance.


Are you referring to Java? Sun was beloved.


Products and services have a very different risk profile. With products you generally can vet a lot of risk up-front, with services, you have more risk tied to future activities.


No, developers don't like React because of an infrastructure supported by Facebook. React is entirely selfhostable, and only as secure as your own dev environment. Built as an open sourced tool, with major contributions from thousands outside of FB.

You can't compare the two and their safety anf 'favor among developers', devs also fought against FB by having them change their licensing bc FB made the horrendous decision to essentially own any and all projects developed on it.

Devs don't trust facebook, such as no one should.


Please don't speak for all of us. I for one think Facebook being involved with React is absolutely a good thing.


Is the cost really that high? For the vast majority of projects, all developers will need to do is run "yarn prettier".

We can't expect everything to be perfect on day one, nor should we be stuck with the poor choices we made when starting a project. Maintainers should be allowed to change their mind after careful consideration and community consensus.


Part of the calculus for the cost is losing the immediate utility of git blame once every file has been reformatted.


Configure your git blame to ignore cleanup changes.

https://www.moxio.com/blog/43/ignoring-bulk-change-commits-w...


This changes everything. Thank you!!!


If GitHub doesn't automatically support the feature (article says it doesn't) I don't think it'll be very useful for many teams.


If you can use GitHub but not Git, I'm not sure you can really say that you know version control. Fine for designers who are just helping out in projects and don't really know to but developers who manages merges, backports and alike should really know the insides of Git, not just the GitHub GUI.


git 2.23 isn’t that old - seems like something that GitHub could support in the future


Thanks for sharing this. This issue is holding so many code bases behind.


--ignore-rev: https://www.moxio.com/blog/43/ignoring-bulk-change-commits-w...

Personally tho I haven't had an issue navigating back another revision. UIs are good at handling that kind of interaction, and I rarely use blame without a UI. (nearly every other git interaction: CLI all the time. but not blame.)


The loss is a bit of convenient tooling but it can be replaced with some slightly less convenient tooling. It's not going to be an architectural limitation and you can treat it as a relatively simple per company/team/project tradeoff.

Especially when working with syntax heavy compiled languages like Rust, autoformat on save frees me up enough mental capacity for me that the costs are well worth it for the extra development speed. I just use Git Lens and some custom git aliases to get around the messy logs, whereas my last team handled the payment frontend for a large company so tracing the history of changes was taken way more seriously and reformatting someone else's code outside of organized refactorings, let alone autoformat, was disqualified from the start.


This used to have no value to me. But years into my career I discovered that I can't live without it. Detective work on the history of code is vital to truly groking why things are the way they are in code bases.


It will likely conflict most in-progress PR. For PRs that are large and long lived it will be a PITA to maintain and will further slow integration so, likely, yes.


I ran formatters on a largish codebase over Christmas when all the PRs were done. You just have to pick your moment. If it's really hard then get everyone to agree on a date to do it and make it each developer's responsibility to either merge before or rebase after the change. It can be done.


Some team in my old job use to have a term for this - "grabbing the virtual chicken". It was essentially a giant distributed lock :)


The same people shaming Amazon and Fedex are probably the same people buying a ton of goods online for delivery and getting upset about the delays.


The goal of a side project can be whatever a person wants it to be. Make money. Learn something. Improve people's lives. Creative outlet. Your definition limits people's ambitions.


Agreed. I started a side project SaaS with the goal of being the top product in it's niche and making enough money that I could live on it passively (if needed) and I accomplished that. I do think you should be highly interested in the subject, so not doing only for the money. And also don't underestimate the value of recruiting subject matter experts to help you.

But when I look at side projects for myself, I look at who's making money already in a subject I care about and if I can do it better.

In the things I failed at in the past, I was chasing new things that I wasn't particularly interested in or didn't get the subject matter expertise required to succeed - one had an ad supported business model which just ended up causing me to try creating 2 businesses effectively at once instead of 1. Many people underestimate those things and I did that early on and failed.

As I've gotten older I mostly look at things where I can compete and just outperform versus trying to do something novel. A lot of people come to me w ideas and get discouraged when they find out that competition already exists for their idea.

Very hard to do something entirely new and succeed financially.


Does your release process include publishing to brew? I ask because brew only has 0.10.3, whereas crates and github show something a few versions ahead (0.11.3). Looks awesome!


No, I unfortunately doesn't maintain myself the brew formulas, I don't even know how those things work (I'm not a mac user).


"almost complete bullshit" is a bit strong. i've read both the book and the Guzey piece and i think the most substantial insight in his rebuttal is that oversleeping can increase mortality risk, otherwise it seems like a lot of “he cited this wrong” or <nasally-voice>well technically…</nasally-voice>. most of the broader themes in walkers book still stand.


>i've read both the book and the Guzey piece and i think the most substantial insight in his rebuttal is that oversleeping can increase mortality risk

You're misreading my piece. It never claimed that oversleeping can increase mortality risk.

However, I do show that Walker repeatedly misrepresents important evidence, makes stuff up, lacks basic understanding of biology etc. etc.


> fundamentally this was an ad-tech company

Sure ads are their only real revenue source but the vast majority of engineers there are not working on ad-tech, many of them are working on transformative projects like maps, translate, android, chrome, that drastically improve the lives of hundreds of millions of people. Your view is quite cynical and conveniently ignores the leverage and impact that an engineer can have there.


many of them are working on transformative projects like maps, translate, android, chrome

All of those exist purely to expand opportunities to show more ads.


Ads aren’t hurting you or anyone else


The entire purpose of ads is to psychologically manipulate people into taking actions against their own best interests. If you need a thing you will just go and buy it yourself after all.


Ditto, images weren't showing up for me


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: