https://doc.rust-lang.org/1.30.0/book/second-edition/ch16-00...

These sound like quite bold claims to me.

The Go compiler doesn't need to be smarter for Go's usecase. If it can be made smarter, fine. For best possible performance look at C/C++ or Rust.

https://www.jetbrains.com/go/buy/#discounts?billing=yearly

https://www.jetbrains.com/go/buy/#personal?billing=yearly

https://github.com/sveltejs/svelte/issues/1639

Still I'm curious.

Typescript and RxJS (or MobX) with Svelte as the afterthought (https://michel.codes/blogs/ui-as-an-afterthought) would be a nice combo.

Sure, async needs to be shipped and polished, but then Rust needs to tell the world: "We have all you need and as stable as you need."

I couldn't disagree more. Google doesn't make bazillions of dollars because they provide us with live traffic on maps. Google has significantly enabled and actively driven the mindless consume-everything-all-the-time culture with all the horrible consequences for our mental-health and the environment.

The world would be a much better place without the ones like Google, Facebook and Amazon.

Regarding React: In many webgl use-cases UI-framework overhead can be neglected as the user interacts either with the scene or the UI rendered by the framework. The browser doesn't usually need to update the DOM and the scene in one frame.

We are using reactive programming basically everywhere. Example (Angular):

The Angular Router has an Observable "paramMap". We don't subscribe to it but are creating another Observable for the data that should be loaded.

  getData$ = (
    paramMap$: Observable
  ): Observable => {
    return paramMap$.pipe(
      // Create a query string
      map(paramMap => {
        // some pure function - business logic
        return getSomeQueryBasedOnTheRouteParams(
          paramMap 
        );
      }),
      // get the data
      // select$ is a method on the customStore that wraps the http client and does some more stuff
      // The switchMap is actually one of the concepts that I found initially not the easiest to understand 
      switchMap(someQuery=> {
        return this.customStore.select$({
          query: someQuery
        });
      }),
      map(rawData => {
        // pure function with business logic
        return modifyData(rawData);
      }),
      shareReplay()
    );
  };

   getFilteredData$ = (
     // filter:$ is in our case a simple Subject we're calling next(newFilterValue)
     // NGRX, NGXS or Akita are popular state management libraries to manage this kind of state
     filter$: BehaviourSubject,
     data$: Observable): Observable => {
        combineLatest(filter$, data$).pipe(
          // Do the filtering using pure functions
          map( ...
            return myFilterFuntion(filter, data);
          )
        )
   };

The business logic is the same as in imperative-pull code. But using the abstraction of RxJS a lot of boilerplate and indirection vanishes. RxJS is not the easiest abstraction to learn (for me), but as with all, once you're comfortable a lot of the likely intimidating code above will become familiar. You just focus on writing business-logic in pure functions and combine it with RxJS.

Hmmmm, I wonder how a subscription can cause side effects? I can only think of mutating the data in the subscription. But that should not be done.

We are using RxJS with great success but you should go all the way with Observables: All computations/combination/etc. should be done in pipe()s. If you need to combine some plain data with Observables create a subject for the plain data and pipe(combineLatest(),map(), ...). Don't mix it into subscriptions. Subscribe at the very end of the chain. No modification in subscribtions.

Comments URL: https://news.ycombinator.com/item?id=16801973

Points: 1

# Comments: 0

However, you have to be prepared for a serious learning curve when needing customizing (e.g. attribute based authorization with Spring Security and AOP). It's a jump in the cold water after the pain- and effortless start using Spring Boot.

I haven't mastered Spring yet (in depth understanding of DI, AOP and the configuration), but I feel that when mastered, Spring is the ultimate framework to build concise and clean applications.