Around 15 years ago I needed to build an internal app for my company that would aggregate and display a lot of data. Our backends were all in Java and I had sour taste for JavaScript from a previous project so I looked around for an AJAX framework that would allow me to avoid writing any JavaScript. Lo and Behold there were actually 2 viable ones on the market: Google GWT and Echo2. I played with both of them and Echo2 blew me away. It looked and acted better than anything else on the market at the time. Rich widgets, translucency, works in (almost) any browser, etc. I rolled an app with it. The mechanism of operation was pretty similar to LiveView except WebSockets didn't exist at the time so it worked by having a super thin JavaScript client that polled the web server on the regular basis. So yeah, a bit chatty but for intranet app I didn't care much. Everything worked and felt like it was a Java Swing app but in a browser. The app became popular and we started writing extensions to it and adding modules. Then inevitable customization came. "Can we create a widget that does X?" "Ughh let me take a look.". This is when my nightmare began. Writing a new widget for this thing required putting together some utterly nightmarish JavaScript code and then compiling it together with equally nightmarish piece of Java code. If you had any custom stylesheet you basically were screwed. So roughly 2 years down the road from starting the project I started rewriting it in pure JavaScript and ExtJS (now called Sencha), which was one of the first few juggernaut frameworks for writing SPAs circa 2007-2008. That's why when things like Blazor and LiveView roll around I get flashbacks akin to post traumatic stress disorder.
I remember when Sencha came on the scene :) WebSocket's help for more efficient bidirectional comms and guarantee load-balanced process placement, but LiveView can also be used with long polling if folks have a hard requirement. We also have much better DOM apis for things like efficient diffing/patching that I'm sure you lacked back then. Were you keeping stateful "widgets" on the Java side or hydrating from client state for interactions?
>We also have much better DOM apis for things like efficient diffing/patching >that I'm sure you lacked back then
Oh I hope so. I marvel at React virtual DOM magic on daily basis so I'm sure it can be all done a lot more efficiently these days.
>Were you keeping stateful "widgets" on the Java side or hydrating from client >state for interactions?
IIRC it was 90% on the Java side. The default polling rate was something along the lines of 200 ms. So if you clicked a checkbox on the front end, it would perform the animation for clicking it on the front end but it wasn't considered checked until the backend was informed of it and signed off on it. In Java code if you had a listener for onClick you would write a normal Java method and it would get invoked normally with access to all your server stuff. As you can imagine, Echo2 server session objects could get pretty heavy. Reminded me a bit of mainframes and terminal clients lol :)
>I think many of these workers are laid off so they can get unemployment benefits, and they'll be hired again by the same companies as soon as the quarantine end
That is highly doubtful. Many companies can't survive even 2 months of inactivity and will fold.
>which should take a couple month if we look at what happened in China.
China is undergoing a second wave right now [1] due to unlocking quarantine too early. It's extremely likely that they will be undergoing a second lockdown. Anecdotally, speaking to a lot of my friends in NYC most everyone who is currently WFH (myself included) isn't planning on returning back to the offices until at least the end of the year. Realistically, I think we won't fully get rid of lockdowns until vaccine is available and 80% of the population is vaccinated.
> All those services, and a bunch of other services for small businesses are possible because of Wechat.
Ughh, no thanks buddy. I'd rather not have any of this propaganda garbage. WeChat basically contributed to a global pandemic because it's prime instrument of Chinese censorship[1].
That's what skeptics in Italy were originally saying. Now people in Lombardy are dying from strokes because hospitals can't admit them because ICU is overrun by Covid-19 patients. Sure, if you break your leg and die from bleeding out because all local hospitals are busy treating bilateral pneumonia patients you technically didn't die from Covid-19, but ....
> Now people in Lombardy are dying from strokes because hospitals can't admit them
Now wait a minute. If you have a source on that, please do provide it. Because I am from Italy and I have never heard of such things. (There were cases of people who died from a stroke and tested positive to COVID-19, but that's all I know)
Thank you, even though I am honestly not sure if I can trust a Twitter thread.
For instance, this article [1] (in Italian) says that "up until now [yesterday], no patient who could have benefited from intensive care has been excluded". BUT it also says Lombardy might be headed that way if the virus keeps spreading at this rate.
Just to be clear, I do not want to downplay what is happening in any way. But I feel it is better if we stick to verifiable info.
This is where I'm currently battling my south-Denver community. They're all up in arms reciting the GP's facts-in-a-vaccuum. They honestly don't give a rip about the extreme pressure it's put on healthcare systems in Italy (let alone Seattle). They're mad at the local government for "bordering on hysteria" because they're following the South Korean model for management.
Once it's fully spread through our community because the've decided they're entitled to be carriers (because, hey, you're more likely to die of the flu), they'll blame that same government for failing to provide the requisite care in the community.
Currently it's very difficult to reason about object geometric dimensions / movement from video alone. We (humans) are decent at it and we still make mistakes. "The right ML algorithm" for this is basically a problem as hard as achieving singularity.
>Nothing about the greenest and most sustainable solution: reducing consumption.
Well that's because it's not a realistic solution. Any solution that goes against the human nature is doomed to fail. Our species historically had issues with implementing solutions that require short-term detriment no matter how large the long term benefits were. Montreal protocol is often cited as one of these collective actions that succeeded, however what is NOT often cited is that the cost of implementing it was tiny compared to respective countries GDP. I.e. millions, not billions of USD.
>Java finally gets what's been available in Scala (case classes), C# (structs or maybe properties), Kotlin (data classes) and others for a very long time .. so long we already have tools like Immutables and Lombok to get past this really dumb limitation in Java.
All the ones you named are fairly new languages, and C# does not have anything even remotely like records (structs are value types, and properties are fields) so what's your point? Java historically has been very conservative with implementing things because they usually try to get it right (generics non-withstanding). For that matter C# rushed into a few things too and screwed the pooch badly on them.
I'd be curious which features you think C# messed up on. I have been using C# professionally since 2000 in it's first beta and can't think of a newer feature that would meet this criteria?
That said you are correct about records. Although it is getting them also.
The one that annoys me the most in C# on a day-to-day basis is Nullable<T>. Java took their time with Optional<T> but once it was released it was great. Can be used in lambdas, all libraries are modified and aware of it etc. C# Nullable<T> is near useless because it only works on value types. I.e., you know, the types that are least likely to generate NullReferenceException for you.
In both C# and Java, reference types are nullable. Nullable<T> exists in C# to provide for nullable value types. It's not comparable to Optional<T> as that's an entirely different feature.
> C# Nullable<T> is near useless because it only works on value types. I.e., you know, the types that are least likely to generate NullReferenceException for you.
You are completely missing the point of Nullable. It was introduced because databases allowed int, float, etc ( value types ) to be null. It was never meant to be an Option type. Reference types are already "nullable" so the database returning null for strings wasn't a problem. But databases returning nulls for int was a problem. It led to performance issues ( boxing and/or adding additional code to marshal data from one source to another ). If you find Nullable to be annoying then you either don't code in C# much and you especially don't deal with data/databases.
For what it was intended for, Nullable did it's job. And if Nullable is your only complaint, given the extraordinary changes that C# has gone through, I think it speaks well for C#.
Nullable/Non-nullable reference types in C# 8.0 having nothing to do with Nullable<T> and aren't even implemented using it.
C# 8.0 implementation of something like Optional<T> for reference types uses static flow analysis to ensure correct use of potentially null values. That's vastly superior in every way to Optional<T>.
Because they live on the stack and follow the rules of value types you really shouldn't be using them for anything major. I.e. you want to model a SQL query result for a table with more than 3 columns? Probably struct is NOT the way to go, use a POCO class.
Well of course. Just like an int doesn't always live on the stuck. I.e. when it's declared as a field for example. If you are piping data from SQL DB into a List<YourStruct> the list is a reference type and will of course be on the heap.
Another issue with struct being big is really when it's being passed around and value copying starts to occur. You want to minimize this if the struct is large. My point being is that if in doubt, you probably don't want to use a struct and hence it's not a general purpose data container.
They mention Bellingcat in the article but what they don't mention is that their "verification" essentially piggy-backed on top of identical Bellingcat verification of a the same video that got released 14 hours prior [1]. This seems strange to me.
I would recommend trying this one first to see how you like it. In general coding fonts are sort of a very personal thing - everyone is different.
I started a new job 1.5 months ago which facilitated a jump from IntelliJ to Visual Studio. I've been trying to find a good editor font as the Consolas that was the default for VS 2019 just didn't agree with me. I'm ok with Consolas in bash terminal but somehow inside VS it bugs me. I tried a few of my Mac favorites like Monaco and Menlo. Was using Menlo and it was a decent experience. Tried this JetBrains one and so far so good. It just works for me. I think will keep it.
