281–290 of 428 posts
I love the idea of a "thought experiment language" - actually creating a working language is a big overhead, and its really fun to think about what an ideal language might look like. The crazy thing with reading this and the comments, is that it seems like we all have been daydreaming about completely different versions of a "high level rust" and what that would look like. For me I'd just want a dynamic run time + si…
I've written a bit of Rust, and I was left with mixed feelings, that seem to be still the same here: - loved the memory safety patterns when compared to the horrible things that you can do with C++ - found almost every thing where it was different to have a harder to parse syntax, that I could never get used to. The implicit return at the end of a statement for instance make it harder for me to visually parse what's…
> all keywords should be obviously pronounceable I hear you. Internally, I always pronounced "var" as rhymes with "care", but then a colleague pronounced it "var" as rhymes with "car". I think the same guy pronounced "char" like char-broiled, whereas I had thought of it like "care". And he would say "jay-SON" for json, which I pronounced like Jason. How would you feel about a notation that is not meant to be pronounc…
Their Hello, Dada! example: print("...").await I'm coming from Python, and I can't help but ask: If my goal as a programmer is to simply print to the console, why should I care about the await? This already starts with a non zero complexity and some cognitive load, like the `public static void main` from Java.
The other problem I see here is that starting and awaiting the task are too coupled. In JavaScript calling the function would start the task, and awaiting the result would wait for it. This lets you do several things concurrently. How would you do this in Dada: const doThings = async () => { const [one, two, three] = await Promise.all([ doThingOne(), doThingTwo(), doThingThree(), ]); }; And if you wanted to return a…
Earlier quoted context omitted.
> The implicit return at the end of a statement for instance make it harder for me to visually parse what's being returned, since I really depend on that keyword. Cutting my teeth on Schemes and MLs and now working in Python, I have the complete opposite experience. It's jarring to have to specify return. What else would I want to do at the end of an expression? It seems tautological. The real reason it's there in Py…
I know it's not very FP, but you might explicitly not want to return anything and just modify the data.
Earlier quoted context omitted.
Rust's type system prevents bugs far beyond mere memory bugs. I would even go as far as claiming that the type system (together with the way the standard library and ecosystem use it) prevents at least as many logic bugs as memory bugs.
The type system was built to describe memory layouts of types to the compiler. But I don’t think it prevents any more logic bugs than any other type system that requires all branches of match and switch statements to be implemented. (Like elm for example)
I've written a bit of Rust, and I was left with mixed feelings, that seem to be still the same here: - loved the memory safety patterns when compared to the horrible things that you can do with C++ - found almost every thing where it was different to have a harder to parse syntax, that I could never get used to. The implicit return at the end of a statement for instance make it harder for me to visually parse what's…
I’m in the middle of working through The Rust Book, and I haven’t written any serious code with it yet, so interpret this through that lens. When I looked at rust code before, it all seemed a bit weird. I couldn’t immediately understand it, but I’ve since come to realize this was because the dozen or so languages I can read well don’t really resemble rust, so my pattern matching was a bit off. The more I learn about…
For instance, I'm fine to write C++, Javascript or Python (with types at least). Ruby or Rust for some reason do rub me the wrong way, no matter how much I try to tough it out.
I thought the creators of Rust were creator , singular, in Graydon Hoare. Are they involved with this?
Niko has been involved with Rust since before they had conceived of the borrow checker and the entire commiter list could be fed with a pizza.
Earlier quoted context omitted.
Yep, I think Crystal is the thing that is making a real go at essentially this suggestion. And I think it's a great language and hope it will grow.
Do you know how Crystal compares with Haxe? That's another one that might fit the requirements nicely.
Earlier quoted context omitted.
The other problem I see here is that starting and awaiting the task are too coupled. In JavaScript calling the function would start the task, and awaiting the result would wait for it. This lets you do several things concurrently. How would you do this in Dada: const doThings = async () => { const [one, two, three] = await Promise.all([ doThingOne(), doThingTwo(), doThingThree(), ]); }; And if you wanted to return a…
I assumed dada is using promises under the hood, just as JS is. If this is the case it could provide a static method for waiting on multiple promises, just as JS does.
Dada, like JavaScript, is based exclusively on async-await. This means that operations that perform I/O, like print, don't execute immediately. Instead, they return a thunk, which is basically "code waiting to run" (but not running yet). The thunk doesn't execute until you await it by using the .await operation.
Earlier quoted context omitted.
Also it immediately makes me wonder what `await` is... Is it a reference to a field of whatever the `print()` method is returning? Is it calling a method? If it's a method call without parentheses, how do I get a reference to a method without calling it? (These kinds of questions are just unavoidable though; everyone will have these little pet things that they subjectively prefer or dislike.)
They borrowed it from Rust: `.await` is special syntax, roughly equivalent to `await print(...)` in other languages. https://rust-lang.github.io/async-book/01_getting_started/04...