useerup

Death is a moral responsibility. You owe your existence to evolution. Evolution would not work if we had to compete for resources with all of the organisms that came before us when they didn't die off. Death is an integral part of living a bringing our species forward. Your responsibility is to make the best of your time here. Have fun, love, and contribute to society and science if you can. Then die and make room for the next generations.

Microsoft has ported CLR (.NET Core) to Webassembly and it runs in the browser. You can indeed run CLR code in the browser. That is how Blazor works

So much was so right about PowerShell. But it failed to attract a wider audience, and in their quest to woo Linux devs Microsoft has been undermining PowerShell lately. Knowing what PowerShell offers, falling back to bash CLI tools feels like two steps back.

Just some of the stuff PowerShell did right:

- PowerShell cmdlets are self-describing and rich in information. Rather than each command doing its own parsing of parameters, cmdlets describe parameters and delegates the actual parsing to the shell. The shell understands data types, parsing rules, e.g. how to parse a UUID or a date. Not only does this ensure a consistency that was never in *sh shells, but it also enables cool stuff like e.g. autocomplete, predictive input, help instructions etc. almost for free.

- "Simulation" mode (-Confirm and -WhatIf) where a cmdlet can describe the action it is about to take, and the mode of the shell may decline everything (effectively a "simulation mode") or may actually ask the user for permission (-Conform) for each action.

But, alas, PowerShell never caught on outside Windows, and now MS is leaving it to wither in their quest to not upset a wider non-Windows community.

The first .NET Blazor "webassembly" was the .NET runtime ported to Webassembly, but where developer code would actually be the same type of IL (Microsoft's Intermediate Labguage) as .NET runs on Windows and Linux.

Unlike those platforms however, the IL was actually interpreted by the ported .NET runtime. Only the runtime was actually running as WASM.

To this day this is still the default, but now you can use a compiler to compile from IL to WASM, and then run full WASM code in the browser. This toolchain is a bit slower on build, but the code will run much faster.

Worse, it won't ever work if you intended it to be a JavaScript replacement because it cannot integrate into the interaction of the surrounding page, because it is a sandbox without compromise

That is a pretty bold statement considering that Blazor actually does allow you to ditch JavaScript and very much integrates with the surrounding page.

It is true that for manipulating the DOM, Blazor internally needs to go through JavaScript as there are no direct WASM-to-DOM binding (yet).

But you, as a developer, can develop sites that runs its interactivity using webassembly instead of Javascript.

I believe because the C# version has been written using rectangular arrays. This requires every array access to use a multiplication. The Java version uses array-of-arrays and hoisting the inner array out before accessing it in the inner loop.

C# also has arrays-of-arrays, and could (should) be written in the same manner.

I use grocery store apps where I can scan the items with my phone as I put them in my bag. Checkout is then only swipe to pay. There are occasional random inspections, otherwise I completely skip the checkout lines.

Here in Denmark we also have a driver's license app. The app has a feature through which the user can identify themself to another party using the same app on their phone.

When used to identify, the app displays a series of QR codes which can be recorded by the 2nd phone through the camera. No need to hand over th e phone. It tranfers identifying information such as name, age and the photo so that the 2nd party can use it to validate on their screen.

Blazor - until .NET 8 - came in Blazor Server and Blazoe Webassembly variants.

Blazor Server renders the DOM at the server and sends it to the browser. The server also holds on to some state for each client - notably the "current DOM" - so that it can calculate diffs on changes and only send the diffs to the browser.

Blazor Webassembly does the rendering in Webassembly in the browser. The .NET stack runs in the browser. Here, the code renders and diffs in the browser and the the diffs are applied to the DOM as well.

This also means that the same components can run either server-side or client-side. They basically all end up computing DOM diffs and applying those diffs to the actual DOM. Pretty neat, actually.

Each model has it's pro and cons. Blazor Server initialized really quickly and relies on minimal Javascript in the browser. But it creates load and server affinity on the server. Blazor Webassembly offloads all rendering to the browser, but at the cost of an initial load of the code.

In .NET 8 these can now be blended, and a new "auto" mode allows a component to be initially server-side and then client-side when the webassembly code has downloaded.

In addition to that is now (.NET 8) also the static server side rendering (and "enhanced navigation") which you could say is server side components without the "circuit" server affinity and server state of each client. Static server side rendering has some limitations on how interactive they can be - i.e. changing the DOM.

A cube of water 1cm * 1cm * 1cm = 1cm^3 has a mass of 1 gram. A cube of water 1m * 1m * 1m is 1000 liters and has a mass of 1000 kg

The SI units are supposed to be related like that.

This comment make me question if you really have any experience with LINQ. If you had, you would not make a comment where you seem to think that LINQ is used only for data access.

LINQ is (at the most basic level) list comprehensions done better. It is functional programming for the imperative C# programmers. It has the potential to remove most/all loops and make the code more readable in the process.

Unfortunately basic mistakes can result in so many of those N+1 type queries if you're not careful. It can also result in reading entire table(s), possibly inside those nested N+1s.

I don't know which "basic mistake" would do this. Maybe when using Lazy loading Proxies?

We use EF Core and it is quite easy to control eager loading or load-on-demand on a per-case basis.

I dont think EF ever did that. However, if you used automatic lazy loading and you somehow inadvertently referenced the collection, then yes, it would lazy load the related entities.

Sooo it’s dapper with string interpolation override to make queries parameterized so you don’t need to manually put the parameters on as 2nd arguments?

Pretty much. C# does some really cool innovations around string interpolation which proves very useful for logging, SQL query etc.

You can create your own string interpolation handler, which is what the new SQL query does and what several log libraries do. So basically you can use interpolation safely and remain assured that you do not introduce SQL injection errors. Also, this way string interpolation does not prevent query plan caching, as normal string interpolation would do.

Blazor computes the DOM deltas in webassembly/.NET code in the browser and then sends those deltas to the translation layer which then performs the changes to the DOM. This process would get a considerable performance boost if webassembly were allowed to access the DOM directly.

Silverlight required a plug-in. That's a barrier to adoption that they never overcame. When plugins were outlawed it was impossible to continue Silverlight. Microsoft had seen the writing on the wall and had effectively abandoned Silverligt as a strategic product long before that. Blazor Webassembly is not in the same situation. Webassembly is not going to be pulled. Webassembly is objectively better than Javascript for the task of running code in the browser, so my prediction is that Javascript will be deprecated before Webassembly.

Actually, many western number systems have traces from base 20. Just consider how you have names for numbers up until 20.

In Danish, the way we name numbers are heavily inspired by French, which also exhibit traces from base 20.

The name in Danish for 60 and 80 in modern Danish are "tre(d)s" and "firs", respectively. These are shortened forms of "tredsindstyvende" and "firsindstyvende" used historically, literally meaning "3 times 20" and "4 times 20", respectively. The number for 50 is "halvtreds" - derived from "half way to treds (60)" - meaning half way (when the "way" is 20 long) between 40 and 60.

In french 80 is quatre-vingt (4-20).

If anything, arguably our common system in which we have named numbers up until 20 (i.e. base-20) and then shift to base-10 for numbers above 20 is illogical.

Any other suggestions?

Futhark: https://futhark-lang.org/

Microsoft also seems to be prioritizing Typescript and Node internally with its recent moves.

You may want to look at Blazor Webassembly (https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...) and Blazor United (https://devblogs.microsoft.com/dotnet/asp-net-core-updates-i...)

They scrapped the old CLR and started over with a new "CLR Core".

Then they ported the new CLR Core along with the framework BCL to webassembly and has the CLR running in the browser, upon which they built Blazor Webassembly.

So you can now target the CLR and have your code run in the browser.

And now they are making progress on Blazor Unified where components can start of as server-side rendered exclusively and transparently and automatically move to webassembly rendering within the same application or page. It really is crazy stuff.

Typescript is not the only thing going on in MS Engineering.

Summary is a bit misleading. This is about the fourth vaccine shot (2nd booster if you will). Vaccines are still recommended (and free) in Denmark if you are not vaccinated yet. The fourth shot is offered to above-50 residents and below-50 residents in risk groups.

Blazor Server requires a peristent websocket connection to each client to execute the C# code you write on the client and maintain state

Blazor Server retains the circuit for up to 3 minutes if the connection is lost, so you do not loose the connection even if the websocket connection is interrupted.

It is also not correct that it needs a websocket connection. It builds on SignalR which will use websockets if available but will fall back to other methods such as long polling to emulate a persistent connection.

Blazor Server absolutely has it's place, but you need to know when that is. You can even scale it out on multiple servers, but at least until .NET 7 you'll need to ensure "sticky" connections (the client must connect to the same server based on e.g. IP address, cookie or similar).

Does anyone else get the feeling that we (as a field) are missing something basic about concurrency? Like there's a really elegant solution just around the corner, that has the low overhead of async/await without the complexity. Or otherwise put, the ease of goroutines but without GC.

Yes. There is current research into Algebraic Effects (see for instance https://www.microsoft.com/en-us/research/wp-content/uploads/...).

Algebraic Effects promise a return to non-colored functions, as AE can abstract over exceptions, continuations, async and other control-flow mechanisms.

The "Sdk.Web thing" is the way the project is built.

As I and several people in this thread has pointed out to you, the application the resulting application is not a "web" application. It is a console app that launches a webserver.

The Sdk (without web) is not designed to compile cshtml and/or razor source files. It has nothing to do with package dependencies.

If you do want to start of with a console app sdk, then look at "minimal API". You simply add package references to Microsoft.AspNetCore and Microsoft.AspNetCore.App to your console app, and then you can start using the minimal API samples. They will also launch a website.

The example I showed you above was literally adding two lines and changing one line; and then you had a console app which asked the port and launched a webserver on that port.

If you start from a console app, you will not have build targets configured for cdhtml and razor files. However, to prove that you can launch a webserver the same way you can do this (yes I have tried it and it works):

1) Add dependencies to your "console sdk" project:

    <PackageReference Include="Microsoft.AspNetCore" Version="2.2.0" />
    <PackageReference Include="Microsoft.AspNetCore.App" Version="2.2.8" />

    using Microsoft.AspNetCore.Builder;
    var builder = WebApplication.CreateBuilder(args);
    var app = builder.Build();
    app.MapGet("/", () => "Hello World!");
    app.Run();

I did. It works. The above code lines are cut directly from a test project that I made.

Several people have pointed out how a web app in .NET 5/6 is really a console app which only starts a web server configured with an application and waits for it to complete (i.e. shut down).

It really is that simple.

1. Create a new web project (it is actually a console app)

2. In program.cs add the following lines at the top:

    Console.Write("Port number:");
    var port = int.Parse(Console.ReadLine());

    app.Run($"https://localhost:{port}");

A `Microsoft.NET.Sdk.Web` project is still a console app. The "web" variant has some other default packages and (crucially) it has some other defaults for how to compile files such as cshtml.

Yes. Almost all DBMSs has a way to delimit table/column names (for instance when a name contains spaces or special characters.

However, proper DBMSs expose parameters as 1st class concepts through the API. That has several advantages, some of which:

1) It is more secure, as you will not have to do this dangerous escaping before invoking. Parameters are substituted by the DBMS.

2) The DBMS can better understand the "dynamic" part of a query and cache query plans.

of course, in a large sense, the one that hits from behind is at fault

I don't know where you live, but where I live (Denmark) brake-checking is a serious traffic offense which can lead to loss of license. While the driver behind has to keep distance, you cannot brake for non-traffic reasons. I.e. you cannot simply brake-check someone on the freeway because you think the driver behind you is driving too close (also a serious offense).

`ls | sort --time` is very close to `ls | sort LastWriteTime` which is how you would do it in PowerShell.

In PowerShell `ls` is only used for retrieving the filesystem objects (files and directories). It does not have options for sorting or formatting[1]

Sorting is generally handled by `sort` (alias for the Sort-Object cmdlet).

Formatting is generally handled by one of the format commands, like format-table (alias `ft`) or format-list (alias `fl`) or by converting into another format like e.g. json or xml through `convertto-json`.

I.e. if I want to display the full path of every file sorted by descending by last access, I would write:

    ls | sort -d LastAccessTime | select fullname

... commands accept and parse arbitrary strings as input instead of formally specifying it like a function signature + docblock. If I could rewrite the universe, commands would use a central API for specifying the names, data types, descriptions, etc. for all the input they take

Which is exactly what powershell does: Commands in powershell (called "cmdlets") are like functions with type hints. A command does not parse the input strings itself, rather it exposes this type information to the shell. The shell is the one responsible for discovering the parameters (and types) and parsing the command line parameters and coercing types before passing them (strongly typed) to the actual command.

This means that the information about parameter names and types is readily available for doc-generation, auto tab-completion and language servers which allow syntax highlighting, completion etc to work even inside editors such as vscode or emacs.

The point is that to specify a cmdket you must declare parameters, in much the same way that for a function in a programming language to accept parameters it must declare those as formal parameters.

Sure ls has a 58 (!) arguments but it's still a tool to list files ultimately.

No, it has evolved into a tool to get files/directories of a directory and sort them and format them.

Powershell separates those. `ls` in Powershell gets filesystem objects. It does not have any of the nix craziness for controlling the output and sorting, yet it is possible to do the exact same thing by piping output from ls into a format-command like format-table(ft), format-list(fl) or even convertto-json

It's not dynamic. It is structural typing