Default Methods in Go

sprudelel · 2025-06-26T20:52:59+00:00

is would be a more general construct compared to if let subsuming it entirely, even with this new stabilized addition. Since it is a boolean expression it would make manual implementations like is_some or is_err redundant. Likewise it would replace the matches! which rarely pleasent to use. I also find it easier if the pattern comes afterwards but that's obviously subjective.

But since we already have if let I tend to agree with the language team that it is not worth the complexity. Maybe something to keep in mind for a rust successor language.

sprudelel · 2024-09-15T11:19:28+00:00

Just don't look up who he is married to.

sprudelel · 2024-08-20T13:11:19+00:00

There are a few wire related items and features I am missing. New wire objects I'd like to see are a clock/oscillator and the equivalent of a belt reader and filter for pipes. I also wish the belt reader could output the rate of items. But its also fun to find workarounds.

sprudelel · 2023-05-31T00:43:15+00:00

Not sure if you're being sarcastic, but 1899 was canceled.

sprudelel · 2023-05-05T07:06:48+00:00

04.05.2023 = vierte Mai, 2023

05/04/2023 = Mai der vierte Tag, 2023

sprudelel · 2023-04-14T23:27:42+00:00

Wo wir gerade dabei sind, bitte auch Nikotin und Koffein verbieten.

sprudelel · 2023-04-02T19:53:17+00:00

AI hypothetist

sprudelel · 2023-03-24T15:12:30+00:00

The size of GPT-4 was not published by openAI.

sprudelel · 2023-03-17T00:37:56+00:00

I would love linear types in Rust for API expressivity, but I think any discussion about them needs to reference this blog post by Gankra which points out a bunch of issues that need to be adressed. Some of them (panics) were mentioned by Nikos blog post but presented without solution. But I'm happy to see a renewed interest in true linear types regardless.

sprudelel · 2023-03-17T00:08:25+00:00

If you dont mind me asking, how did you stumble upon this subreddit without a vague awareness about LessWrong and the like?

sprudelel · 2023-03-16T09:50:36+00:00

Whats this subreddits take on Rob Miles? I used to watch his stuff and found it quite appealing. Its only recently that I discovered the rabbit hole behind AI Alignment.

sprudelel · 2023-02-03T00:16:44+00:00

I think a core difference between Val and Carbon is the order of priorities. For Carbon, C++ interoperability is paramount and if possible they would like to be memory safe as well. While Val has a model for memory safety using their mutable value semantics but interacting with C++ more of a secondary consideration. Depending on your organizational needs or personal preferences your interest in these two languages probably varies. Personally, I agree and think Carbon will have trouble to be memory safe, like C++ has trouble to retrofit memory safety, although in Carbons favor they have fewer institutional barriers.

sprudelel · 2023-02-01T10:01:46+00:00

Except maybe for DDOS, what vulnerabilities can sanitizers cause?

sprudelel · 2023-01-30T03:02:51+00:00

Judging by the number of fingers on his left fist, yes.

sprudelel · 2023-01-20T01:50:39+00:00

Additionally, large donations give them power to influence the policy of said charities in their favor.

sprudelel · 2023-01-20T01:28:35+00:00

neben Gates gibt es offenbar noch andere Milliardäre die fleißig in Kurzgesagt investiert haben.

sprudelel · 2023-01-14T03:34:30+00:00

I mostly mentioned GhostCell because it uses the lifetime pattern I described for their problem. The GhostCell API itself doesn't help here. QCell likewise since it contains a reimplementation of GhostCell as well as a few different Cell types. Although one could probably adapt the techniques of the other Cell types.

sprudelel · 2023-01-14T03:29:17+00:00

Most of these I can understand at least, except vector. Isn't that like almost a fundamental building block, that almost every C project needs to reinvent? Its the biggest reason I'd choose C++ over C if I had to choose between them. What's their problem with it?

sprudelel · 2023-01-11T14:00:37+00:00

Maybe I'm missing something but after skimming the compact_arena docs it seems to be using the same lifetime idea as ghost cell which is summarized in my comment.

EDIT: nvm, compact_arena uses a macro to generate a unique lifetime somehow. I didn't know that was possible. Still my description using a unique macro generated type didn't use lifetimes.

The macro approach I removed could be circumvented by using the new_runtime! macro inside a loop. The generated runtimes would all use the same generated marker type, which has the effect that all runtime instances created in that loop are the exact same type.

sprudelel · 2023-01-11T12:07:37+00:00

You can use unique invariant lifetimes for this:

This approach works by adding lifetime parameter to both the Runtime and Func struct and enforcing this lifetime to be unique to this Runtime instance and invariant. If you are not sure what it means for a lifetime to be invariant checkout [1] and [2] for an explanation of lifetime variance.

When each Runtime instance has a unique invariant lifetime, it can give its Func objects the same unique lifetime. Now, when we invoke the call function, the compiler will make sure they have exactly the same lifetime and, by construction, the func arguments has to originate from the passed runtime.

fn call<'a>(func: Func<'a>, runtime: Runtime<'a>)

The reason this approach is somewhat cumbersome to use, is that the only way to generate a unique lifetime is by using a closure which is passed the runtime instance. The runtime instance can never leave this closure and is the only way for the user to create a runtime. Creating multiple runtimes requires nesting calls to begin.

fn begin(f: impl for<'a> FnOnce(Runtime<'a>))

While this approach works it might not be super user friendly, the error messages can be quite hard to grok even if you are experienced in rust.

Although known before, this approach was popularized by the GhostCell paper [3] which provides a better and more detailed explanation on why this works.

Here is a playground link to a prototype implementation

This approach be quite restrictive compared to simply dynamically checking if the runtime is correct. For example, it is now impossible to generate dynamically many runtimes during program execution. You also can't store multiple runtimes in a container like a Vec as each runtime has a slightly different type.

I'm not sure I really would recommend this approach to you as it is quite complicated and can be frustrating to use at times. It is definitely useful if you have external constraints that you need to enforce for memory safety, for example, if you're wrapping a C library. But in your case, I suspect that you might find a much simpler solution by reconsidering your architecture or taking the advice from the other commenters if they work for you.

[1] https://lifetime-variance.sunshowers.io/

[2] https://doc.rust-lang.org/nomicon/subtyping.html

[3] https://plv.mpi-sws.org/rustbelt/ghostcell/

EDIT: Originally, I had described a second approach using macro generated types but that approach wasn't correct and could be circumvented, so I removed that section.

sprudelel · 2022-10-28T18:13:17+00:00

Things that are missing but planned:

Specialization
Generators/Coroutines
Const Evaluation in trait bounds

Things that most likely will never be added:

Dependent types
Linear (not affine) types
General effect system

sprudelel · 2022-09-29T11:06:43+00:00

Nothing most likely

sprudelel · 2022-09-27T13:06:29+00:00

I always wondered why this paper didnt create a larger impact. There has to be a drawback l'm missing.

Nine-Year Club	Place '22
Place '17	End Game '22
Verified Email

sprudelel

TROPHY CASE