> I am frustrated that the USA’s money advice largely comes from billionaires.

One of my big issues with the 'follow your passion' advice is it almost always comes from people who are already rich. And, those people are often trying to leverage worker passion to staff their companies.

As a young person, don't follow your passion. Instead, figure out the fastest way to economic security and once there, then figure out a passion.

I think the most bad rep for RxJS comes from using it when it is not needed.

Parent comment said:

> But the problems they solve are also unintuitive.

Do you consider calling a JSON API unintuitive or complex? If not, then you may be using the wrong tool. If you need nothing else, you are perfectly fine using a promise.

If you need to await extra requests, transform them, and react to other events then you need RxJS. For a simple call, you do not.

> I would imagine most people’s use case (mine certainly is) for RxJS boils down to “call a JSON API and receive a response”. That shouldn’t be a hard problem

Do you consider the following code hard to understand or are you are making requests in a more complex way?

``` this.network.get('<url>').subscribe(response => <do whatever you want here>) ```

Even if we agree to disagree that the above code snippet is hard to understand, you can just convert it to a promise:

``` const response = await lastValueFrom(this.network.get('<url>')) ```

    http$
        .pipe(
            map(res =>     res['payload']),
            catchError(err =>     {
                console.log('caught mapping error and rethrowing', err);
                return throwError(err);
            }),
            finalize(() =>     console.log("first finalize() block executed")),
            catchError(err =>     {
                console.log('caught rethrown error, providing fallback value');
                return of([]);
            }),
             finalize(() => console.log("second finalize() block executed"))
    )
        .subscribe(
            res => console.log('HTTP response', res),
            err =>     console.log('HTTP Error', err),
            () =>     console.log('HTTP request completed.')
    );

Unintuitive? Yes.

If by unintuitive you mean “Can I look at it without training and know what’s going on.” But the problems they solve are also unintuitive. Only, those issues can be buried under a tangle of nested callbacks that look correct, intuitively.

Once you take the time to really (and I mean really) understand RxJS it’s incredible. Write your own Observables. Write your own operators. Learn what the built in operators are really doing (subscriptions, etc) reimplement them yourself.

What are your thoughts on the direct descendant, Roc? [0] I know it's pre v0.1 so maybe you don't have any, but as a fellow Elm lover it seems pretty compelling on the surface albeit less directly frontend-dev focused.

[0] https://github.com/roc-lang/roc

Configuration is applied in layers. If you’re using the default setup you get the following layers applied in this order:

1. appsettings.json

2. appsettings.{env}.json

3. user secrets (only in Development environment)

4. environment variables

5. command line args

You can full customize the setup if you desire, there are packages to support things like external secret stores. If you Google ‘Asp.Net core configuration” there’s a MS page that goes into great detail on all of this.

Anyway, your env vars must match the name as you’d structure it in a json object, but with the periods replace with double underscores. So ConnectionStrings.MyConnection becomes CONNECTIONSTRINGS__MYCONNECTION, FeatureFlags.Product.EnableNewIdFormat becomes FEATUREFLAGS__PRODUCT__ENABLENEWIDFORMAT, etc.

Been using .NET for years now for backend web development after having taken a break from C#. It is such an improvement over the old .NET framework. When I started building my first backend with it, I was surprised how much was included and "just worked". Need to add authentication? Few lines. OAuth? Also built in. Response caching? Yes. ORM? EF Core is pretty good. Need to use env variables to override your JSON config? You are going to have to build a... just kidding that works with one more line too.

Coming from NodeJS, the amount of stuff that could be added with a single line from an official package was great. No more worrying about hundreds of unvetted dependencies.

Buffer might lead the way with respect to transparency but at first glance those salaries don’t look very competitive.