141–150 of 168 posts
Earlier quoted context omitted.
You can enable null safety in TypeScript, seems like a pretty good fix to me.
Its mediocre at best. Like in maths, how would i feel if addition would sometime actully be division. Thats hiw bad it is.
Earlier quoted context omitted.
Does Go actually have an async story? I know that question risks starting a semantic debate, so let me be more specific. Go allows creating lightweight threads to the point where it's a good pattern to just spin off goroutines left and right to your heart's content. That's more of a concurrency primitive than async. Sure, you combine it with a channel, and you've created an async future. The explicit passing of conte…
Go's async story is great, as there is no function coloring at all. That being said, I don't like Go's syntax very much. The runtime is great though.
Earlier quoted context omitted.
Ditto. C# gets a bad rap due to its Windows-exclusive history, but it's now cross platform and has most of the features PL nerds are looking for. Strict nulls, pattern matching, a really mature and easy to use async ecosystem (it invented async/await), even a lot of the low level stuff is there (unsafe{} blocks ala rust and manual memory management where needed).
C# is nice, but it is nowhere near Rust in terms of safety or expressiveness. Thankfully they are finally adding discriminated unions (sum types) and other sorely missing features. Unsafe in C# is much more dangerous than unsafe in Rust, precisely because it doesn’t actually color a function. It just allows its body to use pointers. This is why you have methods in the CLR called “DangerousFoo()”, and the compiler doe…
This one is more subjective, but I also think C# has a more mature and painless web stack.
I love both languages but for me they each fill a different role.
Go with more expressive types and a bit stricter compiler to prevent footguns would be a killer backend language. Similar to what TypeScript was to JavaScript.
My 2 cents would be to make it work well with TypeScript frontends. I think TypeScript is so popular in backends because 1. you can share types between frontend code and backend code and 2. it's easy for frontend devs to make changes to backend code.
Earlier quoted context omitted.
No doubt a chatbot would be built faster if using a less strict language. It wasn't until I started working on larger Python codebases (written by good programmers) that I went "oh no, now I see how this is not an appropriate language". Similar to how even smaller problems are better suited for just writing a bash script. When you can have the whole program basically in your head, you don't need the guardrails that p…
I've also found that traversing a third-party codebase in Python is extremely frustrating and requires lots of manual work (with PyCharm) whereas with Rust, it's just 'Go to definition/implementation' every time from the IDE (RustRover). The strong typing is a huge plus when trying to understand code you didn't write (and I'm not talking LLM-generated).
Looks great. But I can't help wondering: If it is similar to Rust why not make it the the same as Rust where it feature-matches? Why import "foo.bar" instead of use foo::bar? Why Bar.Baz => instead of Bar::Baz =>? What are you achieving here? Why make it subtlety different so someone who knows Rust has to learn yet another language? And someone who doesn't know Rust learns a language that is different enough that the…
I switch between languages a lot and I'm currently learning PHP. I've found that syntax similarities can be a hazard. I see "function" and I think I'm writing JavaScript, but then I try to concatenate strings with "+" and I realize I'm actually writing PHP and need to use ".". These challenges are especially noticeable in the early days of learning.
Go syntax and the Go runtime would be the perfect combo for me. Oh well... I love Rust for what it is, but for most of my projects, I can’t justify the added complexity. Sure, there are a bunch of things I miss from the Rust world when I’m working on large-scale distsys services in Go, but introducing Rust in that space would be a recipe for disaster. I guess the Go team knows that if they start adding everyone’s fav…
Earlier quoted context omitted.
MoonBit [0] is the best/future complete/active “rust with gc”. [0] https://www.moonbitlang.com
Did MoonBit add support for some kind of shared memory concurrency like threads? I remember discovering the language, being very excited about it, and then learning it is single-threaded, which makes it a poor replacement for Rust IMHO.
They support native target (as well as js target) but wasm one was always the primary one.
Having said that they have (cooperative) async for native target only currently.
Personally I'm looking forward for them to self host it – not sure why they're still holding to ocaml compiler, the language seems sufficient to have moonbit written in moonbit. Together with it I'm waiting for proper open source – currently what the team is doing is a bit like what Meta sometimes does – internal development, no community development, they just dump updates as snapshots from time to time instead of normal, fully open development.
I'm also clinging on my last intel purchase (macbook pro) and unfortunatelly they don't provide intel builds for macOS just arm ones (even though they do for linux), which is a bit of a pain – but I think I'll just buy arm macbook before they'll support intel on macOS (and maybe they'll never do, which is fair). It's a small thing from moonbit perspective, but annoying and limiting a bit for me personally to work remotely only with it.
Something that I don't understand about Rust, or these rustylangs, is the insistence of separating structs and methods. Don't get me wrong, I like named-impl blocks, but why are they the only option? Why can't I put an unnamed-impl block inside the struct? Or better yet just define methods on the struct? What's the point of this and why do these rustylangs never seem to change this?
There are several reasons. 1. Struct fields are really important in Rust because of auto-traits. Your life as a Rust programmer is easier if all fields fit on the screen, because one of them may be the reason your struct is `!Sync` or whatever. 2. Impl blocks can have different generic bounds from the struct itself, which is a nice shorthand for repeating the same generic bounds for a series of related methods. So yo…
struct Example {
number: i32,
}
impl Example {
fn boo() {
println!("boo! Example::boo() was called!");
}
}
trait Thingy {
fn do_thingy(&self);
}
impl Thingy for Example {
fn do_thingy(&self) {
println!("doing a thing! also, number is {}!", self.number);
}
}
struct Example {
number: i32,
impl {
fn boo() {
println!("boo! Example::boo() was called!");
}
}
impl Thingy {
fn do_thingy(&self) {
println!("doing a thing! also, number is {}!", self.number);
}
}
}
trait Thingy {
fn do_thingy(&self);
}
Earlier quoted context omitted.
There are several reasons. 1. Struct fields are really important in Rust because of auto-traits. Your life as a Rust programmer is easier if all fields fit on the screen, because one of them may be the reason your struct is `!Sync` or whatever. 2. Impl blocks can have different generic bounds from the struct itself, which is a nice shorthand for repeating the same generic bounds for a series of related methods. So yo…
These don't seem like insurmountable challenges though. Unnamed impl blocks could work entirely within requirements. There could also be a lint to warn about any fields that are below trait definitions. struct Example { number: i32, } impl Example { fn boo() { println!("boo! Example::boo() was called!"); } } trait Thingy { fn do_thingy(&self); } impl Thingy for Example { fn do_thingy(&self) { println!("doing a thing!…