5 ms·

Are you saying that Rust, a system programming language, can compete with the scripting languages in speed of developing features?! Or are you saying that it i

by berntb 10y ago

Are you saying that Rust, a system programming language, can compete with the scripting languages in speed of developing features?! Or are you saying that it is a pleasure to use, so you'll use it for smaller backends where development speed isn't that critical? (Asking, not flaming. :-) )

cccooohn 10y ago
the goal of 2017 "robust, high-scale servers" is maybe for this. scripts have fast developing speed,but are not always robust,high-scale,specially for those backend services developed by many developers,here are fields of java,go,.net,even c++.a language with safety,high performance,low resource consumtion is strong competitor.languages with GC such as JAVA are resource monsters,specially when there are unlimited microservices running simultaneously
tatterdemalion 10y ago
> Are you saying that Rust, a system programming language, can compete with the scripting languages in speed of developing features?! I'll say it. At work, the backend is Rails, and I am a Rust contributor in my freetime. I am in the early stages of working on a framework for web apps in Rust & I believe it will be comparatively productive to Rails. Only your code will be faster and many bugs will be caught at compile time.
- berntb 10y ago
  Bold. :-) I do hope you're correct. (Given a modest test suite and checking parameters at external API interfaces, scripting languages didn't have much problems with bugs that could be found at compile time, imho.)
  - tatterdemalion 10y ago
    > (Given a modest test suite and checking parameters at external API interfaces, scripting languages didn't have much problems with bugs that could be found at compile time, imho.) Not my experience at all.
    - hinkley 10y ago
      I've given JavaScript about six years to prove that tests make up for static analysis and all I've learned is that we need MORE static analysis. I've met about four people in a dozen years that write better tests than me, and pretty much everyone else is writing garbage. And when I look back at my own I'm never satisfied. Essentially the only thing worse than no tests is thinking you have test safety when you don't. Particularly, negative tests in a dynamic language are easy to write but are virtually guaranteed to break at a later date without anyone noticing, because you are now looking in the wrong spot for a piece of data.
      - berntb 10y ago
        Good point about tests and dynamic data structures. Thanks.
      - Can_Not 10y ago
        Coming from dynamic land, including JavaScript, one thing I noticed about rust's types and compile time safety was how it would probably eliminate 90% of the unit tests needed for an equivalent JavaScript program, essentially allowing the programmer to focus on less pendantic and more useful-looking unit tests.
  - kazagistar 10y ago
    "Bugs that can be founderstood at compile time" is a complicated category, since it depends on how much you lean on your compiler to help. For example, wrapping primitive types in semantic wrapper types can be an easy way to catch errors where you mix up parameters. And with a sufficiently powerful type system like Idris you can theoretically catch literally any possible bug at compile time.
- erlend_sh 10y ago
  Have you heard about Helix? - http://blog.skylight.io/introducing-helix/ http://blog.skylight.io/introducing-helix/ I think this is a great way to introduce large existing Ruby codebases to Rust in increments, much like Sentry demonstrated recently, but for Python: https://blog.sentry.io/2016/10/19/fixing-python-performance-with-rust.html https://blog.sentry.io/2016/10/19/fixing-python-performance-...
  - tatterdemalion 10y ago
    Yep. :) Different usecase from what I'm working on; helix is for embedding Rust inside of a Ruby program, my library is for writing an HTTP service in Rust; so it will sit on top of tokio + hyper.
pjmlp 10y ago
It is possible to have both capabilities in a programming la language.
- berntb 10y ago
  I note the long list of obvious examples...? :-) But sure, the world would be a better place if Rust, Go and/or Swift could fulfill that niche. I really don't know enough. (Go seems a bit boring. Rust is too new. Swift is a bit limited re Linux etc support.) (I've seen the claim that some C++ gurus could develop features as quick as seasoned scripters, but... how many years did it take to get to that state? :-( ) (Sorry for coming back late.)
  - pjmlp 10y ago
    OCaml and Lisp come to mind as possible examples. Also note that for me personally, I don't see any value in using scripting languages for anything other than system administration instead of the more cryptic shell variants.
    - berntb 10y ago
      Ah, of course. I have long wondered why (Common) Lisp didn't take over the world at the end of the 90s to the beginning of the millennium. :-( They have a GC, but so do Java. There were good compilers since at least the 80s. But the lisp variants aren't really a system programming language that will replace C. (You can do bit fiddling, but... here the GC comes in, especially for embedded applications with KB of RAM. And so on.) >> I don't see any value in using scripting languages for anything other than system administration The point with scripting languages is that you can develop quickly. For applications where most time is in the DB anyway, they make a good solution. (I.e. for the last 20 years, system administration and web development.)
      - pjmlp 10y ago
        A thing called UNIX where the source code was available for free happened, but lets forget that fact. GC bashers would be surprised how much their lifes actually depends on embedded systems running real time Java deployments.
leshow 10y ago
Absolutely. But the trade-off is not so simple. I can be fairly confident that if my code compiles there are far fewer bugs than if I had written it in nodejs or php. So while it may take longer to get to the initial point that I have something running, I save time on subsequent refactors. And the added bonus, is that my code runs 10-20x faster. So I really didn't give up anything to get the increased confidence. However, I have to backtrack a bit here, because the largest Rust backend I've written was probably a little less than 10k lines. So while it was non-trivial it wasn't a massive undertaking.
- hinkley 10y ago
  There's a substantial discount in many developers heads about the ongoing maintenance costs of their code. To them the up front costs are the only thing that matters. If you're not spending significant time on rework it means your coworkers are doing it for you. As version control has gotten better it's harder to hide who is to blame but most people still don't bother to look. Which means you get no feedback about how good your code is.

by berntb 10y ago

cccooohn 10y ago

the goal of 2017 "robust, high-scale servers" is maybe for this. scripts have fast developing speed,but are not always robust,high-scale,specially for those backend services developed by many developers,here are fields of java,go,.net,even c++.a language with safety,high performance,low resource consumtion is strong competitor.languages with GC such as JAVA are resource monsters,specially when there are unlimited microservices running simultaneously

tatterdemalion 10y ago

> Are you saying that Rust, a system programming language, can compete with the scripting languages in speed of developing features?! I'll say it. At work, the backend is Rails, and I am a Rust contributor in my freetime. I am in the early stages of working on a framework for web apps in Rust & I believe it will be comparatively productive to Rails. Only your code will be faster and many bugs will be caught at compile time.

berntb 10y ago
Bold. :-) I do hope you're correct. (Given a modest test suite and checking parameters at external API interfaces, scripting languages didn't have much problems with bugs that could be found at compile time, imho.)
- tatterdemalion 10y ago
  > (Given a modest test suite and checking parameters at external API interfaces, scripting languages didn't have much problems with bugs that could be found at compile time, imho.) Not my experience at all.
  - hinkley 10y ago
    I've given JavaScript about six years to prove that tests make up for static analysis and all I've learned is that we need MORE static analysis. I've met about four people in a dozen years that write better tests than me, and pretty much everyone else is writing garbage. And when I look back at my own I'm never satisfied. Essentially the only thing worse than no tests is thinking you have test safety when you don't. Particularly, negative tests in a dynamic language are easy to write but are virtually guaranteed to break at a later date without anyone noticing, because you are now looking in the wrong spot for a piece of data.
    - berntb 10y ago
      Good point about tests and dynamic data structures. Thanks.
    - Can_Not 10y ago
      Coming from dynamic land, including JavaScript, one thing I noticed about rust's types and compile time safety was how it would probably eliminate 90% of the unit tests needed for an equivalent JavaScript program, essentially allowing the programmer to focus on less pendantic and more useful-looking unit tests.
- kazagistar 10y ago
  "Bugs that can be founderstood at compile time" is a complicated category, since it depends on how much you lean on your compiler to help. For example, wrapping primitive types in semantic wrapper types can be an easy way to catch errors where you mix up parameters. And with a sufficiently powerful type system like Idris you can theoretically catch literally any possible bug at compile time.
erlend_sh 10y ago
Have you heard about Helix? - http://blog.skylight.io/introducing-helix/ http://blog.skylight.io/introducing-helix/ I think this is a great way to introduce large existing Ruby codebases to Rust in increments, much like Sentry demonstrated recently, but for Python: https://blog.sentry.io/2016/10/19/fixing-python-performance-with-rust.html https://blog.sentry.io/2016/10/19/fixing-python-performance-...
- tatterdemalion 10y ago
  Yep. :) Different usecase from what I'm working on; helix is for embedding Rust inside of a Ruby program, my library is for writing an HTTP service in Rust; so it will sit on top of tokio + hyper.

pjmlp 10y ago

It is possible to have both capabilities in a programming la language.

berntb 10y ago
I note the long list of obvious examples...? :-) But sure, the world would be a better place if Rust, Go and/or Swift could fulfill that niche. I really don't know enough. (Go seems a bit boring. Rust is too new. Swift is a bit limited re Linux etc support.) (I've seen the claim that some C++ gurus could develop features as quick as seasoned scripters, but... how many years did it take to get to that state? :-( ) (Sorry for coming back late.)
- pjmlp 10y ago
  OCaml and Lisp come to mind as possible examples. Also note that for me personally, I don't see any value in using scripting languages for anything other than system administration instead of the more cryptic shell variants.
  - berntb 10y ago
    Ah, of course. I have long wondered why (Common) Lisp didn't take over the world at the end of the 90s to the beginning of the millennium. :-( They have a GC, but so do Java. There were good compilers since at least the 80s. But the lisp variants aren't really a system programming language that will replace C. (You can do bit fiddling, but... here the GC comes in, especially for embedded applications with KB of RAM. And so on.) >> I don't see any value in using scripting languages for anything other than system administration The point with scripting languages is that you can develop quickly. For applications where most time is in the DB anyway, they make a good solution. (I.e. for the last 20 years, system administration and web development.)
    - pjmlp 10y ago
      A thing called UNIX where the source code was available for free happened, but lets forget that fact. GC bashers would be surprised how much their lifes actually depends on embedded systems running real time Java deployments.

leshow 10y ago

Absolutely. But the trade-off is not so simple. I can be fairly confident that if my code compiles there are far fewer bugs than if I had written it in nodejs or php. So while it may take longer to get to the initial point that I have something running, I save time on subsequent refactors. And the added bonus, is that my code runs 10-20x faster. So I really didn't give up anything to get the increased confidence. However, I have to backtrack a bit here, because the largest Rust backend I've written was probably a little less than 10k lines. So while it was non-trivial it wasn't a massive undertaking.

hinkley 10y ago
There's a substantial discount in many developers heads about the ongoing maintenance costs of their code. To them the up front costs are the only thing that matters. If you're not spending significant time on rework it means your coworkers are doing it for you. As version control has gotten better it's harder to hide who is to blame but most people still don't bother to look. Which means you get no feedback about how good your code is.