221–230 of 274 posts
Earlier quoted context omitted.
Something in the area of linear types and mutable value semantics.
Anything out there for reference or would you be implementing from theory/ideas here? God speed to you in terms of the project overall, it's exciting to see the beginnings of a rust-like-lang without the headaches!
Thanks!
Earlier quoted context omitted.
C has numeric enums and tagged unions, which are sum types without any compile time safety. That’s idiomatic C. Go doesn’t have any equivalent. How do you do stuff like this in Go, at all? I’ve been programming for 30+ years. Long enough to know direct translations between languages are rarely beautiful. But I’m not an expert in Go. Maybe there’s some tricks I’m missing? Here’s the problem, if you want to have a stab…
> C has numeric enums and tagged unions C has unions, but they're not tagged. You can roll your own tagged unions, of course, but that's moving beyond it being a feature of the language. > How would you model this in Go? I'm committing the same earlier sin by trying to model it from the solution instead of the problem, so the actual best approach might be totally different, but at least in staying somewhat true to yo…
This feels like a distinction without a real difference. Hand-rolled tagged unions are how lots of problems are approached in real, professional C. And I think they're the right tool here.
> the actual best approach might be totally different, but at least in staying somewhat true to your code: (...)
Thanks for having a stab at it. This is more or less what I ended up with in Go. As I said, I ended up needing about 50% more lines to accomplish the same thing in Go using this approach compared to the equivalent Typescript, rust and swift.
If anyone is curious, here's my C implementation: https://github.com/ottypes/libot
Swift: https://github.com/josephg/libot-swift
Rust: https://github.com/josephg/textot.rs
Typescript: https://github.com/ottypes/text-unicode
I wish I'd kept my Go implementation. I never uploaded it to github because I was unhappy with it, and I accidentally lost it somewhere along the way.
> the actual best approach might be totally different
Maybe. But honestly I doubt it. I think I accidentally chose a problem which happens to be an ideal use case for sum types. You'd probably need a different problem to show Go or C# in their best light.
But ... sum types are really amazing. Once you start using them, everything feels like a sum type. Programming without them feels like programming with one of your hands tied behind your back.
Earlier quoted context omitted.
Supporting recursion only to a depth of 1000 (or whatever) is equivalent to supporting loops of up to 1000 iterations. If I put out a language that crashed after 1000 iterations of a loop, I'd welcome the rudeness.
Plenty of languages, including very serious ones like C and Rust, have bounded recursion depth.
I couldn't figure out the main points, besides the "between Rust & Go" slogan. I've worked both with Rust and Go, and I like Rust more, but there are several pain points: * macro abuse. E.g. bitshift storing like in C needs a bunch of #[...] derive_macros. Clap also uses them too much, because a CLI parameter is more complex than a struct field. IDK what's a sane approach to fixing this, maybe like in Jai, or Zig? No…
I couldn't figure out the main points, besides the "between Rust & Go" slogan. I've worked both with Rust and Go, and I like Rust more, but there are several pain points: * macro abuse. E.g. bitshift storing like in C needs a bunch of #[...] derive_macros. Clap also uses them too much, because a CLI parameter is more complex than a struct field. IDK what's a sane approach to fixing this, maybe like in Jai, or Zig? No…
I've been having fun with Gleam. I'm not really sure where it falls on the spectrum though. It is garbage collected, so it's less abrasive than Rust in that sense. But it's pure functional which is maybe another kind of unfriendly.
"Memory Safe No garbage collector, no manual memory management. A work in progress, though." I wish them the best, but until they have a better story here I'm not particularly interested. Much of the complexity in Rust vs simplicity in Go really does come down to this part of the design space. Rust has only succeeded in making a Memory Safe Language without garbage collection via significant complexity (that was a tr…
If you look at the Github, there's a design proposal (under docs/design) for that. It looks like the idea at the present time is to have four modes: value types, affine types, linear types, and rc types. Instead, of borrowing, you have an inout parameter passing convention, like Swift. Struct fields cannot be inout, so you can't store borrowed references on the heap. I'm very interested in seeing how this works in pr…
I don’t struggle with lifetimes either, but I do think there’s a lot of folks who just never want to think about it ever.
Looks nice, but -> syntax always feels extremely off-putting. What does it get me?
Earlier quoted context omitted.
I am very interested in Hylo! I think they're playing in similar spaces. I'd like to explore mutable value semantics for Rue. One huge difference is that Hylo is using LLVM, whereas I'm implementing my own backends. Another is that Hylo seems to know what they want to do with concurrency, whereas I really do not at all right now. I think Hylo takes a lot of inspiration from Swift, whereas I take more inspiration from…
How are Swift and Rust very similar? I can search, but want to hear your opinion. And congrats on starting a language project, even if Just for Fun (Linux). ;) https://frappe.io/blog/book-reviews/just-for-fun-a-book-on-l...
Both are playing around in similar spaces, both shared team members for a while, both have a take an automatic memory management that isn’t a garbage collector, both were sponsored by a primary company for a while (Swift still is, I think). There’s a lot of differences too.
This is a bit silly but when i look at new languages coming up I always look at the syntax, which is usually horrible(Zig and Rust are good examples), and how much garbage there is. As someone that writes in Go, I can't stand semicolons and other crap that just pollutes the code and wastes time and space to write for absolutely no good reason whatsoever. And as this compares itself with Go, I just cannot but laugh wh…
Weird, that's exactly how I feel reading Go: func (lst *List[T]) Push(v T) { if lst.tail == nil { lst.head = &element[T]{val: v} lst.tail = lst.head } else { lst.tail.next = &element[T]{val: v} lst.tail = lst.tail.next } } And this one doesn't even have the infamous error-checking.
Now imagine if it had semicolons, ->, ! and '.
Earlier quoted context omitted.
As a long time C++ user, I’m curious why you like inheritance and virtual methods so much. I maintain a medium sized, old-ish C++ code base. It uses classes and inheritance and virtual methods and even some multiple inheritance. I despise this stuff. Single Inheritance is great until you discover that you have a thing that doesn’t slot nicely into the hierarchy or when you realize that you want to decompose an interf…
Protected and private inheritance are C++'s equivalent to traits, and they don't suffer from the usual issues of multiple inheritance. As for type classes, check out concepts. By no means am I trying to sell C++, I don't touch it myself, but it doesn't leave you completely adrift in those seas.
How so? Maybe in a COM-like world where the user of an object needs to call a method to get an interface pointer.
I’ll grant that concepts are a massive improvement.