I fancy learning a new language. I've got experience in Python, PHP, Ruby, Bash and many years ago Java, Haskell and C++. Though I'm absolute dogshit at system languages generally. I GET pointers but I fucking hate having to think about them.

Is Nim nice? Is it better than Rust? I like being a contrarian so I'd rather not learn Rust since it's too fashionable right now. But Nim seems to have that independent, cool streak but still niche. It also seems a little bit like Python but with low level stuff slapped in.

I fancy doing something like some of the following:

• TUI/ncurses pacman app.
• Taskade terminal app.
• Network scanning tool.
• USB midi tool.
• Kitchen sink that gargles my balls (optional)

So how is Nim for this? Thoughts? Feelings?

etk is a library for the Ebitengine game engine that simplifies creating graphical user interfaces. The README lists the features and widgets. Boxcars uses etk to greatly simplify UI development, as its single codebase targets web, desktop and Android.

ffplay -f lavfi -i life=s=400x300:mold=10:r=30:ratio=0.1:death_color=#C83232:life_color=#00ff00,scale=1200:800:flags=32

I had this discussion in my workplace and wanted to share and get opinions from the folks here. (I suspect StackOverflow might not appreciate such open ended questions).

Context: We have a microservice involved in pricing signalling to our users. We have an endpoint which have the following:

• Input: an array of item ID's
• Output: the expected final price of the given items.

The item prices are quite volatile (and no, it is not crypto related), and is dependent on things like instantaneous supply-demand, promotions, etc.

Since the prices change quite frequently, it became a requirement that we commit to the price that was shown to the user initially, up to a certain time period (eg 5 min after the price was calculated). This improves the UX since the user will be charged as according to what they expected at the start.

Currently, in our system, we achieve this via a JWT, which contains all the details in the request, the obligatory signature, and the expiry set to 5 min from the time it was generated.

After generating this receipt, the FE can then call the endpoint with the JWT which does the actual payment processing using the params encoded in the token. This way, we know that the params + the total cost that is quoted in the JWT originates from our service since we verify that we signed it.

And the system evolves once more. We see that in the system, there is this mechanism, that if the token is expired, we do not reject the request at the charging step. Instead, we call the price endpoint internally using the params provided, and check if the price is the same as in the expired JWT. If it is the same, we process it as normal despite the JWT being expired.

This is where the contention lies. I believe that we should force the user to procure another non-expired JWT and removing this complex logic while others believe in the value of this improved UX where the user doesn't need to restart the whole flow again.

What do y'all think? Which way would y'all architect the endpoint? Or is there something fundamentally wrong with our design (maybe JWT is not the best suited for this use case)?

If you use a compiled language, you should periodically look at Godbolt and see what your code is doing and what changes to your code will do in the compiled output.

In this case a positively insane way of calculating squares and cubes generates 311 lines of ARM assembler output that will swallow your memory. With even something as simple as -O1 on the command line it's replaced by one or two multiplications respectively. With -fwhole-program it removes the functions entirely and interlaces them into the loop in main().

Know your tools. It makes huge differences!

Many thumbnail programs exist that will take a large image and reduce it to a thumbnail for you, often supporting working in batches. But what about turning user-uploaded images into thumbnails? Obviously, you don’t want to simply send a large image to the browser and have HTML resize it, because the quality wouldn’t be great, and your bandwidth would go through the roof. So you need something to handle this process on the fly, which is where this recipe comes in handy.

Chat rooms and programming content

One needs to send 1 mln HTTP requests concurrently, in batches, and read the responses. No more than 100 requests at a time.

Which way will it be better, recommended, idiomatic?

• Send 100 ones, wait for them to finish, send another 100, wait for them to finish… and so on

• Send 100 ones. As a a request among the 100 finishes, add a new one into the pool. “Done - add a new one. Done - add a new one”. As a stream.