(untitled)

Any recs for languages that can compile into compact standalone executable, have good RAM footprint (it may have GC, but at least it should pack everything in memory super tight and avoid introducing layers of extra pointers when you put structures in structures), have decent collections library (at least dynamic arrays, hash maps, hash sets), support something like typeclasses/traits (key feature is being able to implement any number of "interfaces" for types coming from outside of your code). Bonus points if does support some fancy pattern matching and lightweight syntax for defining structs / tagged unions usable with that pattern matching.

It sounds like you want Rust to be honest.

>>43138 Just wondering if there are any alternatives I missed. D and Zig are somewhat close but sadly no traits/typeclasses and most likely worse ecosystem/tooling on top of that.

>>43133 the odds of finding a programming language with a long and oddly specific shopping list of features, most of which aren't related by any particular design philosophy, is quite small. the odds of it also being widely adopted is basically zero

>>43141 > long and oddly specific It's only 4 bullet points, and only 2 of them are actually about language itself. It's not oddly specific at all. To rephrase in a slightly more general way, I want a language for small desktop apps that has expression problem solved in any decent way. https://en.wikipedia.org/wiki/Expression_problem

>>43133 Looks like you need Golang. I know that it has runtime footprint but it's just extra 2-3 MB for an executable that will work on any compatible device after compilation. Imagine struggles to compile C project that wants new glibc but your host system is outdated as well as some end-users' ones. Only cons I can see for you are: 1. Binaries can become large rather quick because of compilation approach: binary include whole package even if it uses only one function from it (there are workarounds tho) 2. Poor GUI libraries (my own opinion)

>>43145 And what exactly you see as an analog to traits/typeclasses in Golang?

> You can’t implement methods on types that you don’t own (this is common in Go). Basically this is the central point of what I'm looking for. Being able to implement newly defined interfaces for types coming from 3rd party libraries, also, being able to implement interfaces coming from library A for types coming from library B, etc.

>>43143 >To rephrase in a slightly more general way, I want a language for small desktop apps that has expression problem solved in any decent way. the most decent way to solve the "expression problem" is structural typing. doesn't Go have structural typing? Or use OCaml or something, but then i'm not sure about the RAM footprint

>>43150 Structural typing alone doesn't solve it. Lets say you have trait Printable { void print(); }, the ability of something to be printable doesn't depend on structure of the object in question, it depends only on whether Printable trait was implemented for that type.

>>43151 >the ability of something to be printable doesn't depend on structure of the object in question it does, if you consider the available methods to be part of the object's structure, which is a perfectly sensible thing to do. an object is not a POD struct

>>43152 so i was bored and looked into how structural typing is implemented in Go. it can't do that. it's just duck typing for interfaces. i guess you're just gonna have to use Nim and implement this feature yourself

>>43152 > it does, if you consider the available methods to be part of the object's structure, which is a perfectly sensible thing to do. an object is not a POD struct Hey, but structural typing alone doesn't say anything about being able to declare new methods for old classes. That needs a special mechanism to be present in language. >>43153 > Nim Thanks, this is an interesting one and I totally forgot it exists. I see there some kinds of multimethods, mixin/bind construct, and a lot more, in general it seems like a massive metaprogramming kitchen sink and it supports compiling to C++ and interfacing with C++ libraries, which kinda solves the problem of impossibility of having any kind of consistent package ecosystem for such language. https://nim-lang.org/docs/manual.html#implementation-specific-pragmas-importcpp-pragma

>>43154 >structural typing alone doesn't say anything about being able to declare new methods for old classes. That needs a special mechanism to be present in language. if you map out an object's fields and their types in a given context, you have the object's structure for that context. i'm not talking to you about classes or any specific means of associating named fields with object handles. the association could be based on vtables, prototype chains, looking up a function pointer on a struct, UFCS combined with ad hoc polymorphism... it doesn't matter. if you can sensibly hide something behind a "foo.bar" syntax, it fits the bill. nothing stops 'bar' from being a function that you invoke with "foo.bar(...)". so what i'm talking about is (probably) what you're thinking of as structural typing, but with field access abstracted under this scheme, an object is defined by whatever you can do with it. an "interface" simply defines expectations about the object's fields. when you cast an object as an interface type, you get a fat pointer referencing an ad hoc vtable. the vtable points to whatever looking up the expected fields on the object's type resolves to (after de-sugaring). looking up fields on the interface type just resolves to that Nim doesn't do this out of the box, but once upon a time i used it to implement something similar. extending the language like that is probably going too far, but the point is that it's easily doable. i was surprised that a language that boasts structural typing using interfaces (i.e. Go) doesn't actually do it

>>43155 > structural typing, but with field access abstracted I'm yet to see a language that takes it this far. My impression of structural typing is more of a lower level concept concerned mostly about being able to use shared code that deals with intersecting subsets of actual physical fields (which sometimes happen to be methods, with a single extra step either to vtable or prototype). It is like this with row polymorphism in ML languages, it is also like this in TypeScript, most likely it's also similar in Go. But under your definition typeclasses in Haskell and traits in Rust are also structural typing. I don't have any strong feelings about how to call certain things though.

>>43172 >I'm yet to see a language that takes it this far. very few of them do structural typing at all. but yeah... i just spent some time trying to find one that does what i have in mind and i can't. too bad. you could bolt it on top of any procedural language with function overloading and UFCS to get extremely flexible polymorphism with no extensibility problem nonsense and no philosophical baggage >intersecting subsets of actual physical fields i've never seen a definition of structural typing that talks about "physical fields". who cares if the fields are "physical" or not? they look like fields and the user treats them like fields. polymorphism adds a level of abstraction over what's "physical" in any case. maybe you mean "explicitly defined as fields", but if you look at the conventional examples, it's more like "explicitly associated with the type" but doesn't defining a function that accepts an argument of some type, associate it with that type? so really, those examples reflect the unstated assumption that it all needs to be bundled together, in one place, by a single syntactic construct. and that's exactly what creates the Expression Problem. it's an undesirable limitation and i don't see how it's inherent to structural typing. structural typing is a pragmatic alternative to nominal typing >under your definition typeclasses in Haskell and traits in Rust are also structural typing some crippled version thereof, i guess