3 ms·

Note that I haven't watched the whole video, just skipped through it. That said, not to be negative, but what does this language offer over Rust? If the goal is

Note that I haven't watched the whole video, just skipped through it. That said, not to be negative, but what does this language offer over Rust? If the goal is to create a new language with an emphasis on safety and fine-grained memory control, along with a nice module system and high-level constructs like easy first-class functions, it seems like Rust already covers that. What does the language offer that's new?

hayksaakian 12y ago
offhand, one problem the author mentioned with rust was writing unsafe code. he went into detail in either the first or second video (I don't remember).
MrDom 12y ago
He beats that horse to death in the other two videos, which can be found at the link below. https://www.youtube.com/user/jblow888/videos https://www.youtube.com/user/jblow888/videos
- thinkpad20 12y ago
  I appreciate the response, but it'd be nicer to get a quick summary than a link to a pair of nearly two-hour videos.
  - gnuvince 12y ago
    For Rust, the short of it is that Blow finds its ideas too new and untested to dive into it. There are also some issues such as closures having a different syntax than top-level functions: he wants to be able to move functions easily between scopes.
    - bjz_ 12y ago
      > There are also some issues such as closures having a different syntax than top-level functions: he wants to be able to move functions easily between scopes. But closures have different semantics to functions, both in representation and in execution. The semantics of his language becomes even more confusing when he says that items at the top level are position independent, where as it seems that those in a function scope are, and yet they share the same syntax. There is a simple fix though. Just keep a uniform syntax for position independent items, but allow them to be declared at any scope. That is exactly what Rust does.
      - gnuvince 12y ago
        Yeah, I don't disagree, I'm just relating what he said in videos 1 and/or 2 about Rust. Personally, I'm all for having different syntax for different semantics.
mbrubeck 12y ago
This thread on the Rust subreddit compares Blow's language ideas to Rust: http://www.reddit.com/r/rust/comments/2gwi11/jonathan_blow_ideas_about_a_new_programming/ http://www.reddit.com/r/rust/comments/2gwi11/jonathan_blow_i... He specifically says that Rust "cares too much about safety" and that satisfying its safety guarantees adds too much friction to development. Some of the Rust programmers in the thread acknowledge that the safety/friction trade-off for games may be different from, say, OS kernels or web browsers. He also notes that Rust is new and still needs to prove itself, which I don't think anyone will disagree with.
- wtetzner 12y ago
  > He also notes that Rust is new and still needs to prove itself That's true, but I don't think making a new language avoids that problem.
eco 12y ago
I'm still watching it but I was thinking the same thing but about D. - Module system - Optionally avoiding complex build systems (rdmd or dub) - Fast build times - Type inference - Nested block comments - Owned memory (Unique, Scoped, RefCounted) - All variables initialized by default - Anonymous or strong enums - Specify enum type (inferred by default) - Order independent symbols - Scope guard statements (more powerful in D though) - Locally defined functions - Built-in dynamic arrays - Parameterized types (doesn't work in his language yet but he says it's coming) - Compile time function evaluation (only side-effect free code though so no playable space invaders at compile time) - Complex checks using compile time function evaluation - Generate code at compile time and mix it into the program itself I like where his language is headed but I'm not convinced we aren't already there. I guess I should go back and listen to his other talks to see why he's unsatisfied with Rust or D.
chipsy 12y ago
Blow wants to optimize for (developer) speed and simplicity over memory safety - roughly, "Go's simplicity, minus garbage collection" instead of what he calls "big idea" languages. Which I would never go for myself, but he's very adamant on this point; he dismisses most new ideas in PL theory entirely in favor of focusing on the engineering problem of smoothing out basic issues seen in his existing C++ development environment, where, to paraphrase him, "everything is junk and it demoralizes me". In that respect there's plenty we could learn from this project and its whole-process agenda, even if it isn't introducing sexy new methods. There are very few PL projects that aim only to work on boring everyday problems.
- lobster_johnson 12y ago
  I don't think Blow is against big ideas as such -- his language has some big ideas on its own -- but he certainly seems to prefer familiarity and simplicity over mind-altering language-theoretical weirdness. One aspect of familiarity, incidentally, is being able to hire junior devs. I see that as being a problem with Go -- and, in the future, Rust -- not to mention rocket-scientist languages like Haskell, Ocaml or even Scala, or indeed C++. Go is "simple", but not really that simple, not compared to Ruby or Python. (Of course, this might not be an issue for Blow, whose company is already using C++.) While Blow was originally talking about safety not being a paramount issue, I believe he has mentioned ownership-lifecycle management, possibly something like Rust's borrowing, as being on his mind.

hayksaakian 12y ago

offhand, one problem the author mentioned with rust was writing unsafe code. he went into detail in either the first or second video (I don't remember).

MrDom 12y ago

He beats that horse to death in the other two videos, which can be found at the link below. https://www.youtube.com/user/jblow888/videos https://www.youtube.com/user/jblow888/videos

thinkpad20 12y ago
I appreciate the response, but it'd be nicer to get a quick summary than a link to a pair of nearly two-hour videos.
- gnuvince 12y ago
  For Rust, the short of it is that Blow finds its ideas too new and untested to dive into it. There are also some issues such as closures having a different syntax than top-level functions: he wants to be able to move functions easily between scopes.
  - bjz_ 12y ago
    > There are also some issues such as closures having a different syntax than top-level functions: he wants to be able to move functions easily between scopes. But closures have different semantics to functions, both in representation and in execution. The semantics of his language becomes even more confusing when he says that items at the top level are position independent, where as it seems that those in a function scope are, and yet they share the same syntax. There is a simple fix though. Just keep a uniform syntax for position independent items, but allow them to be declared at any scope. That is exactly what Rust does.
    - gnuvince 12y ago
      Yeah, I don't disagree, I'm just relating what he said in videos 1 and/or 2 about Rust. Personally, I'm all for having different syntax for different semantics.

mbrubeck 12y ago

This thread on the Rust subreddit compares Blow's language ideas to Rust: http://www.reddit.com/r/rust/comments/2gwi11/jonathan_blow_ideas_about_a_new_programming/ http://www.reddit.com/r/rust/comments/2gwi11/jonathan_blow_i... He specifically says that Rust "cares too much about safety" and that satisfying its safety guarantees adds too much friction to development. Some of the Rust programmers in the thread acknowledge that the safety/friction trade-off for games may be different from, say, OS kernels or web browsers. He also notes that Rust is new and still needs to prove itself, which I don't think anyone will disagree with.

wtetzner 12y ago
> He also notes that Rust is new and still needs to prove itself That's true, but I don't think making a new language avoids that problem.

eco 12y ago

I'm still watching it but I was thinking the same thing but about D. - Module system - Optionally avoiding complex build systems (rdmd or dub) - Fast build times - Type inference - Nested block comments - Owned memory (Unique, Scoped, RefCounted) - All variables initialized by default - Anonymous or strong enums - Specify enum type (inferred by default) - Order independent symbols - Scope guard statements (more powerful in D though) - Locally defined functions - Built-in dynamic arrays - Parameterized types (doesn't work in his language yet but he says it's coming) - Compile time function evaluation (only side-effect free code though so no playable space invaders at compile time) - Complex checks using compile time function evaluation - Generate code at compile time and mix it into the program itself I like where his language is headed but I'm not convinced we aren't already there. I guess I should go back and listen to his other talks to see why he's unsatisfied with Rust or D.

chipsy 12y ago

Blow wants to optimize for (developer) speed and simplicity over memory safety - roughly, "Go's simplicity, minus garbage collection" instead of what he calls "big idea" languages. Which I would never go for myself, but he's very adamant on this point; he dismisses most new ideas in PL theory entirely in favor of focusing on the engineering problem of smoothing out basic issues seen in his existing C++ development environment, where, to paraphrase him, "everything is junk and it demoralizes me". In that respect there's plenty we could learn from this project and its whole-process agenda, even if it isn't introducing sexy new methods. There are very few PL projects that aim only to work on boring everyday problems.

lobster_johnson 12y ago
I don't think Blow is against big ideas as such -- his language has some big ideas on its own -- but he certainly seems to prefer familiarity and simplicity over mind-altering language-theoretical weirdness. One aspect of familiarity, incidentally, is being able to hire junior devs. I see that as being a problem with Go -- and, in the future, Rust -- not to mention rocket-scientist languages like Haskell, Ocaml or even Scala, or indeed C++. Go is "simple", but not really that simple, not compared to Ruby or Python. (Of course, this might not be an issue for Blow, whose company is already using C++.) While Blow was originally talking about safety not being a paramount issue, I believe he has mentioned ownership-lifecycle management, possibly something like Rust's borrowing, as being on his mind.