wild_egg

That's a bit bold when you know nothing about me, but sure.

I exist in a polyglot environment and we use Go for things that we expect to sit and do their job for years without modification.

Nothing more annoying with these than needing to update a runtime to patch a CVE and suddenly needing to invest two weeks to handle all the breaking changes. Go lets us take 5 minutes to bump the version number in the Dockerfile and CI configs and move on to more important work.

I'm not suggesting we'd go rewrite all of those if Go relaxed its guarantees but we'd stop picking it to write new things in and it would slowly disappear as we decommission the existing services over the years.

Data point of one, but I've been using Go since 2012 and would drop it instantly if any of the backwards compatibility guarantees were relaxed.

Having bugs imposed on you from outside your project is a waste of time to deal with and there are dozens of other languages you can pick from if you enjoy that time sink. Most of them give you greater capabilities as the balance.

Go's stability is a core feature and compensates for the lack of other niceties. Adding features isn't a good reason to break things. I can go use something else if I want to make that trade.

There's no reason at all why you can't also organise code into components under this model. Orthogonal concepts

> I think it's better -- in the most pessimistic case -- to look at jj as reframing how you think about branches and commits in the same way that learning a type of Lisp reframes your thinking even if you're a full time Python developer and have zero intention of ever using a Lisp.

For some reason this actually had me pause in fear. I've been using git deeply for years and find it very natural and mindless to use at this point. The thought that I might again be trapped in Plato's cave like I found I had been prior to learning Common Lisp is actually disturbing...

Now I don't have a choice but to give jj a shot

I keep hearing anecdotes like this and truly want to give Emacs a shot. Do you use it exclusively on a PC?

My big blocker is that a significant portion of my time is on a phone rather than a computer these days and I have to think that all the chording with Emacs would get impossibly cumbersome.

Anyone here have a good way to leverage Emacs on the go?

I haven't used mssql since ~2013 but I think you're right that it's not available there.

Works great in MySQL, PostgreSQL, and SQLite though.

No love for JOIN ... USING in this thread eh

    SELECT 
        t.passenger_name, 
        t.ticket_no, 
        bp.seat_no
    FROM Flights f
    JOIN Ticket_flights tf USING (flight_id),
    JOIN Tickets t USING (ticket_no),
    JOIN Boarding_pass bp USING (ticket_no, flight_id)
    WHERE f.arrival_airport = 'OVB';

They call it a fixed size array type but, yes. It was added earlier this year. Works really great

https://duckdb.org/2024/05/03/vector-similarity-search-vss.h...

Have you given sqlx a try? Manual query writing like database/SQL but convenience wrapper functions that handle the row scanning part for you. I haven't felt the need to use anything else for years now.

It's bad at directly working on classical computer problems like math and data processing. But you can do it indirectly by having it write a program that produces the correct result. Interestingly, I didn't even have to have it run the program, although usually you would

    write a tool which counts the number of w's in "strawberry" and return the result

Which produced:

    Here's a simple Python function that counts the number of 'w's in the word "strawberry" and returns the result:

    ```python
    def count_w_in_strawberry():
        word = "strawberry"
        count = word.count('w')
        return count

    # Call the function and print the result
    result = count_w_in_strawberry()
    print(f"The number of 'w's in 'strawberry' is: {result}")
    ```

    This tool does the following:

    1. We define a function called `count_w_in_strawberry()`.
    2. Inside the function, we assign the word "strawberry" to a variable called `word`.
    3. We use the `count()` method on the `word` string to count the occurrences of 'w'.
    4. The function returns the count.
    5. Outside the function, we call `count_w_in_strawberry()` and store the result in the `result` variable.
    6. Finally, we print the result.

    When you run this code, it will output:

    ```
    The number of 'w's in 'strawberry' is: 1
    ```

    This tool correctly identifies that there is one 'w' in the word "strawberry".

This is excellent as well. I don't really jive with the Collapsnik aspect but I absolutely love powerful systems that can run in constrained environments.

Thanks for sharing, I'll be diving into this for a while

> This made me realize that Go was always promoted as "do not use frameworks, do not use libraries, use standard library, everything you need is in there".

I've been writing Go since 2012 and have no idea where you picked up this sentiment. The stdlib is there to give you many useful capabilities but it's focus has always been on correctness and flexibility rather than performance.

If performance is your concern, it's always been recommended to reach for other libraries that share that focus.

There's plenty to dislike about the direction Go is moving but stdlib performance isn't one of them. Just find a package that suits you better.

Indeed. People writing HTML5 as if it's XHTML is an old pet peeve of mine

The only elements that are absolutely required are doctype and a non-empty title. Most minimal valid HTML doc:

    <!DOCTYPE html>
    <title>Foo</title>

The important bit is figuring out if those times where "the right way" would have helped outweigh the time saved by defaulting to "good enough".

There are always exceptions, but there's typically order of magnitude differences between globally doing "the right thing" vs "good enough" and going back to fix the few cases where "good enough" wasn't actually good enough.

You can see the evolution of the article in the PR on GitHub. Seems genuine.

Having to deploy a dedicated server unit to render your frontend is a lot of additional complexity for zero benefit when you still require an API server to actually drive everything.

Have your API server render the HTML itself and your entire stack becomes radically simpler. Iteration speed goes through the roof.

If you're not building Google Sheets, skipping the entire SPA universe provides massive benefits with no notable downsides. The same UX can be provided either way but often with improved performance which actually means a better UX

> My go-to is Verdana based on previous empirical tests.

Do you have any handy links around this? I've a passing interest in information-dense UIs and font choice is a vital but often overlooked aspect of such interfaces. Would love to see how others evaluate such things.

> It's always the same with Scrum. Every time you point out something clearly wrong, the response is always "well that's not really scrum, you're doing it wrong".

Scrum is a victim of semantic drift. The vast majority of people "doing scrum" have never read the guide and are just doing things that other people have told them is Scrum.

It's not Scrum's fault that people have hijacked its name for something completely different. It happens often.

What people call Scrum isn't really Scrum. What people call REST isn't really REST. What people call DevOps isn't really DevOps.

People using the wrong word for something doesn't mean the original definition of the word is invalid.

It's fairly different from the Communism situation in that people discussing Communism are generally talking about the same concepts and the debate is whether or not they're feasible. With the other terms I used above, people are using the same words to talk about completely different concepts with different definitions.

None of those things are part of scrum as described by the actual guide

> Daily stand-ups, the main benefit of which is that managers (EMs/PMs) get daily updates on status.

The scrum guide fairly explicitly states that managers should not attend or be part of stand-ups unless they're actively involved in the work as part of the development team.

Strictly speaking, buttons aren't typically hypermedia controls. Haven't read the paper yet but the only controls in HTML are links and forms. Buttons can be nested inside those as actuators but aren't controls unto themselves since they don't meet that functional requirement of sending a request to a URL and inserting response content into the viewport.

EDIT: It seems the authors also consider images and iframes to be controls since they also make requests and add content to the viewport.

> perhaps something that reflects the losing characteristics of both philosophies.

Oof. With how much love Rust gets here, I didn't expect to see it being called out like that.

How about "The Worse Thing"?

Send the notes out afterwards and have them validated

Been writing Go since 2012 and consider the status quo on all of these to be _features_. I may be in the minority there though

FWIW a lot of those packages with default context wrapper functions have that as a backwards compatibility measure for code written before the context package existed. It's almost always preferable to call the newer function with your own context instead

Have you tried it? It may be one of those "you have to see it to believe it" things but I can assure you that was not hyperbole

This seemed an odd question until I noticed the logo. Now my brain hurts.

Maybe dumb question but why is keeping a million booleans in one process un-scalable? That's only 125KB of memory which can easily live inside CPU cache and be operated on atomically.

Any hints on how to even begin looking into this? There's a plethora of content on starting SaaS projects but can't say I've ever come across any for hardware.