01:57 <mgxm> andrewrk: the build manifest should be something like that? https://clbin.com/j5Don

09:44 <hio> Generics are ununderstandable to me, both in java, in c# and in every other language I've ever used that uses generics

09:45 <hio> I like to compare it to an entire new hidden dimension like threading. I have to think one layer deeper everytime I have to parse some code that uses generics as if the code is multithreaded

09:45 <hio> If you think about it, that's exactly what generics are: multiple threads of code that can all happen at the same time where that T shows up

10:23 <knebulae> hio: that's not the right way to look at generics. It's no wonder you are confused.

10:24 <knebulae> hio: if you're on here, I'd be more than happy to show you a couple of examples that would make generics simpler for you.

10:26 <hio> I'm not convinced that it's possible

10:26 <knebulae> Well, generics can *get* complicated, but you're making it harder than it needs to be. :)

10:27 <knebulae> hio: well, O

10:27 <hio> T could be anything, how is that helpful ?

10:27 <knebulae> hio: well, I'd say, this is the first misconception: "multiple threads of code that can all happen at the same time where that T shows up"

10:28 <knebulae> hio: T is not magic :)

10:29 <knebulae> hio: let's say you have a very simple function. It adds to variables (language is not important): return X+Y;

10:29 <hio> it could literally be anything, how am I supposed to understand a piece of code if I dont know what can arrive at T

10:29 <knebulae> hio: follow with me for a moment

10:30 <knebulae> hio: do you understand the concept of a function that adds two numbers and returns the result (in any programming language that supports functions).

10:30 <hio> lol man I know how to program and I know how generics work, I'm just saying that I dont like them

10:31 <knebulae> hio: well, as with all programming, I'd say the devil is in the details. If you really understood, there would be no confusion ;)

10:31 <hio> maybe if you really understood, there would be agreement

10:32 <hio> Golang doesnt have generics and everybody loves how simple it is

10:32 <hio> that's a fact

10:32 <knebulae> hio: fact?

10:32 <knebulae> hio: I hate go.

10:33 <knebulae> hio: It's horrible. Typing and typing and typing, and don't get me started on error handling.

10:34 <knebulae> hio: people like go because of co-routines and all the built in network goodies. Not because it's a good language. Plus it has Google's $$ behind it.

10:34 <hio> error handling is stupid in Go, that's true.

10:34 <hio> i can admit problems, can you?

10:35 <knebulae> hio: ?

10:35 <hio> generics are too hard to parse when reading code, that's simply something you have to admit

10:37 <knebulae> hio: I disagree. In fact, I think generics make things clearer. For example, in C#, I know that a Dictionary<String, UInt64> is clearly a dictionary with strings for keys and unsigned int64s as values.

10:38 <hio> ok but it is never enough anyway. What kind of strings? what do the ints mean?

10:38 <hio> that's my point about generics, you might as well remove them because it's never good enough

10:38 <knebulae> hio: And the dictionary itself was written once. With generic types. Instead of several times over with pointer tricks or casting or multiple function entrypoints.

10:39 <knebulae> hio: and now you know why I offered to clarify for you. :)

10:39 <hio> ?

10:41 <knebulae> hio: In go, if I want a function to add two numbers, I would have to create several functions. Functions like AddInt8, AddInt32, AddUInt64...

10:42 <hio> lets be honest, you effectively have to do that anyway in your generic function

10:42 <knebulae> hio: with generics, I can create one function (in pseudocode), Add<T>(T: x, T: y). So now, in code, I can call Add<UInt32>(10, 20) and get 30. The Type name in the angled brackets gets substituted into the function for T. But remember, Zig at least is not a dynamic language.

10:44 <knebulae> hio: therefore, at COMPILE TIME, what happens is the compiler will see every place you used Add<T> in your code, and for every type T (say you used int8, int32, int64 in code), the compiler will actually generate a function in code as though you had actually had an Add(int8, int8) function and an Add(int64, int64) function.

10:45 <knebulae> hio: at the end of the day, generics are an evolution of templates, which are (at the end of the day), just an evolution of macros.

10:45 <knebulae> hio: that's right... it's all actually syntactic sugar!

10:46 <hio> right and the price for that sugar is that I have to read an extremely cryptic generic function and attempt to understand it based on an abstract type T instead of real types

10:46 <knebulae> hio: well, generics do have their problems

10:47 <knebulae> hio: one I hate is that checking for the type at runtime in generic functions is generally frowned upon

10:47 <knebulae> hio: but sometimes it's absolutely critical to write compact and succinct code.

10:47 <hio> it's frowned upon because it shines a light on the leaky idea of generics where you effectively still have to check types and write type specific code, it's just hidden behind if else statements inside the generic function

10:49 <knebulae> hio: my favorite test of a new language and how well generics work is to write a 4 type ORM (string, int, double, date) and see how easy it is.

10:52 <knebulae> hio: well you clearly know what you're talking about; but it's comments like this that worry me: "ok but it is never enough anyway. What kind of strings? what do the ints mean?"

10:55 <hio> then you should have asked, what I meant was that a string is still not enough type information. What type of strings are allowed in that dictionary? What do they mean, are they keys to a database, passwords, hashes? Which ones should be allowed?

10:56 <IntoxicatedHippo> hio: If I have a variable which is a string how do I know what that variable is for?

11:02 <knebulae> hio: well, that depends on the function, just an with a non-generic function.

11:04 <knebulae> hio: I agree with your leaky abstraction comment about generics, but I would rather read 1 generic function with a switch statement on type than 3, 5, or 100 individual functions.

11:08 <hio> it wouldnt create 100 individual functions, you could still write a generic function that receives a void* and then you just have to cast and then do the logic. it's the same exact thing except without the cryptic T

11:08 <knebulae> hio: Also, generics are more useful in traditional OO languages. Think about methods that could work on many different types but must be re-written over and over again with slight variations because the types do not share the same base class. This is less of a problem in languages like Zig and Rust that use function composition (and Javascript that uses object prototyping)

11:09 <knebulae> hio: void eliminates the type safety guarantees the compiler provides. we could also just write in asm which has no concept of types.

11:10 <hio> Im not actually that good with go but it seems they had the right idea, you can cast any object to an interface and if it happens to implement that interface implicitly then you can work with it kinda generically without knowing its exact real type

11:11 <knebulae> hio: so you are telling me that it's easier to implement "interface", then track down and make sure it's implemented on that type than to look at a generic function and mentally sub the T for whatever type you're using? I mean it's literally the same thing as mentally substituting a type for void instead of T.

11:12 <hio> there is a point of diminishing and even negative returns when the type system is more complex and more annoying than the value it provides

11:12 <hio> we can see that with Rust

11:12 <knebulae> hio: agreed.

11:12 <knebulae> hio: but I will disagree on go.

11:12 <knebulae> C# got generics right, and they are a pleasure to use.

11:13 <hio> i disagree, c# is horrible to use

11:13 <knebulae> hio: to each their own

11:14 <hio> you cant even pass a SubClass object to a function that wants a BaseClass and then call .SharedFunction() on it and it will call the BaseClass.SharedFunction() instead of the SubClass.SharedFunction()

11:14 <hio> how stupid is that? think about that

11:14 <knebulae> hio: ?

11:15 <knebulae> hio: you would want alternative behavior? I'm confused.

11:15 <hio> void function(BaseClass bla) { bla.sharedfunction(); }

11:15 <knebulae> hio: I get it

11:15 <hio> now im calling that with a subclass that has implemented sharedfunction

11:15 <hio> yet it's still calling the baseclass' function even though the compiler obviously knows what im passing to it

11:16 <hio> for such a simple thing I need to use reflection. It just shows me: To hell with complex type systems

11:16 <hio> c# isnt even that complex and it's already leaky as hell

11:17 <knebulae> hio: in your subclass example, were you using the override keyword?

11:18 <knebulae> Because method shadowing in C# requires one of 3 conditions: the method itself must be virtual or abstract, or the derived method must be declared override

11:19 <knebulae> hio: C# isn't as leaky as you think.

11:28 <hio> ok sorry knebulae, I was speaking from memory. I found the sample I created that shows the problem: https://dotnetfiddle.net/NGKqNJ

11:28 <hio> it should be printing the specific class' function implementation

11:28 <hio> instead it's always the base

11:31 <knebulae> hio: no it shouldn't

11:31 <knebulae> hio: that's not what this code says

11:31 <hio> yeah I know because c# is arbitrarily implementing their own personal decision on how types should work

11:32 <hio> it might just as well work this way

11:32 <knebulae> hio: lol

11:32 <knebulae> hio: man, I know you know that's not how software works :)

11:32 <knebulae> hio: it's not like Anders doesn't know how to design a programming language ;)

11:35 <hio> wait I think that wasnt the correct sample

11:35 <knebulae> hio: First, you call ActorCompiler().CompileStatement(stmt). But you don't do *anything* with stmt. How do you expect a method to be called on an object you don't use?

11:35 <hio> i might have mixed some samples up

11:36 <knebulae> hio: ok

11:37 <hio> i dont remember what it was, see that's my point dude. Type systems are too complex

11:40 <hio> oh right, i remember. It was around the problem that inside the ActorCompiler.CompileStatement i couldnt call the right one from the stmt object. I would have to make a huge list of if (stmt is SubClass) blabla

11:41 <knebulae> hio: the reason C#'s type system is complex, as you say it, is because it is robust. Give me a few minutes, I'll show you.

11:58 <knebulae> hio: https://dotnetfiddle.net/NGKqNJ

11:59 <hio> you have to click "share" and get ur own link

11:59 <hio> this just shows me my own code again

11:59 <hio> or fork might work too

12:02 <knebulae> hio: ok, let me check

12:06 <unique_id> Generics is just replacing T with the type you supplied. It's exactly like copy pasting a class and changing one thing about it. It couldn't be made any simpler.

12:06 <unique_id> It just saves you work

12:11 <knebulae> https://dotnetfiddle.net/tTj51s

12:11 <knebulae> hio: see if that one works.

12:12 <knebulae> hio: you will see that you have to be more explicit with C# with method overriding, but what you want to do is easily within the capabilities of the system.

12:13 <knebulae> hio: I assume you are running into problems writing something using the actor model? plugins?

12:18 <knebulae> hio: You will notice the problem you were encountering with the DerivedClass3 example.

12:19 <knebulae> hio: the solution, especially using the actor model, is to explicitly mark your parent classes' methods as abstract/virtual then override in the subclass.

12:21 <knebulae> hio: https://dotnetfiddle.net/t2pyBx

12:22 <knebulae> hio: I guess this site works differently than I thought.

12:47 <knebulae> so back to zig, lol, has anyone had issues calling c functions with varargs support?

12:55 <knebulae> hio: here was the very final result if you care: https://dotnetfiddle.net/KPIEdc

20:49 <errpr> Is there a way to write a library that calls functions defined by the library user?

20:50 <j`ey> using function pointers?

20:51 <errpr> how do I get the pointer?

21:16 <errpr> okay I can write my library inside a struct and have the caller initialize the library struct with pointers to the functions, feels a tad clunky though

21:37 <knebulae> errpr: yes. that is how function callbacks work.

21:39 <hooo> zig has no concept of interfaces?

21:40 <hooo> im trying to think of why this would be necessary or how function calls are maybe good enough

21:43 <hooo> although I dont see why it shouldnt be good enough, yes it's clunky but whatever

22:11 <knebulae> hooo: functions are first class citizens in Zig. You can pass them just like you would values. They are function pointers without the messiness.

22:15 <hooo> he asked how a zig library could consume a struct with certain functions supplied by the user. So that implies that the library has a certain signature for functions it wants to expect and only the implementation for those functions is swapped

22:16 <hooo> the question is how this intent can be done cleanly and nicely

22:26 <knebulae> hooo: right. The zig manual indicates that a function "type" can be created like so: const call2_op = fn (a: i8, b: i8) i8;

22:27 <knebulae> hooo: Which could then be used in a function declared as such: fn do_op(fn_call: call2_op, op1: i8, op2: i8) i8

22:28 <knebulae> hooo: So if the proper signatures exist, the compiler will enforce a "clean" interface with the user supplied functions.

22:29 <knebulae> hooo: if not all necessary pointers are provided, then the library can error out.

22:40 <hooo> anyone know what is going on here, it's trying to find some gcc lib even though I'm trying to just use a hopefully self contained musl std library for zig: https://paste.centos.org/view/07cba598

22:50 <hooo> ok i figured it out

22:50 <hooo> --library-path /usr/local/lib64 where my gcc libraries are