3 ms·

I'm saying it. The piston developers are doing what right now? Writing a new programming language (dyon). Why are they doing that? Because rust is great for pr

I'm saying it. The piston developers are doing what right now? Writing a new programming language (dyon). Why are they doing that? Because rust is great for prototyping games in? no. ...rust is verbose. It is statically typed, it is less productive than some other languages and it is hard to learn. Now, you get a whole lot of other benefits in exchange for that, absolutely, and technically speaking, rust is a super awesome and sophisticated language. ...but right now, it has neither the ecosystem nor simplicity for picking up and practically solving high level problems. If you have a problem, right now, you want to solve: pick go. ...unless your problem is something that rust would be better at, and those things are low level things, like building game engines, not high level things like building web applications and cross platform desktop chat applications or machine learning solutions to driving cars. You can build high level applications in rust, and in C++; the point I'm making is that unless you actually have a reason for picking them (and there are plenty...), don't. Pick the tool for the job; rust is a great tool for the right job. Go is a better tool for a lot of applications; and a totally useless one for others. /shrug. We don't need to pretend rust is general high level language you should pick up and use for any problem domain. It's not. You're shooting yourself in the foot if you use it as though it was.

stymaar 10y ago
> The piston developers are doing what right now? Writing a new programming language (dyon). Why are they doing that? Because rust is great for prototyping games in? I agree with that, Rust is not a scripting language. Dynamically-typed scripting languages have proven their efficiency for prototyping. > rust is verbose. It is statically type, it is less productive than some other languages Than scripting languages yes, but it's exactly on the same side than Go on this point. Scripting languages are extremely convenient for small projects, but are more difficult to maintain in the long run if the project grows too big. (I personally live coding JavaScript, and a the project grows we are progressively add a static-typing layer (flowtype.org) to our code for the sake of maintenance). > it has neither the ecosystem nor simplicity for picking up and practically solving high level problems. There is a real trade-off between scripting languages (Python, Ruby and Nodejs), and statically-typed ones (Java, Go, and Rust), but it's not related to being high-level or not. In term of abstractions and features, Rust is at least as high-level as Java & Go. > If you have a problem, right now, you want to solve: pick go. We are using some Go at my company because we wanted to follow the trend, but frankly unless you want to built a simple system with no dependencies, Go is not ready to solve problem «right now» either, because the ecosystem is still really poor. If you have a problem, right now, you want to solve, you should probably still pick Java over Go, even if a lot of people (me included) don't like Java … Basically I think Java is the most important factor of success of the Go language: Go feels like Java, but in a younger and trendier way. > We don't need to pretend rust is general high level language you should pick up and use for any problem domain. It's not. You're shooting yourself in the foot if you use it as though it was. Rust is a «general high level language», with the same high-level generality than Go or Java. I bet one can chose any* Go or Java code sample, and rewrite it in Rust with around the same amount of code and without introducing any memory issues (what you wouldn't be able to do in C or C++). I think that's a good illustration of Rust being a «general high level language». *unless it depends on a library that has no equivalent in Rust (as I said before, the youth of Rust's ecosystem is the reason not to use Rust in S1 2016). > and it is hard to learn. It is indeed, no discussion about that.
- lossolo 10y ago
  > (what you wouldn't be able to do in C or C++) I would and many more people also would but for sure it would be harder/more complex in C/C++ than in Go. You wrote that as it would be impossible to do it in C or C++ which is not true.
  - shadowmint 10y ago
    They're referring to memory safety, which isn't possible in C/C++* and is in rust. (and in go and java and js, yes; but not in C/C++ or any other low level language) (* without external formal verification, which makes it technically possible I suppose, but not as a built-in feature)
  - stymaar 10y ago
    Of course it's possible to do the same thing in C, but most likely not with «the same amount of code», nor with «memory safety». ;)
    - lossolo 10y ago
      > nor with «memory safety» I've wrote that you can do it with memory safety which is possible BUT it's more complex in languages like C/C++ that do not guarantee memory safety (it's your responsibility). If it was not possible then you would not have anything on your screen right now. I am writing that because someone that is not familiar with those languages would get impression from your comment that memory safety is impossible in C/C++ which is not true.
- shadowmint 10y ago
  eh, I don't want to argue; I've said my bit. Verbose low level memory safety and a high level trait system is a massive step up from C++/C. It's of mixed value if you're doing something you could do in java or go. It's of questionable value if you're doing something you could just whip up in python or js. Perhaps you're right; rather than just straight out saying go, I'll preface my answer next time I hear the go/rust question: 'Should a write my next project in go or rust?' 'If you didn't use either, would you write it in C++?' '...no?' -> 'Then pick go.' '...yes?' -> 'Wtf dude, there's no way you could do it in go then. use rust.'

stymaar 10y ago

> The piston developers are doing what right now? Writing a new programming language (dyon). Why are they doing that? Because rust is great for prototyping games in? I agree with that, Rust is not a scripting language. Dynamically-typed scripting languages have proven their efficiency for prototyping. > rust is verbose. It is statically type, it is less productive than some other languages Than scripting languages yes, but it's exactly on the same side than Go on this point. Scripting languages are extremely convenient for small projects, but are more difficult to maintain in the long run if the project grows too big. (I personally live coding JavaScript, and a the project grows we are progressively add a static-typing layer (flowtype.org) to our code for the sake of maintenance). > it has neither the ecosystem nor simplicity for picking up and practically solving high level problems. There is a real trade-off between scripting languages (Python, Ruby and Nodejs), and statically-typed ones (Java, Go, and Rust), but it's not related to being high-level or not. In term of abstractions and features, Rust is at least as high-level as Java & Go. > If you have a problem, right now, you want to solve: pick go. We are using some Go at my company because we wanted to follow the trend, but frankly unless you want to built a simple system with no dependencies, Go is not ready to solve problem «right now» either, because the ecosystem is still really poor. If you have a problem, right now, you want to solve, you should probably still pick Java over Go, even if a lot of people (me included) don't like Java … Basically I think Java is the most important factor of success of the Go language: Go feels like Java, but in a younger and trendier way. > We don't need to pretend rust is general high level language you should pick up and use for any problem domain. It's not. You're shooting yourself in the foot if you use it as though it was. Rust is a «general high level language», with the same high-level generality than Go or Java. I bet one can chose any* Go or Java code sample, and rewrite it in Rust with around the same amount of code and without introducing any memory issues (what you wouldn't be able to do in C or C++). I think that's a good illustration of Rust being a «general high level language». *unless it depends on a library that has no equivalent in Rust (as I said before, the youth of Rust's ecosystem is the reason not to use Rust in S1 2016). > and it is hard to learn. It is indeed, no discussion about that.

lossolo 10y ago
> (what you wouldn't be able to do in C or C++) I would and many more people also would but for sure it would be harder/more complex in C/C++ than in Go. You wrote that as it would be impossible to do it in C or C++ which is not true.
- shadowmint 10y ago
  They're referring to memory safety, which isn't possible in C/C++* and is in rust. (and in go and java and js, yes; but not in C/C++ or any other low level language) (* without external formal verification, which makes it technically possible I suppose, but not as a built-in feature)
- stymaar 10y ago
  Of course it's possible to do the same thing in C, but most likely not with «the same amount of code», nor with «memory safety». ;)
  - lossolo 10y ago
    > nor with «memory safety» I've wrote that you can do it with memory safety which is possible BUT it's more complex in languages like C/C++ that do not guarantee memory safety (it's your responsibility). If it was not possible then you would not have anything on your screen right now. I am writing that because someone that is not familiar with those languages would get impression from your comment that memory safety is impossible in C/C++ which is not true.
shadowmint 10y ago
eh, I don't want to argue; I've said my bit. Verbose low level memory safety and a high level trait system is a massive step up from C++/C. It's of mixed value if you're doing something you could do in java or go. It's of questionable value if you're doing something you could just whip up in python or js. Perhaps you're right; rather than just straight out saying go, I'll preface my answer next time I hear the go/rust question: 'Should a write my next project in go or rust?' 'If you didn't use either, would you write it in C++?' '...no?' -> 'Then pick go.' '...yes?' -> 'Wtf dude, there's no way you could do it in go then. use rust.'