[–] 12 points 2 weeks ago (8 children)

Bash and Python are very different. Bash uses your system as programming language, while Python offers a lot more. Python is in many cases a good solution that does not need extra work for programming languages to compile. If you don't think that Python is a grown up language, then you seem to be misinformed.

  • source
  • parent
  • context
  • [–] 27 points 2 weeks ago (12 children)

    Oh that's sad. I was hoping for that the title of the post was misleading, and it just meant that the "experimental" flag was removed. Well, sadly no.

    Little rant: My eyes hurt from reading 100% white on 100% black background... Wish sites stopped doing it. Thank god Firefox has this builtin reader view functionality.

  • source
  • [–] 2 points 2 weeks ago

    yeah that matches what I see, most of what we run at work is one app and one database, so the slow query log plus looking at the plan gets you like 90% of the way. I never really had the multi service case where otel pays off, I guess at some point it does, but for a small team it felt like a lot of plumbing to end up finding the same n+1 query lol

  • source
  • parent
  • context
  • [–] 11 points 2 weeks ago

    What I've realized is that because of the hype, you've virtually always got investors willing to offer a service for free, in hopes of attracting users.
    Which means, if that service then tries to make that money back, users will quickly find another free offering and switch to that instead.

    Obviously, in theory, you might manage to offer such a unique service that folks won't find a competing service, but:

    1. a lot of these AI services do the same shit, because it is just language models and image models at the end of the day, and
    2. if you can quickly build that service then others can quickly build it, too, so if people are willing to spend money on your offering, you won't need to wait for competitors.

    This is a very different situation than a gold rush, and yet it feels ever more appropriate when folks say only those who sell shovels earn money from it...

  • source
  • [–] 10 points 2 weeks ago (2 children)

    Now, with all that telemetry in place and a coding agent I can finally engage with production properly: not reactively when something goes wrong, but every day I can chat with the production, ask it about its concerns, about what is going on lately, if something feels wrong.

    Good luck

  • source
  • [–] 6 points 2 weeks ago

    No, the author is not confusing them. It's everyone else that has been confused insofar as they use "REST" to describe APIs that are not actually REST. True REST is a way of architecting networked applications according to a set of constraints, as defined by Roy Fielding in his original dissertation. Here's an excerpt that sums it up:

    In order to obtain a uniform interface, multiple architectural constraints are needed to guide the behavior of components. REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state.

    Many "REST" APIs do not adhere to these constraints, especially self-descriptive messages and hypermedia as the engine of application state (also known as HATEOAS). Note that this says nothing about HTML: HTML is but one representation of hypermedia, but far from the only one. Hypermedia is something that allows discovery of additional, related resources by way of links between resources. There are a number of ways of doing this, such as RFC 8288 Link Headers or embedding links within one of a resource's representations (such as a JSON representation).

    It's a much larger topic than I can fully explain here, but I highly recommend reading Roy Fielding's dissertation, especially Chapter 5 which talks about REST and what it is.

    I also highly recommend this blog post from Google Cloud's engineering team, which talks about why you should use links instead of keys to represent relationships in API design: https://cloud.google.com/blog/products/application-development/api-design-why-you-should-use-links-not-keys-to-represent-relationships-in-apis.

  • source
  • parent
  • context
  • [–] 5 points 2 weeks ago

    The repeated division trick has a quicker counterpart, which is to create a separate variable and repeatedly multiply that by 10, comparing to the original as it goes. Probably not as fast as anything beyond the repeated division trick, but I mention it because its rediscovery was likely missed by jumping right to clzl tricks.

    It also generalises a lot more readily to numbers in other bases. Kind of a "jack of all trades, master of none" solution.

  • source
  • [–] 2 points 2 weeks ago* (last edited 2 weeks ago) (1 child)

    Is he confusing REST with AJAX? AJAX was supposed to return HTML but is nowadays often used to return JSON, yes mostly from a REST API.

    But I would expect to get well structured data from a REST API. If you return HTML you might as well return it directly suited for presentation which may not be very well suited for data parsing by a computer.

    Edit: No, he's not confusing them. The first guy coining the REST term defined them as explicitly returning hypertext. Sounds like every webserver ever to me.

  • source
  • [–] 5 points 2 weeks ago (3 children)

    Amazing. It's so weird, I was just needing to do this same operation and was looking into some of the bithacks. Although I don't have the ability in the language to fully utilize this, I am astounded by how lean you made it.

  • source
  • view more: ‹ prev next ›