141–150 of 274 posts
Interesting, for me the "between Rust and Go" would be a nice fit for Swift or Zig. I've always quite liked the language design of Swift, it's bad that it didn't really take off that much
Earlier quoted context omitted.
Yes it does. Unless I can attach a trait to a struct without having to define all the methods of that trait for that struct. This is my issue with interfaces and go. I can totally separate out objects as interfaces but then I have to implement each implementation’s interface methods and it’s a serious chore when they’re always the same. For example: Playable could be a trait that plays a sound when you interact with…
You can provide default method implementations for traits. Any type with that trait gets the default behavior, unless you override it.
I have mostly been writing Rust in the last 10 years, but recently (1 year) I have been writing Go as well as Rust. The typical Go story is to use a bunch of auto generation, so a small change quickly blows up as all of the auto generate code is checked into git. Like easily a 20x blowup. Rust on the other hand probably does much more such code generation (build.rs for stuff like bindgen, macros for stuff like serde,…
I have mostly been writing Rust in the last 10 years, but recently (1 year) I have been writing Go as well as Rust. The typical Go story is to use a bunch of auto generation, so a small change quickly blows up as all of the auto generate code is checked into git. Like easily a 20x blowup. Rust on the other hand probably does much more such code generation (build.rs for stuff like bindgen, macros for stuff like serde,…
> The typical Go story is to use a bunch of auto generation, so a small change quickly blows up as all of the auto generate code is checked into git. Like easily a 20x blowup. Why do you think the typical Go story is to use a bunch of auto generation? This does not match my experience with the language at all. Most Go projects I've worked on, or looked at, have used little or no code generation. I'm sure there are pr…
The only thing I can think of that Go uses a lot of generation for that other languages have other solutions for is mocks. But in many languages the solution is "write the mocks by hand", so that's hardly fair.
Earlier quoted context omitted.
Remove all of that noise. Take this: fn fib(n: i32) -> i32 {} The (n: i32) can be just (n i32), because there is no benefit to adding the colon there. The -> i32 can also be just i32 because, again, the -> serves no purpose in function/method definition syntax. So you end up with simple and clean fn fib(n i32) i32 {} And semicolons are an ancient relic that has been passed on to new languages for 80 fucking years wit…
In a Hindley-Milner (or deriative) type system, types doesn't have to be explicit, making the number of arguments ambiguous here: fn fib(n i32) i32 {} But even if they need to be written explicitly, type applications like `List a` would require syntax to disambiguate them. Personally, I would like a language that pushes the programmer to write the types as part of a doc comment. Also think about returning lambda's. S…
It should be
fn foo(n i32, m i32) (i32, i32) {}
fn foo(n i32) (a i32, b i32) {}
for (;;;) {}
if foo := a + b; foo > c {}Any tentative ideas yet as to how you will manage the memory management? Sounds like a sort of magic 3rd way might be in the making/baking!
Earlier quoted context omitted.
I am playing around with this! I'm mostly interested in something in the space of linear types + mutable value semantics.
Could you please explain what this implies in layman's terms? I've read the definition of 'linear type' as a type that must be used exactly once, and by 'mutable value semantics', I assume, that unlike Rust, multiple mutable borrows are allowed? What's the practical implication of this - how does a Rue program differ from a Rust program? Does your method accept more valid programs than the borrow checker does?
Mutable value semantics means no references at all, from a certain perspective.
You can sort of think of linear types as RAII where you must explicitly drop. Sorta.
“More programs” isn’t really the right way to think about it. Different semantics, so different programs :)
Earlier quoted context omitted.
Primary motivation is to have a fun project. If nobody ever uses this, I'll still be happy. I'd like fast compile times, and giving up some of Rust's lowest level and highest performance goals in exchange for it. As well as maybe ease of use.
Nice, seems like a super cool project. I've thought a Rust like language but at Go's performance level would be interesting. Garbage collected, but compiled to a binary (no VM), but with Rust's mix of procedural and functional programming. Maybe some more capable type inference. If you don't mind me asking, how did you get started with programming language design? I've been reading Crafting Interpreters, but there is…
Crafting interpreters is fantastic!
Mostly just… using a lot of them. Trying as many as I could. Learning what perspectives they bring. Learning the names for their features, and how they fit together or come into tension.
The theory is great too, but starting off with just getting a wide overview of the practice is a great way to get situated and decide which rabbit holes you want to go down first.
Earlier quoted context omitted.
> Check out V-lang ... it has the details. Does it? From its docs [0]: > There are 4 ways to manage memory in V. > The default is a minimal and a well performing tracing GC. > The second way is autofree, it can be enabled with -autofree. It takes care of most objects (~90-100%): the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via GC. The devel…
"none of those stand out as "memory safety without GC" to me" ... can you explain why you believe they are not memory safe without GC? Im more interested to know the points in relation to autofree. Regarding the details, here is a pretty informative github discussion thread on same topic: https://github.com/vlang/v/discussions/17419 It is also accompanied with a demo video (pretty convincing in case you would like to…
Reading "Memory safe; No garbage collector, no manual memory management" on Rue homepage made me think of V for this very reason. Many think is trivial to do it and Rust has been in wrong for 15 years with its "overcomplicated" borrow checking. It isn't.