Earlier quoted context omitted.
I have good and bad experience as well. I do have a prototype project, and while it allowed to get going quickly, I found the remote debugging story useless, as Visual Studio 2022 SSH support is a steaming pile of garbage. (Doesn't use the windows systemwise ssh install, but some crappy library that only supports password auth, or some wonkny certificate format, and outdated ciphers, which is understandably disabled,…
i just recently switched from VS 2022 remote to VS Code, (windows->linux, C++) and it works very well. i'm not sure i have many reasons to keep VS 2022 around right now
.NET 8 Standalone 50% Smaller On Linux
161–170 of 179 posts
Re: .NET 8 Standalone 50% Smaller On Linux
#162Earlier quoted context omitted.
I was helping some friends with F# homework, and being a Rust programmer, I had to ask: your project file is XML, and the order you list the project files matter, and it won’t tell you that you listed them wrong? Compile errors are super long lines and don’t show an excerpt of the code with underline under what went wrong with suggestions on how to fix it? I know I’m asking a lot here, but that level is available wit…
You are touching upon some of the reasons why C# is unproductive for us. Because aside from when its "included batteries" decide to in-fight, there is also the parts where the "magic" breaks. This is more anecdotal, however, since it's going to depend a lot on who you and your team are. The guy I was discussing with made a point about C# being very easy to on-board new developers in, which is probably true for them.…
But yes .. when you step out of the well-defined area in .net you have an "Apple moment" where trying to do something they didn't anticipate or actively dislike becomes wildly, unreasonably difficult and you get pushed down a hacking rabbithole. I'm quite proficient at MSBuild now but I shouldn't have to be.
Re: .NET 8 Standalone 50% Smaller On Linux
#163Earlier quoted context omitted.
You are touching upon some of the reasons why C# is unproductive for us. Because aside from when its "included batteries" decide to in-fight, there is also the parts where the "magic" breaks. This is more anecdotal, however, since it's going to depend a lot on who you and your team are. The guy I was discussing with made a point about C# being very easy to on-board new developers in, which is probably true for them.…
> it's not like they couldn't have taken inspiration from other languages and done it right That’s literally it: they couldn’t. It’s hard to duplicate good effort and make it profitable. So many people make either valuable or well-made things.
Explain? This isn't an assembly line, it's not a question of scaling handmade artisanship.
Re: .NET 8 Standalone 50% Smaller On Linux
#164Anyone knows other alternatives for Azure Functions, but for DIY hosting? ( eg. OpenFaas - https://www.openfaas.com/ )
> The Azure Functions service is made up of two key components: a runtime and a scale controller. ... The Azure Functions runtime can run anywhere. ... The scale controller monitors the rate of events that are targeting your function, and proactively scales the number of instances running your app.
> Kubernetes-based Functions provides the Functions runtime in a Docker container with event-driven scaling through KEDA. ... Using Functions containers with KEDA makes it possible to replicate serverless function capabilities in any Kubernetes cluster.
[0] https://learn.microsoft.com/en-us/azure/azure-functions/func...
Re: .NET 8 Standalone 50% Smaller On Linux
#165Earlier quoted context omitted.
C# approach to concurrency has always been better since its introduction. It does have Channels which offer more focused pattern for SPSC, MPMC, etc. scenarios but neither Java nor Go offer a comparable level of ease of use as C#’s hot-started tasks: // The tasks will run in parallel var data = service.GetData(id); var user = service.GetUser(name); Handle(await data, await user); Re: the above comment on switching to…
Your example is not concurrency though, it’s parallelism. You’re consuming two different services at the same time and waiting for the result. What you would want to showcase is how you handle two different consumers calling a single service. The difference is rather important once you have many consumers calling a lot of services and your computation needs to be done on the right state. As a side note I really don’t…
If two callers call the same method concurrently, whether it requires any synchronization or a more advanced primitive like Channel (for which C# has well-written implementation) or nothing at all is a case-by-case choice.
Java's parallelism by definition cannot be better because they had to retrofit a green threads design onto existing ecosystem, only ever addressing the hardware thread blocking issue with all the ceremony and bloat to do the most basic actions concurrently and/or in parallel still remaining in place.
Java requires far more steps to achieve comparable behavior for what C# requires you doing nothing or a method call at most. Dispatching array elements to a consumer in parallel? call .AsParallel(), and no, Java's Stream API requires more work. Want to fire off two asynchronously completing methods? Just use the example above, neither Java nor Go can hold a candle to this. Methods are CPU-bound and blocking? Easy - just use Task.Run to achieve the same.
Re: .NET 8 Standalone 50% Smaller On Linux
#166Anyone knows other alternatives for Azure Functions, but for DIY hosting? ( eg. OpenFaas - https://www.openfaas.com/ )
Yes: Azure Functions on K8s. [0] > The Azure Functions service is made up of two key components: a runtime and a scale controller. ... The Azure Functions runtime can run anywhere. ... The scale controller monitors the rate of events that are targeting your function, and proactively scales the number of instances running your app. > Kubernetes-based Functions provides the Functions runtime in a Docker container with…
A bit overkill to use k8s for my use-case, but didn't knew it was possible for AF.
Re: .NET 8 Standalone 50% Smaller On Linux
#167Earlier quoted context omitted.
i just recently switched from VS 2022 remote to VS Code, (windows->linux, C++) and it works very well. i'm not sure i have many reasons to keep VS 2022 around right now
I'm eyeing with Rider, just have no capacity at the moment to evaluate it thoroughly.
Re: .NET 8 Standalone 50% Smaller On Linux
#168Everything dotnet is doing for cross-platform is great and better than alternatives --- except one HUGE issue: There is no official GUI on Linux. Linux's exclusion from MAUI (while 25% of world's developers' primary dev machine is a Linux system according to Stack overflow survery) creates a huge hurdle for those developing on Linux to build any cross platform GUI app with dotnet. If I , as a developer developing a w…
Avalonia exists, and from the looks of it is better than all the crap MS has put out over the years (even on Windows, don't get me started on WPF shutters) so not using it because its not "official" is silly.
Re: .NET 8 Standalone 50% Smaller On Linux
#169Earlier quoted context omitted.
Your example is not concurrency though, it’s parallelism. You’re consuming two different services at the same time and waiting for the result. What you would want to showcase is how you handle two different consumers calling a single service. The difference is rather important once you have many consumers calling a lot of services and your computation needs to be done on the right state. As a side note I really don’t…
It is both, please do not misconstrue this. If two callers call the same method concurrently, whether it requires any synchronization or a more advanced primitive like Channel (for which C# has well-written implementation) or nothing at all is a case-by-case choice. Java's parallelism by definition cannot be better because they had to retrofit a green threads design onto existing ecosystem, only ever addressing the h…
I’m sorry, but it’s really not the same thing. You appear very confident, and sort of rude, in your argumentation, but there is just such a huge difference between parallelism and concurrency I don’t even know where to begin. I mean, you’re talking about (a)synchronous calls, tasks, and, what not, but what you need to solve is when two thousand sensors want to update the same data through the same service all at once. And they want to do this fairly often.
In reality it’s even more complex than this because a lot of the sensors carry data on behalf of each other so often you’ll receive the same data multiple times and so on, but there isn’t much need to get into that.
But hey, you do you, if C# works for you, great.
Re: .NET 8 Standalone 50% Smaller On Linux
#170Earlier quoted context omitted.
It is both, please do not misconstrue this. If two callers call the same method concurrently, whether it requires any synchronization or a more advanced primitive like Channel (for which C# has well-written implementation) or nothing at all is a case-by-case choice. Java's parallelism by definition cannot be better because they had to retrofit a green threads design onto existing ecosystem, only ever addressing the h…
> It is both, please do not misconstrue this. I’m sorry, but it’s really not the same thing. You appear very confident, and sort of rude, in your argumentation, but there is just such a huge difference between parallelism and concurrency I don’t even know where to begin. I mean, you’re talking about (a)synchronous calls, tasks, and, what not, but what you need to solve is when two thousand sensors want to update the…