181–190 of 205 posts
Earlier quoted context omitted.
It does matter because there is a portion that is toxic in about any sizeable community, so following that logic all wells would be easily poisoned
All wells are easily poisoned, though; Hyprland for example.
Earlier quoted context omitted.
Pretty much every non-GUI (and GUI if it's Avalonia/Uno/etc.) .NET application, unless it uses niche things like windows registery or management API, is by definition platform agnostic and runs wherever .NET runs (macOS, Linux, FreeBSD(with caveats), Android, iOS, Windows, sometimes in browser with WASM). Most businesses which have moved away from old versions run their server workloads on Linux hosts within K8S or o…
Also git credential manager: https://github.com/git-ecosystem/git-credential-manager
Earlier quoted context omitted.
Until Zig has a good story for use after free, I wouldn't be considering it. Regarding C#, there was some research work at MSR for improving escape analysis and IDispose usage via lifetime analysis, but seems to never have moved beyond proof of concept. By the way, Midori internal presentation from 2013 is doing the rounds on twittersphere.
I don't think there was any work on escape analysis in current .NET related to Midori, at the very least not in public. However, there has been separate research and support for object escape analysis unrelated to this. Here's the rough timeline of the work: Initial issue https://github.com/dotnet/runtime/issues/11192 was submitted in 2018 and concerns general research direction on feasibility and profitability of EA…
I was talking about this kind of research papers, there was one also about linear/affine types in a C# extension, similar to Spec#, System C# and others, but I can't get the title right to find it.
"Uniqueness and Reference Immutability for Safe Parallelism"
https://www.microsoft.com/en-us/research/publication/uniquen...
"Simple, Fast and Safe Manual Memory Management"
https://www.microsoft.com/en-us/research/publication/simple-...
Earlier quoted context omitted.
For years, whenever there was drama and shit-flinging in the OSS world, i looked up the people causing that on github and blocked them. Github has this feature that it warns you when you look at a repository where people you blocked contributed. If you keep such a list, you'll easily recognize projects you better stay away from. For me, this was one of the reasons to keep away from Rust.
That sounds flawed to me. A large block list will disproportionately warn you about projects that are more open to any external contribution in general. Guilt by association is a weird standard for FOSS contributions. I certainly don't review the external lives of contributors on my repositories.
For those who are worried, Andreas is a thoughtful dude. This decision was not made on a whim. Also, they’re not doing a massive rewrite: > The Swift team is also investing heavily in C++ interop, which means there's a real path to incremental adoption, not just gigantic rewrites. To me, the Tweet does a good job justifying the decision. I’m rooting for Ladybird, and I hope this decision pays off. A modern browser in…
> For those who are worried, Andreas is a thoughtful dude. This decision was not made on a whim. Yes. But many terrible decisions are taken this same way. > and I hope this decision pays off It is terrible when we need to hope for something to succeed because we see that they are clearly doing something wrong but will do it that way anyway because they are strong-willed. Just take the obvious path everybody is pointi…
There you go, we have immature industry if Rust or Swift is only logical choice to substitute C++, maybe working on a better language would be such a bad idea after all, meanwhile still long on Jai.
On a language which doesn't have any safety, doesn't plan on implementing basic features such as incremental compilation, tagged unions, async, or package management and others, and nobody is currently working on? Good luck.
Hm. Not sure, if this is really a wise choice. After all they are choosing to use an Apple controlled programming language. Whatever direction Apple wants to go in, they will face themselves with following or working around. As an example we can look at Go and the whole GOPROXY debacle. And they will also have to deal with Apple not going into a direction, if they need that direction. Might have to build more stuff t…
Earlier quoted context omitted.
This is an old argument, and it’s well understood that “GC” by default refers to tracing GC and delayed collection. (Without delayed collection, there arguably isn’t any “garbage” in the first place.) “Can do C++ style memory management” is very different from what happens when coding in the default idiomatic style of the language and when using existing libraries written in the language. What happens by default is a…
Understood as such by those that don't grok CS. What is relevant is if one is actually skilled in using their tools, or should be doing something else instead.
The definition of GC encompassing RC has fallen out of favour because it doesn’t capture the essential distinctions that people want to make: firstly, are cycles broken automatically? secondly, is there any tracing process happening behind the scenes?
Most people are happy to accept that CPython is GC because it does RC and cycle collection so you are managing memory thinking about paths from a root, but not Swift because you are managing memory thinking about an ownership graph.
In the past, people wanted to make a different distinction: is the CPU having to do extra work to keep track of a reference count. When CPUs were slow, this was an important distinction to make. Nowadays it’s a less important distinction so the definition has evolved.
I had suspected this would happen, I haven’t got into Swift yet (I’m mostly doing embedded C still) but Swift finally seems to have just ticked off some niggles that makes it a much stronger contender. Things like not having official Debian builds (there were Ubuntu etc.), not being able to run under other C libraries like musl (like if you want to run in Alpine Linux containers), not really being able to run embedde…
Honestly, Swift seems like such a nice language. Most of the performance and power, great interop, but more directed at application development than Rust (with e.g. refcounting being the default). But as they say, you choose a language for its ecosystem, not for the language itself. It would be great if Swift’s open source ecosystem for stuff other than app development grew. It does indeed seem like Apple is pushing…
Given that this is Ladybird, which came out of the Serenity OS project (which didn't allow any external code at all), it's not surprising that they didn't prioritize ecosystem when picking a language. I believe they're planning on being less strict about that with Ladybird, but the culture of independence is likely still there.