Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
berkes
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
27 ms
·
391.
▲
by
berkes
2y ago
Is this your project? I'd love to see a link to the source. My problem with all of these nice invoicing tools is that they are way too localized. Most often US-centric. Invoices must adhere to strict rules in many countries. And lots
392.
▲
by
berkes
2y ago
> something that looks like HTML This is surprisingly easy. Because the "this is HTML" is both vague and limited. HTML5 is remarkably vague and permissive. Also, HTML has nothing to do with CSS nor with JS, nor with any DOM ap
393.
▲
by
berkes
2y ago
> I don't think it's worth trying to write a rendering engine for HTML. You will never finish - HTML is a spec fully owned by Google and Apple at this point and it's just too complex to implement from scratch. This keeps b
394.
▲
by
berkes
2y ago
> very promising low hanging fruit That was actually excacly our angle of attack: see the routes, modules or jobs that were putting the most pressure on the servers. Then copy the entire app over to separate servers, connected to the sam
395.
▲
by
berkes
2y ago
What you describe is common "management of complexity", or, really, lack thereof. These problems are independent of "microservices" vs "monolith". They are independent of "using a framework" vs "
396.
▲
by
berkes
2y ago
> At first I was reaching for JS and this feels good—total control! But I wanted to challenge myself to use a hypermedia based approach, and in the end the outcome felt better. I've built a search page that used meilisearch as backe
397.
▲
by
berkes
2y ago
I'm not sure if I follow this example, though. Doesn't a searchbox with typeahead and instantly updating results still require a backend? Isn't that backend not the most important ingredient of this use-case? Or did you send
398.
▲
by
berkes
2y ago
Well, Ruby (on Rails) is slow, single core, synchronous, database blocked and hard to scale. But certainly almost everyone realises that's not a feature of it being a monolith, but comes from it's language/stack/paradi
399.
▲
by
berkes
2y ago
> "just write better code" to avoid these pitfalls A lot of issues in and with Rails code leans heavily on this idea. It often comes in other flavors like "You can write rails apps that perform really well" or "
400.
▲
by
berkes
2y ago
I keep hearing this "microservices to allow scale", in which "scale" implies performance, as some counterargument against microservices. Honest question, who ever seriously proposed microservices to improve performance
401.
▲
by
berkes
2y ago
I partially agree. It's not so hard to write software that keeps the borrow checker happy in early stages. But it does restrict the freedom to make terrible decisions a bit. Sometimes in that stage terrible decisions are OK. But I do l
402.
▲
by
berkes
2y ago
I have had the luxury to work in projects that don't have to target many platforms, but rather "one": a server. Which then is often a simple linux variant so setting up a CI or even the local build to target that "one&qu
403.
▲
by
berkes
2y ago
Certainly. A lot (all?) of the points I make aren't unique to rust, or even invented in rust. Many have even better implementations in other languages. Go also invented the "fmt", with one opinionated code style "enforce
404.
▲
by
berkes
2y ago
> but as an alternative against Python it gets muddier For me, a clear advantage of rust (and also Go) over Python (or Ruby, or PHP) is not having to deal with runtimes. With Python, the server needs all sorts of setup. Exactly the righ
405.
▲
by
berkes
2y ago
> that are nothing even remotely close to systems programming This is unnecessary gatekeeping. It also shows your lack of perspective. Or, rather, your lack of imagining other perspectives, probably. Sure, rust is primarily a language ai
406.
▲
by
berkes
2y ago
Good one. In general a tricky thing to be aware of with vim: when I add a new variant that uses more characters, the ones with less characters will get a delay. I presume one can tweak that delay even. But personally, I'll make all the
407.
▲
by
berkes
2y ago
How does this related to "AI"?
408.
▲
by
berkes
2y ago
Slightly unrelated: > As an aside, I also use this technique for navigating code with Vim, where a single shortcut goes to a definition of a function in a new pane I was intrigued by this, and searched the author's github for their
409.
▲
by
berkes
2y ago
I had exactly the same. I need something to keep me on track. Or, at least something that signals me "headsup! you are rabbit-holing" rather than encouraging me to rabbit-hole. OTOH, being able to quickly go back to the junction w
410.
▲
by
berkes
2y ago
Sure there are good and bad doctors. But these anecdotes are no "proof" that doctors aren't to be trusted in general. Which is what I was alluding to.
411.
▲
by
berkes
2y ago
If I'm to believe a friend, who'se a family doctor, this is exactly what happens. Especially since corona. And not a tiny minority, but a big group. He told me that a few decades ago, there were the occasional homeopathic or other
412.
▲
by
berkes
2y ago
Depends a bit on the "manufactoring". It's not "black"-"white". While it's certainly true for e.g. a brewery or a bike-factory-line, it's less so for aluminum, or chemicals. And even less so for
413.
▲
by
berkes
2y ago
It does have overlap though. The article is about an anti-trust body researching whether that moat is not too much of a monopoly: > In a summary of evidence given to UK watchdog, the Competition and Markets Authority (CMA), AWS denies th
414.
▲
by
berkes
2y ago
The parent article is about the CMA researching whether AWS is a monopoly and the answer to that from AWS. > Declining revenues isn't the sign of not being a monopoly. Thats a definition thing, though. Monopoly can mean a lot, depen
415.
▲
by
berkes
2y ago
The parent article literally says > In a summary of evidence given to UK watchdog, the Competition and Markets Authority (CMA), AWS denies that customers face any difficulty in switching from its platform. This CMA was investigating amaz
416.
▲
by
berkes
2y ago
The cost of switching is just too high. This is true for their "competion" too. We can see this when researching the books as published to shareholders. When AWS was the "sole" player (first mover advantage) they had ins
417.
▲
by
berkes
2y ago
This reeks of spinning a story by AWS in the hopes to avoid measures from anti-monopoly authorities. Off course a company will deny that they are a monopoly (or cartel etc). They'll keep pointing out their competition to these authorit
418.
▲
by
berkes
2y ago
This market thing is in place already. At least in Europe it is, I've done a project during my energy engineering study for APEX. The irony, however, is that it's not all that good for nuclear. When prices go down or even negative
419.
▲
by
berkes
2y ago
Maybe. Probably, if "future" means 50+ years, so two generations in future. But not if it means "future" in even overlapping the current nuclear plants that are EOL, 10, 20 even 30 years. Because to replace those nuclear
420.
▲
by
berkes
2y ago
No. An energy mix is the answer. One of the parts that is mixed in, can be nuclear. Probably should be. But always a small part of the mix. Nuclear is slow: slow to power up, slow to adjust to demand or supply from others in the mix. And
More ›