[dead]
Rue: Higher level than Rust, lower level than Go
171–180 of 274 posts
Re: Rue: Higher level than Rust, lower level than Go
#172Earlier quoted context omitted.
But that trait can’t have fields
You can use a struct that the other structs have as a field. The trait can then operate on that struct. I'm not trying to convince you to use Rust. If you prefer C++ have at it. I was just trying to point out that most patterns in C++ have a fairly close analogy in Rust, just with different tradeoffs.
Yeah go has embedded structs. It’s ugly and allows one to address the fields on the parent and it exposes the struct (with the same fields) so it’s kind of a head scratcher.
To be honest, it’s been 3 years since I looked at rust and I might try again. I still prefer inheritance because some things just are-a thing. I also love ECS and components and see traits as that. I just wish I could store local state in those.
Re: Rue: Higher level than Rust, lower level than Go
#173Earlier quoted context omitted.
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…
Thanks :) 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.
> Mostly just… using a lot of them
Well I got that part covered at least. Seems like I'm constantly getting bored and playing around with a different language, probably more than I should lol
Re: Rue: Higher level than Rust, lower level than Go
#174I 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…
Anything and everything related to Kubernetes in Go uses code generation. It is overwhelmingly "typical" to the point of extreme eye-rolling when you need to issue "make generate" three dozen times a day for any medium sized PR that deals with k8s types.
Re: Rue: Higher level than Rust, lower level than Go
#175Earlier quoted context omitted.
Yep. This was the biggest thing that turned me off Go. I ported the same little program (some text based operational transform code) to a bunch of languages - JS (+ typescript), C, rust, Go, python, etc. Then compared the experience. How were they to use? How long did the programs end up being? How fast did they run? I did C and typescript first. At the time, my C implementation ran about 20x faster than typescript.…
Rust gets harder with codebase size, because of borrow checker. Not to mention most of the communication libraries decided to be async only, which adds another layer of complexity.
I think it depends on the patterns in place and the actual complexity of the problems in practice. Most of my personal experience in Rust has been a few web services (really love Axum) and it hasn't been significantly worse than C# or JS/TS in my experience. That said, I'll often escape hatch with clone over dealing with (a)rc, just to keep my sanity. I can't say I'm the most eloquent with Rust as I don't have the 3 decades of experience I have with JS or nearly as much with C#.
I will say, that for most of the Rust code that I've read, the vast majority of it has been easy enough to read and understand... more than most other languages/platforms. I've seen some truly horrendous C# and Java projects that don't come close to the simplicity of similar tasks in Rust.
Re: Rue: Higher level than Rust, lower level than Go
#176Earlier quoted context omitted.
Rust gets harder with codebase size, because of borrow checker. Not to mention most of the communication libraries decided to be async only, which adds another layer of complexity.
Disagree, having dealt with +40k LoC rust projects, bottow checker is not an issue. Async is an irritation but not the end of the world ... You can write non asynchronous code I have done it ... Honestly I am coming around on async after years of not liking it... I wish we didn't have function colouring but yeah ... Here we are....
Funny, I explicitly waited to see async baked in before I even started experimenting with Rust. It's kind of critical to most things I work on. Beyond that, I've found that the async models in rust (along with tokio/axum, etc) have been pretty nice and clean in practice. Though most of my experience is with C# and JS/TS environments, the latter of which had about a decade of growing pains.
Re: Rue: Higher level than Rust, lower level than Go
#177Earlier quoted context omitted.
Yep. This was the biggest thing that turned me off Go. I ported the same little program (some text based operational transform code) to a bunch of languages - JS (+ typescript), C, rust, Go, python, etc. Then compared the experience. How were they to use? How long did the programs end up being? How fast did they run? I did C and typescript first. At the time, my C implementation ran about 20x faster than typescript.…
> it was annoying to program (due to a lack of enums) Typescript also lacks enums. Why wasn't it considered annoying? I mean, technically it does have an enum keyword that offers what most would consider to be enums, but that keyword behaves exactly the same as what Go offers, which you don't consider to be enums.
They presumably mean tagged unions like `User = Guest | LoggedIn(id, username)`.
Re: Rue: Higher level than Rust, lower level than Go
#178when we are we getting a language that looks like python and runs 50 times faster than c++ /s
Re: Rue: Higher level than Rust, lower level than Go
#179Earlier quoted context omitted.
Do you have plans for handling C FFI without "unsafe"? Will it require some sort of extension module written in C/C++/Rust?
No direct plans. For the immediate future, only the runtime is allowed to call into C. If this ever becomes a production thing, then I can worry about FFI, and I'll probably just follow what managed languages do here.
FWIW, I really like the way C# has approached this need... most usage is exposed via attribute declaration/declaration DllImport for P/Invoke. Contrasted with say JNI in Java or even the Go syntax. The only thing that might be a significant improvement would be an array/vector of lookup names for the library on the system given how specific versions are often tagged in Linux vs Windows.
Re: Rue: Higher level than Rust, lower level than Go
#180Earlier quoted context omitted.
What would be better?
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…
What’s with all the periods, one at the end of each paragraph? Fully wasted.