I own a Framework 13. It’s slightly overpriced but I would take it any day over a MacBook. It runs Linux perfectly fine with no driver issues and is in general pretty high quality.
I don’t think that’s bad to be in the raw training data per-se. Such content will be RLHF’ed out. Some users will certainly ask it for such tasks and it will somewhat deliver
I can't speak for the mentioned app (rem), but I built my own app with a similar feature set called ScreenMemory (https://screenmemory.app). Which I have obviously used for an extended period of time (coming up on 7 months I believe).
My main and daily use case it to look back at the previous day - this is helpful for standups, retros, and so on. I skim through my days (sometimes weeks) to pick up on what I was working on - it's incredible how much "untracked" work is performed that you pick up on. Sometimes I forget who exactly I talked to about something, but just knowing the rough date I can usually find something to jog my memory.
Google Desktop was the first thing I thought of when I saw the link. One difference with Desktop though is that nowadays people are doing stuff on more than one device. Synching the data somehow or other would presumably involve the sort of cloud services that this developer is avoiding for privacy reasons.
I build a lot of stuff and forget why I did things the way I did.
You can do things like find the point in history where you fixed a bug and go watch yourself debug and put in the fix.
Pretty wild. It makes a lot more sense once you experience getting the value.
Personally I hope Apple adds the feature natively to the OS at some point. They're plenty experienced to build it themselves over there, but maybe having a reference implementation will encourage them to give it a shot.
As long as it’s aimed at people with Chinese citizenship and not anyone that looks remotely Chinese (e.g. Singaporeans, Koreans, etc), I’m not too concerned. They do have laws that force us to look more closely without devolving into pure racism.
The only thing keeping me on an iPhone is that mine hasn’t broken yet and I dislike waste. I got my current phone from a relative that was going to throw it away. Not being able to side load apps & use for development means I pretty much never touch it except for offline maps. It doesn’t even have a SIM card in it
Tangentially related: Is it currently possible to have interop between Go and Rust? I remember seeing someone achieving it with Zig in the middle but can’t for the sake of me find it. Have some legacy Rust code (what??) that I’m hoping to slowly port to Go piece by piece
Yes, you can use CGO to call Rust functions using extern "C" FFI. I gave a talk about how we use it for GitHub code search at RustConf 2023 (https://www.youtube.com/watch?v=KYdlqhb267c) and afterwards I talked to some other folks (like 1Password) who are doing similar things.
It's not a lot of fun because moving types across the C interop boundary is tedious, but it is possible and allows code reuse.
If you want to call from Go into Rust, you can declare any Rust function as `extern "C"` and then call it the same way you would call C from Go. Not sure about going the other way.
It's usually unwise to mix managed and unmanaged memory since the managed code needs to be able to own the memory its freeing and moving whereas the unmanaged code needs to reason about when memory is freed or moved. cgo (and other variants) let you mix FFI calls into unmanaged memory from managed code in Go, but you pay a penalty for it.
In language implementations where GC isn't shared by the different languages calling each other you're always going to have this problem. Mixing managed/unmanaged code is both an old idea and actively researched.
It's almost always a terrible idea to call into managed code from unmanaged code unless you're working directly with an embedded runtime that's been designed for it. And when you do, there's usually a serialization layer in between.
> It's usually unwise to mix managed and unmanaged memory
Broadly stated, you can achieve this by marking a managed object as a GC root whenever it's to be referenced by unmanaged code (so that it won't be freed or moved in that case) and adding finalizers whenever managed objects own or hold refcounted references over unmanaged memory (so that the unmanaged code can reason about these objects being freed). But yes, it's a bit fiddly.
Mixing managed and unmanaged code being an issue is simply not true in programming in general.
It may be an issue in Go or Java, but it just isn't in C# or Swift.
Calling `write` in C# on Unix is as easy as the following snippet and has almost no overhead:
var text = "Hello, World!\n"u8;
Interop.Write(1, text, text.Length);
static unsafe partial class Interop
{
[LibraryImport("libc", EntryPoint = "write")]
public static partial void Write(
nint fd, ReadOnlySpan<byte> buffer, nint length);
}
In addition, unmanaged->managed calls are also rarely an issue, both via function pointers and plain C exports if you build a binary with NativeAOT:
public static class Exports
{
[UnmanagedCallersOnly(EntryPoint = "sum")]
public static nint Sum(nint a, nint b) => a + b;
}
It is indeed true that more complex scenarios may require some form of bespoke embedding/hosting of the runtime, but that is more of a peculiarity of Go and Java, not an actual technical limitation.
It is very easy to call a C# method from C++, since .NET has a COM interop layer. From C++ this will just look as a class with no fields but a bunch of virtual methods. Alternatively, you can easily convert a static method to a native function pointer and then invoke that - this way it's also easy to do from C, Rust, and just about anything else that speaks the C ABI.
If your C# method doesn't take any arguments like managed strings or arrays that require marshaling, it's also very cheap (and there's unsafe pointers, structs, and fixed arrays that can be used at interop boundary to avoid marshaling even for fairly complicated data structures).
.NET was very much designed around these kinds of things. It's not a coincidence that its full type system covers everything that you can find in C.
With that said, Mono has been a staple choice for embedding in game-script style scenarios, in particular, because of the ability to directly call its methods inside (provided the caller honors the calling convention correctly), but it has been slowly becoming more of a liability as you are missing out on a lot of performance by not hosting CoreCLR instead.
For .dll/.so/.dylib's, it is easier and often better to just build a native library with naot instead (the links above, you can also produce statically linkable binaries but it might have issues on e.g. macOS which has...not the most reliable linker that likes to take breaking changes).
This type of library works in almost every scenario a library implemented in C/C++/Rust with C exports does. For example, here someone implemented a hello-world demonstration of using C# to write an OBS plugin: https://sharovarskyi.com/blog/posts/dotnet-obs-plugin-with-n...
I haven't been looking for those because I don't work with .NET. Regardless, what you're linking still needs callers and callees to agree on calling convention and special binding annotations across FFI boundaries which isn't particularly interesting from the perspective of language implementation like the promises of Graal or WASM + GC + component model.
There is no free lunch. WASM just means another lowest common denominator abstraction for FFI. I'm also looking forward to WASM getting actually good so .NET could properly target it (because shipping WASM-compiled GC is really, really painful, it works acceptably today, but could be better). Current WasmGC spec is pretty much unusable by any language that has non-primitive GC implementation.
Just please don't run WASM on the server, we're already getting diminishing generational performance gains in hardware, no need to reduce them further.
The exports in the examples follow C ABI with respective OS/ISA-specific calling convention.
There are more managed langauges than Go, Java, and C#. Swift (and Objective C with ARC) are a bit different in that they don't use mark and sweep/generational GCs for automatic memory management so it's significantly less of an issue. Compare with Lua, Python, JS, etc where there's a serialization boundary between the two.
But I stand by what I said. It's generally unwise to mix the two, particularly calling unmanaged code from managed code.
I wouldn't say it's "not a problem" because there are very few environments where you don't pay some cost for mixing and matching between managed/unmanaged code, and the environments designed around it are built from first principles to support it, like .NET. More interesting to me are Graal and WASM (once GC support lands) which should make it much easier to deal with.
Except that is only true since those attributes were introduced in recent .NET versions, and it doesn't account for COM marshaling issues.
Plenty of .NET code still using the old ways that isn't going to be rewritten, either for these attributes, or the new Cs/WinRT, or the new Core COM interop, which doesn't support all COM use cases anyway.
My remarks also apply to modern .NET, as those improvements were introduced in .NET 6 and .NET 8, and require a code rewrite to adopt them, instead of the old ways which are also available, in your blind advocacy you happened to miss out.
Very few code gets written from scratch unless we are talking about startups.
I was expecting this pedantic comment... If refcounting makes a language "managed", then C++ with shared_ptr is also "managed".
_______
The charitable interpretation is that OP was likely referring to the issues when calling into a language with a relocating GC (because you need to tell the GC not to move objects while you're working with them), which Swift is not.
Swift has just as much concerns for its structs and classes passing across FFI in terms of marshalling/unmarshalling and ensuring the ARC-unaware code performs either manual retain/release calls or adapts them to whatever other mechanism of memory management of the callee.
One of the comments here mentions that Swift has its own stable ABI, which exposes richer type system, so it does stand out in terms of interop (.NET 9 will add support for it natively (library evolution ABI) without having to go through C calls or C "glue" code on iOS and macOS, maybe the first non-Swift/ObjC platform to do so?).
Object pinning in .NET is only a part of equation and at this point far from the biggest concern (it just works, like it did 15 years ago, maybe it's a matter of fuss elsewhere?).
It is a library class, because C++ is a rich enough language to implement automatic refcounting as a library class, by hooking into the appropriate lifecycle methods (copy ctor, dtor).
I have to use Rust and Swift quite a bit. I basically just landed on sending a byte array of serialized protobufs back and forth with cookie cutter function calls. If this is your full time job I can see how you might think that is lame, but I really got tired of coming back to the code every few weeks and not remembering how to do anything.
If you want a particularity cursed example, I've recently called Go code from Rust via C in the middle, including passing a Rust closure with state into the Go code as callback into a Go stdlib function, including panic unwinding from inside the Rust closurehttps://github.com/Voultapher/sort-research-rs/commit/df6c91....
You have to go through C bindings, but FFI is very far from being Go's strongest suit (if we don't count Cgo), so if that's what interests you, it might be better to explore a different language.
I actually like that. I know they aren’t the “best” responses but as defaults, I would be more suspicious if it gave paid tools. I’m tested it and you can just ask for commercial tools if you want
It doesn’t have to be rebuilt every time. The incremental parts are missing when compared to the Go compiler, but when coding a GUI app with Go you’re not modifying the C packages behind the scenes so they won’t need recompiled.
This means one rather slow compile to start and then it’s back to super fast!
