https://doc.rust-lang.org/1.30.0/book/second-edition/ch16-00...
These sound like quite bold claims to me.
148 karma · joined December 18, 2013
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://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<ParamMap>
): Observable<MyData> => {
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()
);
};
Then it goes on with filtering, etc. 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<string>,
data$: Observable<MyData>): Observable<MyData> => {
combineLatest(filter$, data$).pipe(
// Do the filtering using pure functions
map( ...
return myFilterFuntion(filter, data);
)
)
};
The filteredData$ Observable can be consumed via async pipe in a component.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.
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.
It's plain stupid to forget that wolves are predators.
Now, it all depends what you prefer / what's good for you. For me it was a huge productivity boost to switch to Angular because they just tell me how to do things. I don't spend much time on thinking how to architecture or about which library to choose (e.g. MobX vs. Redux), I just do it. With WebStorm it's two clicks to get a component / service / etc. scaffolded. That is pretty much the fasted it can get. Once you know Angular, you can develop really fast despite it's complexity.
But that's really a personal choice. If you need structure and tend to get lost in decision making, give Angular a try.
For the same reasons I'd choose for larger teams.
Then the whole Nokia mess ... what a sad story.
I remember when I finally gave up any hope for Windows Phone: It was when I read that Samsung and HTC ought to pay license fee to Microsoft. That was probably the biggest mistake in Microsoft's history. They should have payed them 50 $ per sold Smartphone with Windows Phone on it.
Anyway - I still have a Windows Phone from my employee and like it.
It seems to have features that the standard edition doesn't have. But does the standard edition have feature the dev edition doesen't?
Or are there some different features? Any of them reason not to use the dev edition in daily browsing?
If you want to do something good for your health, drink herbal tea. But why do most of the people prefer coffee or green / black tea? Or drink red wine or eat lots of dark chocolate. Because those are stimulants.
Edit: And can be easily customized.
Those people often see that helping others is a true source of happiness.
Matthieu Ricard is a quite famous monk having published a lot of interesting stuff:
http://www.matthieuricard.org/en/
This one is on the topic:
http://www.matthieuricard.org/en/books/happiness-a-guide-to-...