Human drive in fog just fine with pure vision, why can’t AI do the same?
Keep in mind that vision is needed in all cases for lane keeping at the very minimum. So if vision is not able to see in fog, it won’t be able to self drive even radar is working.
Is there a formal proof that FSD requires the same level of intelligence of AGI?
Stereo vision can be built from cameras as well, even with a single moving camera. This is exactly what tesla is doing with their new DNN but with multiple cameras.
I don’t disagree with you that Tesla is still far away from FSD, but using what’s not possible today to draw the conclusion that a goal is not achievable in the future is the opposite of first principle thinking. 10 years ago i could also say go AI can’t even beat semi-pro so we will never be able to solve Go with AI.
The Rust community opened an issue on their tracker [0] - it seems that they are not working on one right now:
> Greetings folks! I work on the team that builds the Cloud Client Libraries. Per the last comment - I can absolutely share that we're not actively working on a Rust SDK right now, and we have no immediate plans to start. We completely understand this would be useful, and we'd love to go build it. However, we're focusing all of our energies on Java, Go, Node.js, Python, C#, Ruby, PHP, and C++ at the moment. If you're looking to build something, I'd be happy to bounce ideas with you!
Same here. Pulumi got some things spectacularly right. Their Crosswalk for AWS [0] is magical, especially if you're building serverless apps using Lambda or Docker-based services on top of EKS/ECS. I'd suggest sticking to the TypeScript runtime and major clouds where the support is the best.
_Full disclosure_ - Marcin at Spacelift here, and we chose to support Pulumi in addition to Terraform, so this opinion is necessarily biased.
I don’t get why people like scripting it, declarative is fantastically simple. I don’t want to trace through loops, if statements, functions
It does from these files declare my infra to these scripts when parser thru define my infer
I get Logic in yaml/json is less ergonomic but templing makes us for it
It's probably good when you are already using Typescripts in other parts of your day job. While I like the idea of using a real programming language in place of a declarative DSL you trade in the awkward parts of the latter with the idiosyncrasies of async programming and promises.
Pulumi needs to work on their documentation. I looked at it about 18 months ago and the Python support was barely there.
Tried it again last month and it's better, but I had to do a lot of trial and error. ie. (Try to figure out how to provision an EC2 instance with a root volume. They copied part of the docs from terraform but sections are missing.)
My first project was trying to deploy a Redshift cluster. It flat out didn’t work. Did 2-3 calls with their tech sales before giving up on it. And then cdktf came out shortly after that.
So regular CDK is basically a program-driven CFN generator.
Pulumi has a similar model where you build a resource graph at runtime BUT it's also got the execution engine built-in to the tool.
What this means in practice is that you can create resources (like a kube cluster) and then use them as providers (e.g provision state tracked resources with kube api) all in the same operation.
You can also (in your infracode or an importable module) define "dynamic providers", meaning you can easily extend the execution engine to do custom things related to your workload.
As an example, imagine you want to create a cluster, deploy an app, then provision (state tracked) some app resources like an admin user and group via the app's REST API. You can do that without too much fuss.
Neither terraform nor CDK can really do those things very well. TF is not powerful enough language-wise, and in CDK the execution phase is locked away from you.
You wouldn't see much _practical_ difference between CDK and Pulumi (or Terraform!) for that use-case. The workflow would feel almost identical.
Under the hood different things are happening.
Your CDK program would run with all the resources you declared. That would generate CloudFormation script(s) that get submitted to the CloudFormation service for evaluation. The CloudFormation service (running inside AWS) is the "execution engine" and is responsible for creating and tracking the state of your resources.
Pulumi would run your code, build an object graph, then do the "execution" itself - invoke all the required AWS API calls to create your resources (the API Gateway, the Lambda, etc etc) from where the CLI is running. The CLI would also be writing out all the resource state to somewhere.
The tradeoffs are in line with what you might expect. The Pulumi approach is more powerful, but you "own" more of the complexity since it lives on your side of the responsibility boundary.
Some people prefer AWS to be the execution engine; they feel it's more reliable to let AWS provision resources and keep track of state. They like it that AWS is responsible and will fix bugs.
Others prefer the increased control of "owning" the execution engine. This means being able to debug it or extend it with third party or custom providers that let you provision new resource types. They're happy that they don't need to wait for AWS to fix things, they can do it themselves if they have to.
This is not the only difference between the two tools but it is one of the most fundamental ones.
I guess it depends on what you mean by "under the hood". As far as I know it doesn't use Terraform during runtime but it uses the Terraform resources for generating language definitions. It has a lot of interoperability tools as well such as a "terraform bridge" and a tool that converts Terraform projects.
Waiting for one to show up. We need a better ranking system for content that doesn't confuse "popularity" with "quality". Every comment/article moderation system that has crowdsourced upvotes and downvotes suffers from this. It inevitably leads to groupthink, herd opinion, and shutdown culture.
I'm really curious what @dang's thought's are on moderation and a better voting system, especially since HN seems to be growing in popularity by quite a bit every year.
I genuinely think slashdot did it best, being able to upvote comments for different reasons. Be they "funny" or "insightful" and then letting you sort by what you preferred to see.
Dude, you're here just six months and you already decided that the system doesn't work? I'm here 8 years and I haven't had a single problem with how voting works. When I'm downvoted it's because I say something snarky, generalized, or stupid. HN is by far the most healthy moderated community on the web.
The easy counter is to stop graying out downvoted posts. An even easier counter is to get rid of the downvotes entirely. Have a reporting system to take care of the rule-breakers. For everyone else, bad posts will generally not be upvoted and will thus lurk in the bottom of the page. Underneath all the upvoted comments.
That’s not perfect but I think it would be an improvement over the current system. As an added bonus, it would eliminate the “why am I downvoted” noise.
Slashdot had a nice system back in the day. People were randomly selected to rank posts. You had to give a reason (from a list) for your ranking. And posts would max out at 5 points or have a floor of -1. Maybe that wouldn’t scale to Reddit but it was a fairly humane way of doing things that was a bit resistant to mobs and bots.
> I think there should be a cost to upvoting or downvoting, so they can't be handed out willy-nilly.
It would be really interesting to run an experiment where this was taken literally. If upvotes/karma/whatever you call it were to be treated as almost a type of currency, and submitting a vote directly cost you a vote from your “balance” what would the discussions look like. You could even deal with inflation by lowering the value of votes people already have by increasing the cost for a new vote.
I don’t think this would get you away from the groupthink and pandering comments, as people would probably try to appeal to the widest audience so they could bank more votes, but I’d love to see if it would cause people to post more meaningful comments as opposed to predictable jokes.
Maybe give people unlimited upvotes but a budget of downvotes, say 3 per day or 3 per article. This wouldn't prevent multiple accounts colluding to brigade a thread or person, but it might help stop the casual, uncoordinated drive-by downvoting.
Or, make people actually type in why they're downvoting before it counts. Again, wouldn't stop a motivated attacker or coordinated attackers, but could add just the right amount of friction.
Hacker News does frequently upvote popular opinions, just like Reddit, but I’ve found that substantiated “unpopular” or surprising opinions aren’t treated as harshly. Often they actually do rather well!
> It's easy to farm them by hopping on the winning bandwagon on divisive topics.
> I think there should be a cost to upvoting or downvoting, so they can't be handed out willy-nilly.
Would a cost to voting not encourage farming points?
Aside from the 500 points (or whatever it is now) hurdle to be able to downvote (on HN, and similar though not the same hurdle for /.'s meta moderation), internet points are surely just internet points and any mechanism that made them more would end up in farming / community-moderated voice would tend to the farmers.
