The rest of the world outside of the US and Europe loves AI. China is embracing it fully.
Why is our Western media making the public hate it so much? It's almost as if it's a top down edict from all the news giants to constantly dump on AI and make it sound like it'll kill you.
If we maintain this view, we're going to get steamrolled. And we'll have deserved it.
It isn't needed in every device. I don't need ai in a plug, or in a charging bank. I am perfectly capable of making a decision myself. I can use a piece of software without AI being helpful. Often I just want easy to use items that I have full control over and this lumping AI into everything is removing that.
Best chargers on the market, hands down. Best cables too.
But they've gone into high end stuff. They make the Eufy brand of LiDAR smart vacuums for instance. All done in house, and consistently in the top rankings against market leaders like Roborock and Dreame.
They're killing it.
They're doing home security systems, and all sorts of stuff under the Eufy brand.
Did not realize the Eufy brand was affiliated with Anker. Feels like a missed opportunity, Anker has earned some goodwill from me that might sway my purchasing decisions in the home automation category
I love my Eufy camera: no subscription fee, plug-and-play, never a problem, just a crystal clear view of my driveway with never a glitch. Cost me around $35 a couple years ago.
Love my Anker chargers. I like them even better than my Apple chargers now. Liked their wireless phone charger too, though the blue light on that was excessively bright. I have lots of Anker USB cables, no problems with them.
Didn't know they made Eufy. That would make me highly consider Eufy for anything.
That's because these mega monopolies have diverse income streams and have grown like cancers to tax every system and economy that touches the internet.
Anthropic and OpenAI are having to fight like hell to secure market share. Google just gets to sit back and relax with its browser and android monopolies.
Why did our regulators fall asleep at the wheel? Google owns 92% of "URL bar" surface area and turned it into a Google search trademark dragnet. Now Anthropic has to bid for its own products against its competitors and inject a 15+% CAC which is just a Google tax.
Now consider all the bullshit Google gets to do with android and owning that with an iron fist. Every piece of software has a 30% tax, has to jump through hoops, and even finding it is subject to the same bidding process.
These companies need to be broken up.
Google would be healthier for the economy and its own investors as six different companies. And they shouldn't be allowed to set the rules for mobile apps or tax other people's IP and trademarks.
Still, attributing that progress to "years of research at Google" alone is simplifying the facts to the point of being just plain wrong. That kind of research was always very much in the open and cooperative, with deep levels of standing-on-shoulders.
Attention e.g. was developed by Dzmitry Bahdanau et al. (those being Kyunghyun Cho and Yoshua Bengio) in 2014 while interning at the University of Montreal.
The insight of the paper you point to was that with attention you could dispense of the RNN that attention was initially developed to support.
If by fight like hell you mean hype like hell, then yeah.
Sam Altman's honesty problems, and Elon buying a VS code fork for $60 billion isn't a sign of moral uprightness or wisdom.
There's a lot to be said for grinding away at a problem. Being on your eighth generation AI chip and seventh generation of autonomous driving hardware is how you build value. Not by hobnobbing with fascists and building an army of stock pumping retail investors.
A company that cares more about cost than results is probably a terrible company to work for. They will give you 10yo dell laptop with 8gb memory and complain that you’re slow when it takes 15m to build the application.
Productivity is literally a statement of the relationship between the result and the cost, presumably you found that out after reading the reply and that is why you switched from "productivity" to "results" in your reply.
How can AI be the amazing thing you say it is, but also too stupid to understand unless you get really good at communicating. Wouldn't better AI just mean it understands your ramblings better?
It's fine if the "rambling" is logically coherent. So the communication ability isn't really about expressing your thoughts eloquently, but just effectively and clearly. Run on sentences and train of thought is fine as long as you are saying something meaningful. But no AI will be able to read your mind and know exactly what you mean by "make really cool looking website, not lame please, also nice colors, not boring". Declarative programming through natural language will become incredibly powerful.
Yes, I agree, but as one of the other comments say, they are not able to read your mind. So even if the structure and style is not clear, you must be able to express what you want.
Certainly. I just think "expressing thoughts in words clearly" might in the end turn out to be something different than what we, humans consider clear.
For example long unstructured rambling might turn out to be a non-issue, while as human I would rank such message low no matter how good it is in other informational aspects.
That's true. I feed Codex some very long .md files that I use as a kind of work diary and that are pain to use into something very much usable. Writing your thoughts is important even if done carelessly.
Stripe's APIs have grown so complicated to support so many different shapes of large enterprise workflows that they have to color code the entities to make you think it's simple.
You'll be processing events from totally different yet slightly overlapping entity types for building a simple subscription service and having to synthetically handle 12 month billing. The docs won't adequately explain which events should trigger which product decisions, and there is no guidance on which events and states are authoritative or take precedence.
Stripe is no longer the correct shape for small startups. They are wonderful for big business, but startups need something smaller to go faster. Your Stripe integration will slow you down.
Stripe APIs being simple and easy is a meme from the 2010s. It isn't anymore.
They're great for big business at scale, but they lost how to cater to startups.
Having done a major migration with Stripe, at a startup, I disagree.
They have lots of products, but you don't need most of them and can ignore them. What's left is, in my experience, the correct amount of complexity. We looked at Braintree, and it was just missing things that we were legally required to support, we looked at Judopay and it was... lacking (a nearby founder describe Judopay as treating payments like a hobby).
If your business is just ecommerce and you can use Shopify instead, sure, do that. If you just need to take dumb payments, just use Stripe Checkout. But if you need any control over your payments, Stripe is the only good option for startups. As you grow it becomes easier to justify more complex integrations such as Adyen, Klarna, etc, but Stripe is definitely the best starting place I've seen.
He is right, reading the docs you have no idea which events leads to what. Nowadays with llm's it's easy before that I still dont know which events mean what.
The migration I did was from the basic Stripe product to the complex one. I did it because we were legally required to do the transition. Stripe was the only major vendor with the technology ready for that migration.
> If you just need to take dumb payments, just use Stripe Checkout.
Could not agree more. Offload as much complexity (receipts, invoices, tax, customer info, etc.) to Stripe as humanly possible in the beginning. Don't build for edge cases or UX polish. If people want your product, they will buy it.
This is kind of the tradeoff you need to make when launching a product though. You cleave off some of the product's margin & send it to a third party so that you can get the thing launched. If it's unsuccessful, that's fine, you'll pay no money to the vendor. If it's successful..? Great! Now you can afford to pay someone to build a checkout that doesn't cost me thousands a month in fees.
Stripe takes 1.5-2.5%, so if you're sending them 1,000s a month, your revenues from that checkout are approaching the $millions p/a. Certainly enough to hire an expert in the domain.
Stripe's fees are well above interchange fees (especially in Europe). On top of that Stripe's pricing for other features (e.g. invoicing and subscriptions) is also a percentage, so you end up paying a ton for those features.
because stripe on purpose hide fees, constantly asks you to try out new features and then secretly charges you more then market price when you say yes. See radar, managed payment, stripe billing management etc.
I (sadly) completely disagree with this. There are still so many basic things they don't expose, and it feels like you're fighting an abstraction designed for a start-up that doesn't want to think about the complexities of payments at all. For example, you have to fight a battle to get the card IIN exposed to you. There's no way to see the electronicCommerceIndicator (ECI) for Wallet payments (it clearly has it, since it's shown in the dashboard if you dig deep enough, but it's kept from you). For their Direct Debit integration, they apply limits on the payment amounts you can initiate, but there's no way to actually see the current value of what these limits are. The same Direct Debit integration also doesn't let you customise the payment references used (GoCardless lets you do this to identify e.g. individual invoices on customer bank statements).
Some of the APIs clearly haven't been thought through - e.g. for disputes you can't programmatically retrieve the evidence submitted by the card issuer. Which means you can't build any sort of sensible custom integration for handling disputes. And besides, they don't even support pre-arbitration (which the card issuers know about and take advantage of frequently because they know their decisions outwith the card scheme chargeback guidelines cannot be challenged effectively).
Their Google Wallet integration is worse that Braintree's and doesn't support the web-based flow.
There's not nearly enough visibility when things go wrong, particularly with their 3DS integration (which was failing for Samsung Internet browser users for us, and we had to fight to get looked at - nothing ever got published on the status page despite the fact this significantly affected your chances of securing liability shift) and you have to escalate via an account manager to get any sort of useful support case response.
We're using Stripe to run our marketplace where teachers can sell their language courses. It does MOST of what we want/need.
I've done numerous checkout/payment processing integrations over the years. Stripe is still pretty easy to use and full-featured compared to what I've used in the past. It does have its annoyances, shortcomings and API inconsistencies - but it's still better than the alternatives, in my view.
Support has been good when I needed more documentation on something. Their chatbot performs very poorly, however.
Releasing two MAJOR SDK versions with breaking changes in a single week doesn't help either. [1] I dread every time they release a new SDK version because for me it means only more work for zero value.
I've got so incredibly tired of their constant flow of "innovation" in the API and SDK that I have finally gave up and created another SDK for Stripe from scratch: https://github.com/egorFiNE/simple-stripe-sdk (not yet released)
Huh? Stripe is still the easiest payment provider to build a subscription on. The complexity with payments does not come from APIs. It comes from payment types, regulations, and the need to avoid losing customers. That doesn't change with or without Stripe.
> Stripe APIs being simple and easy is a meme from the 2010s. It isn't anymore.
I'm working with Stripe subscriptions at the moment for a charity taking donations via their website. The subtle differences between subscriptions done through Stripe checkout and subscriptions set up yourself using Stripe elements are by turn infuriating and frustrating.
The documentation is geared towards people using checkout. Stripe's own AI help could find us a bit of information which going through the documentation didn't give us, and it even struggled to find the reference in the docs for it.
One product, two different ways to use it, and slightly diverging feature sets between the two. Argh!
On the other hands, having half the packages depend on packages such as serde, syn, procmacro2 might not be such a good idea. First of all it is annoying when creating new projects to have to move over table stakes. Second, it is a security nightmare. most of rust could be vulnerable if dtolnay decided to go rogue.
It is not that everything should go into the stdlib, but having syn, procmacro and serde would be a good start imo. And like golang having a native http stack would be really awesome, every time you have to do any HTTP, you end up pulling in some c-based crypto lib, which can really mess up your day when you want to cross-compile. With golang it mostly just works.
It isn't really in the flavor of rust to do, so I don't think it is going to happen, but it is nice when building services, that you can avoid most dependencies.
I agree with this. Rust has a node-style dependency problem; any non-trivial rust project ends up with dozens of dependencies in my experience. I would add tokio to the list of dependencies-so-common-they-should-be-moved-to-stdin.
A second tier stdlib would turn out like the Boost c++ libraries -- an 800 lb gorilla of a common dependency that gets called in just to do something very simple; although to be fair most of the Boost functionality already is in rust's stdlib.
As long as the "2nd-tier" stdlib was versioned & tied in with the edition system, it could work. The problem with most stdlibs (including Rust's) is that there's no way to remove anything & replace it with a better design. So the lib only ever grows, slowly adding complexity.
Would it be still a good idea if instead of being created / owned by google as an organization it was originally made by someone that didn't make billions by handling trillions of http requests over decades and you had to keep all of the bad initial api design choices going forward?
I would always go to the official docs page for the needs I have, and use their HTTP library (or any other). It removes decision making, having to ensure good quality practices from lesser known libraries, and risks of supply chain attacks (assuming the root stdlib of a language would have more attention to detail and security than any random 3rd-party library thrown into github by a small group of unpaid devs)
Only when it falls short on my needs, I would drop the stdlib and go in dearch of a good quality, reputable, and reliable 3rd-party lib (which is easier said than done).
Has worked me well with Go and Python. I would enjoy the same with Rust. Or at a minimum, a list of libraries officialy curated and directly pointed at by the lang docs.
The rest of the world outside of the US and Europe loves AI. China is embracing it fully.
Why is our Western media making the public hate it so much? It's almost as if it's a top down edict from all the news giants to constantly dump on AI and make it sound like it'll kill you.
If we maintain this view, we're going to get steamrolled. And we'll have deserved it.
reply