dvlsg

You can generate uuids that play nicer with database storage / indexing. NEWSEQUENTIALID() in MSSQL, for example.

The keys will be easier to guess again, but if all you have to do is guess a primary key to get access to the underlying data, something else isn't right anyways.

Hopefully F# feeds the ability to have functions at the root of a module into C#. It's a small thing, but needing to put pure functions on static classes gets old after a while.

I know local functions are a recent ish addition to C#. Hoping they keep going down that road.

I've used this to good effect before.

Note that the endianness may catch you by surprise, though. For example, what's good in postgres may not be good for SQL server.

Just this morning I got a pop up on my windows computer with a 30 minute countdown to update time.

Which I know will fail - my laptop has been failing to update for the past year or so, but windows still insists on restarting my computer so it can fail the update again.

_Sometimes_ using the "defer updates for a month" will work. Other times, windows will completely ignore it and restart in the middle of my work day.

Ad hoc querying as in users can choose their own time range / bucket size / something else?

I agree, I quite enjoy them in TypeScript where I rely heavily on inference.

I suppose it helps that the types aren't strictly required too, so you can side-step them if necessary.

They don't seem to be. At least not in terms of content. YouTube music has songs that Google play doesn't, and vice versa.

The YouTube music experience is kind of odd. It seems that you can only listen to full albums if someone has uploaded them to YouTube as separate songs. Which makes sense, but it means that currently a lot of the music I listen to is nowhere to be found on YouTube music.

That's what feels strange to me, though. It's not a physical book that can only be in one place at a time, so why are we holding ourselves back with artificial limitations?

I suspect it has something to do with licensing, but I don't know for sure.

Not OP, but if you're looking for something to search for, I suspect they're describing "Pure DI" or using a "Composition Root".

https://blog.ploeh.dk/2014/06/10/pure-di/

https://stackoverflow.com/questions/6277771/what-is-a-compos...

I've found containers are helpful when you want to replace one or two specific pieces in the middle of the dependency tree for testing - let's say a mock database, for example.

On the other hand, I've also found myself avoiding writing code which requires deep mocks like that in order to test. Functional core, imperative shell helps with that.

Does it have drm?

Do they have any artificial restrictions? Last time I tried a similar app (it's been a few years), I wasn't able to get an audiobook because someone else already had it "checked out".

dotnet core is a pleasure to work with, too. I really appreciate the effort that went into making the CLI nice to use. Things like project init, package management, building, testing, etc.

I agree. If most of your experience is with a popular OO language, consider learning a lisp. Learn an ML. Try elixir/erlang to get a feel for how different programming for the BEAM can be.

I suppose you don't _have_ to use different languages to learn new concepts, but it certainly helps in some cases. For example, learning about currying is going to be much more natural in F# than it would be in C#.

If that's a reference to typescript, it can also be used as a backend language with node. That may contribute to the growth, too.

Or just keep logging / requests out of the pure functions, and leave it to the context around them. You can always have the pure functions return a `Result` or `Either` type, if you need information about a failure to be logged.

I agree, I love on-save formatting. Now I can just type code I know is syntactically correct, hit save, and let the formatter worry about the formatting.

I've been using flamebearer to get flame graphs from node. It was silly how easy it was to use. Highly recommend it.

https://github.com/mapbox/flamebearer

I honestly can't remember a recent time I had to start a line with a ( or a [.

I don't really write IIFEs since let and const. I'm sure the outputs from babel/typescript/etc use them, but I don't really need to write them myself, now that we have proper block scoping.

And if I want to declare an array and immediately iterate over it, I just put it in a variable first. That gives it a name, too, which tends to improve readability anyways.

I work with Javascript / Typescript projects on both sides of the argument, and I have to say not using semicolons never seems to cause any problems. Especially not with auto formatting / linters around.

> React knows which component is rendering at any point in time — so it knows which component useState() call corresponds to.

Personally, I think that may be the piece that makes it feel a bit magical. With `this.setState()`, usage of `this` makes me feel like I know how the component and the state are linked.

With hooks, however, there's no obvious link to the component in the code. I'm grabbing `useState` off of the shared react module, `useState` is not passed into the component, and I don't have to reference the component itself at any point while using hooks. The new sets of rules you have to follow to make things line up correctly play a part, as well.

Of course that may be how `this.setState()` does it anyways - you know better than I do, obviously. Maybe the usage of `this.setState()` made me feel confident in something I didn't actually understand under the hood. But at least for me, that's why `useState()` feels a bit magical at first glance compared to `this.setState()`. Not _too_ magical, and not enough to scare me away from using hooks, but still a bit.

Is it built in to pg now? Last time I set up pg I had to add an extension to get UUID support.

It was relatively painless, sure, but I seem to remember having to add it.

Not OP, but I'm keeping a close eye on pulsar.

Im not sure I'd want to replace an existing / working Kafka setup with it, but if pulsar catches on, I would very strongly consider using it for newer projects.

I haven't used pulsar extensively in production for anything, but all the setup and testing I've done on my own was a pleasure. Hoping pulsar continues to grow.

Excited to hear that HA support is in the works. That's one of the main things keeping me away from dokku for a decent chunk of projects at the moment.

Yeah, I use both all the time.

I will admit I have to pass type hints via generics to my compose / pipe calls more often than I would like, but it definitely still works.

Usage of the word "tax" is interesting, too. I'm happy to pay tax if I reap tangible benefits from it / if the "money" is put to good use. I'd say that's the case with typescript.

> I very rarely see TypeScript developers actually use `any` (usually to reflect something like something parsed from arbitrary JSON that needs to be interrogated rather than just type-asserted)

Even that example usage of `any` should be less common, now. I think `unknown` (which is fairly new) is better there.

I agree. The first time I saw F#, I was immediately concerned about single spaces without any braces/brackets/parens indicating function executions.

I stuck it out with F#, though, and now I miss that syntax greatly when I have to use other languages. It's surprisingly wonderful (at least in my opinion). Or at least in languages where partial application / currying / composition is easily-available. I suspect that syntax wouldn't be very helpful with languages where that isn't the case.

Can confirm. I usually have to turn off windows defender whenever I'm doing anything with docker, or node modules, or something similar. If I don't, my computer slows to a crawl.

I've definitely structured f# modules that way. The module exposes one function that "injects" the dependency into multiple other functions, and then returns them as a blob.

I'm not sure if that's "the fsharp way" (i suspect it isn't) and maybe I'll look back on it some day and cringe, but it's working pretty well for some of my (admittedly small) side projects I'm tinkering with right now.

Pure functions are great, regardless of threading / concurrency problems.

I know you don't _need_ immutability enforced at the object level to write pure functions, but I could understand the argument in its favor.