7 ms·

With how much I hear about Rust on here, a little surprising to see it behind the likes of Haskell and and Perl! Kotlin is doing really well for its age especi

by sk0g 8y ago

With how much I hear about Rust on here, a little surprising to see it behind the likes of Haskell and and Perl! Kotlin is doing really well for its age especially, I'm guessing mostly used by Android devs (so far).

benatkin 8y ago
I'm not writing rust yet, but I'm using a couple of tools written in rust, and based on my experience with it, when I need a utility I seek out one that's written in rust. I'm using https://github.com/BurntSushi/ripgrep https://github.com/BurntSushi/ripgrep which is rg, like ack or ag (TheSilverSearcher). I've been using it for a few months, and I like it just a little bit more than ag, because I find its help and interface a bit easier to use. Like ag, it's incredibly fast. Just this week I started using https://github.com/watchexec/watchexec https://github.com/watchexec/watchexec to run rsync to sync from my mac to my vagrant box, because I was switching from using neovim on vagrant to using Visual Studio Code. It works great and has a very nice command-line UI. Another tool that's written in go that I thought maybe was written in rust that's handy is https://github.com/shenwei356/rush https://github.com/shenwei356/rush which runs multiple commands in parallel, like xargs. I'm using it to transfer images between folders on s3 using aws-cli. Based on this, and Servo, which is unstoppable with its Doge logo, I think Rust is going to be a very widely used language. https://github.com/servo https://github.com/servo Edit: I remember part of why I liked rg more than ag - I got to use cargo rather than go, which is a much more intuitive and less opinionated way of downloading libraries than using the go cli. go is coming around though: https://blog.golang.org/modules2019 https://blog.golang.org/modules2019
- sk0g 8y ago
  How much of it is because there's a reason (of sorts), to do a complete re-think, when you're porting tools over? C and C++ have been stable for years, and so has all the little UNIX tooling that was built using them. People are excited by Rust, and take it upon themselves to re-build these tools, as they have well defined requirements and characteristics. The reason these tools might be better is because thought has gone in to modernising and enhancing existing features. That might not be so feasible/ easily doable if you were juggling a decades old codebase to start off with. I'm not sure what my point is, entirely... But ripgrep is good! I have replaced awk and grep with it, because it just feels more... user friendly? EDIT: remembered my point. Are you switching to Rust tools because they are written in rust/ benefit from Rust in some unique way, or because it's a common platform people are re-implementing and re-imagining classic UNIX tools in?
  - benatkin 8y ago
    It’s because I want something that’s been re-imagined, yes.
  - feanaro 8y ago
    > Are you switching to Rust tools because they are written in rust/ benefit from Rust in some unique way, or because it's a common platform people are re-implementing and re-imagining classic UNIX tools in? I think it's a little bit of both for me. The Rust tools tend to have a nicer UX (pretty-printing, colouring by default, with smart detection whether output is to a terminal, subcommand-oriented CLI a la git, etc). This is probably a consequence of nice library defaults but also a matter of culture. They also tend to be very fast. Again, Rust is inherently inducive to writing fast tools, but you also have to do things the right way.
- chmln 8y ago
  Shameless plug - you may also wanna try https://github.com/chmln/sd https://github.com/chmln/sd :)
  - benatkin 8y ago
    I already found it and used it a couple times but forgot about it! It’s pretty neat. Gonna try using it for little things now that I’m using vscode instead of vim.
hardwaresofton 8y ago
I was pretty disappointed in the lack of progress, but a few things come to mind: 1. IMO Rust has the closest thing in "imperative" languages to haskell's type system in a recently released "mainstream" language. 2. Rust brings an entirely new value (memory safety), and accordingly an entirely new hurdle called the borrow checker. This feature is so advanced that languages like Haskell are catching up (it's not a competition really) by introducing things like Linear Types[0]. That's really impressive. 3. Rust is targeting system programmers -- they move the slowest (as they should) in the ecosystem and are the most risk averse (as they should be). 4. Compare Rust to relatively recent systems-level languages (I won't name any), it's doing great. 5. Staying at the same place in the rankings is actually moving forward -- it may not seem like it, but it's hard to stay both effective, liked, and relevant in the world of programming languages (see: Dart). I don't think rust is the kind of language to just shoot up the rankings -- it contains both higher level techniques that aren't quite mainstream yet and is targeted at a smaller community (though they're kind of going after web people with the wasm stuff). I think rust is the kind of language that shows up to be consistently near the top of the rankings in 10 years (and I've said it numerous times but I think Go will displace Java and Rust will displace C/C++ where possible). Yes, I will concede to a slight bias in favor of rust :). [0]: https://gitlab.haskell.org/ghc/ghc/wikis/linear-types https://gitlab.haskell.org/ghc/ghc/wikis/linear-types
- sk0g 8y ago
  Now I'm curious! What are other systems-level languages? I know Go was touted as one at the start, but that's definitely not where it's established a niche! Julia? Nim? That's about all that comes to mind. I wish I could read the Haskell documentation, but the code examples are straight up black magic to me. I really need to dig into some proper functional programming at some point!
  - pjmlp 8y ago
    D, Free Pascal/Delphi, .NET Native, Ada, ATS, Zig, Jai, Oberon, C++20
  - hardwaresofton 8y ago
bsder 8y ago
> With how much I hear about Rust on here, a little surprising to see it behind the likes of Haskell and and Perl! Perl? Please, Perl was SO huge that I'm surprised it's as low as it is (which makes me suspect the methodology, actually ...). In addition, if I remember from the TIOBE index there is the "Top Ten" and "everything else" where 10-20 is basically 1%+some noise and 20-50 is like .3%+noise. > Kotlin is doing really well for its age especially, I'm guessing mostly used by Android devs (so far). I wish the Android ecosystem would finally pick something and just stick with it. Having tooling, samples, and documentation that don't go out of date every 6 months outweighs any mythical "advantage" that switching language, build system, etc. actually gains.
- sk0g 8y ago
  > Having tooling, samples, and documentation that don't go out of date every 6 months This is exactly why I didn't stick with Android for too long. Everything's too... in flux, but in a weird way. "YAY, Google released this feature I've been dying for! Can't wait to use it in 4 years, when enough phones actually support it :)". It's either that or have API level dependent code. Maybe Dart will fix some of these pains, by abandoning all they have built up? It is Google, so I'd say it's unlikely, but still. Hell, I was trying to build an analog clock widget as a tribute to a certain sports team, and Google had deprecated the AnalogClock class. Its successor was, well, nothing. So a few community efforts took its place, and the fragmentation only got worse. Thanks, but no thanks!
  - bsder 8y ago
    Dart? All the cool kids use Kotlin, now, dontchaknow. The only good part about Kotlin getting entrenched is that JetBrains is MASSIVELY invested in not letting Google switch to something else--so we may finally get some stability for a change.
    - pjmlp 8y ago
      That depends pretty much on internal politics from other OS groups.
- 8y ago
hugh4life 8y ago
I think Rust will get a bump in popularity when Rocket no longer requires nightly releases. https://github.com/SergioBenitez/Rocket/issues/19 https://github.com/SergioBenitez/Rocket/issues/19
pjmlp 8y ago
Languages only win long term when they get either a platform or a killer framework of some kind. For Kotlin that is Android. I am more interested to see what will happen to it if Google has one of their usual project reboots with Android. Rust still fails short in several domains, but now with Google and Microsoft's additional love we might see some improvements there.
iainmerrick 8y ago
Here’s a random question on Kotlin, hopefully not too controversial... I now use Kotlin on Android, and it’s mostly a tidied-up Java that’s slightly better in every way. The one big difference is checked exceptions -- Kotlin doesn’t have them. My question is, do Kotlin users prefer unchecked exceptions, or do you find yourself avoiding exceptions entirely now? Or even dropping back to Java when you need exceptions and you want compile-time checks? I find myself mostly trying to avoid exceptions entirely in Kotlin -- maybe not such a bad thing!
- aembleton 8y ago
  If I want an exception, then I don't want it checked otherwise I have to handle it at every layer in which case I may as return a nullable object and handle that. I generally find that I avoid exceptions, but where they are necessary I try and catch at the right level to handle them.
- guiye 8y ago
  Use some lib like vavr (ex javaslang) for catching exceptions into a Try object, a simple functional solution
  - iainmerrick 8y ago
    Sure, but without checked exceptions, the compiler won’t tell you whether you’re catching/wrapping the right exceptions in the right places.
- V-2 8y ago
  I don't think checked exceptions have many defenders left... even among their original proponents. And no language (at least no significant one) really copied Java in this regard, as far as I'm aware. I can't speak for Kotlin users en masse, but personally I don't miss checked exceptions one bit, same as I didn't miss them in C#. And I've never encountered the practice of "dropping back to Java" for checked exceptions of all the reasons. A compelling way of emulating the presumed benefits - without the bad parts - in Kotlin would be to go sort of functional and use a Try return type from Arrow-Kt: https://arrow-kt.io/docs/arrow/core/try/ https://arrow-kt.io/docs/arrow/core/try/

by sk0g 8y ago

benatkin 8y ago

I'm not writing rust yet, but I'm using a couple of tools written in rust, and based on my experience with it, when I need a utility I seek out one that's written in rust. I'm using https://github.com/BurntSushi/ripgrep https://github.com/BurntSushi/ripgrep which is rg, like ack or ag (TheSilverSearcher). I've been using it for a few months, and I like it just a little bit more than ag, because I find its help and interface a bit easier to use. Like ag, it's incredibly fast. Just this week I started using https://github.com/watchexec/watchexec https://github.com/watchexec/watchexec to run rsync to sync from my mac to my vagrant box, because I was switching from using neovim on vagrant to using Visual Studio Code. It works great and has a very nice command-line UI. Another tool that's written in go that I thought maybe was written in rust that's handy is https://github.com/shenwei356/rush https://github.com/shenwei356/rush which runs multiple commands in parallel, like xargs. I'm using it to transfer images between folders on s3 using aws-cli. Based on this, and Servo, which is unstoppable with its Doge logo, I think Rust is going to be a very widely used language. https://github.com/servo https://github.com/servo Edit: I remember part of why I liked rg more than ag - I got to use cargo rather than go, which is a much more intuitive and less opinionated way of downloading libraries than using the go cli. go is coming around though: https://blog.golang.org/modules2019 https://blog.golang.org/modules2019

sk0g 8y ago
How much of it is because there's a reason (of sorts), to do a complete re-think, when you're porting tools over? C and C++ have been stable for years, and so has all the little UNIX tooling that was built using them. People are excited by Rust, and take it upon themselves to re-build these tools, as they have well defined requirements and characteristics. The reason these tools might be better is because thought has gone in to modernising and enhancing existing features. That might not be so feasible/ easily doable if you were juggling a decades old codebase to start off with. I'm not sure what my point is, entirely... But ripgrep is good! I have replaced awk and grep with it, because it just feels more... user friendly? EDIT: remembered my point. Are you switching to Rust tools because they are written in rust/ benefit from Rust in some unique way, or because it's a common platform people are re-implementing and re-imagining classic UNIX tools in?
- benatkin 8y ago
  It’s because I want something that’s been re-imagined, yes.
- feanaro 8y ago
  > Are you switching to Rust tools because they are written in rust/ benefit from Rust in some unique way, or because it's a common platform people are re-implementing and re-imagining classic UNIX tools in? I think it's a little bit of both for me. The Rust tools tend to have a nicer UX (pretty-printing, colouring by default, with smart detection whether output is to a terminal, subcommand-oriented CLI a la git, etc). This is probably a consequence of nice library defaults but also a matter of culture. They also tend to be very fast. Again, Rust is inherently inducive to writing fast tools, but you also have to do things the right way.
chmln 8y ago
Shameless plug - you may also wanna try https://github.com/chmln/sd https://github.com/chmln/sd :)
- benatkin 8y ago
  I already found it and used it a couple times but forgot about it! It’s pretty neat. Gonna try using it for little things now that I’m using vscode instead of vim.

hardwaresofton 8y ago

I was pretty disappointed in the lack of progress, but a few things come to mind: 1. IMO Rust has the closest thing in "imperative" languages to haskell's type system in a recently released "mainstream" language. 2. Rust brings an entirely new value (memory safety), and accordingly an entirely new hurdle called the borrow checker. This feature is so advanced that languages like Haskell are catching up (it's not a competition really) by introducing things like Linear Types[0]. That's really impressive. 3. Rust is targeting system programmers -- they move the slowest (as they should) in the ecosystem and are the most risk averse (as they should be). 4. Compare Rust to relatively recent systems-level languages (I won't name any), it's doing great. 5. Staying at the same place in the rankings is actually moving forward -- it may not seem like it, but it's hard to stay both effective, liked, and relevant in the world of programming languages (see: Dart). I don't think rust is the kind of language to just shoot up the rankings -- it contains both higher level techniques that aren't quite mainstream yet and is targeted at a smaller community (though they're kind of going after web people with the wasm stuff). I think rust is the kind of language that shows up to be consistently near the top of the rankings in 10 years (and I've said it numerous times but I think Go will displace Java and Rust will displace C/C++ where possible). Yes, I will concede to a slight bias in favor of rust :). [0]: https://gitlab.haskell.org/ghc/ghc/wikis/linear-types https://gitlab.haskell.org/ghc/ghc/wikis/linear-types

sk0g 8y ago
Now I'm curious! What are other systems-level languages? I know Go was touted as one at the start, but that's definitely not where it's established a niche! Julia? Nim? That's about all that comes to mind. I wish I could read the Haskell documentation, but the code examples are straight up black magic to me. I really need to dig into some proper functional programming at some point!
- pjmlp 8y ago
  D, Free Pascal/Delphi, .NET Native, Ada, ATS, Zig, Jai, Oberon, C++20
- hardwaresofton 8y ago

bsder 8y ago

> With how much I hear about Rust on here, a little surprising to see it behind the likes of Haskell and and Perl! Perl? Please, Perl was SO huge that I'm surprised it's as low as it is (which makes me suspect the methodology, actually ...). In addition, if I remember from the TIOBE index there is the "Top Ten" and "everything else" where 10-20 is basically 1%+some noise and 20-50 is like .3%+noise. > Kotlin is doing really well for its age especially, I'm guessing mostly used by Android devs (so far). I wish the Android ecosystem would finally pick something and just stick with it. Having tooling, samples, and documentation that don't go out of date every 6 months outweighs any mythical "advantage" that switching language, build system, etc. actually gains.

sk0g 8y ago
> Having tooling, samples, and documentation that don't go out of date every 6 months This is exactly why I didn't stick with Android for too long. Everything's too... in flux, but in a weird way. "YAY, Google released this feature I've been dying for! Can't wait to use it in 4 years, when enough phones actually support it :)". It's either that or have API level dependent code. Maybe Dart will fix some of these pains, by abandoning all they have built up? It is Google, so I'd say it's unlikely, but still. Hell, I was trying to build an analog clock widget as a tribute to a certain sports team, and Google had deprecated the AnalogClock class. Its successor was, well, nothing. So a few community efforts took its place, and the fragmentation only got worse. Thanks, but no thanks!
- bsder 8y ago
  Dart? All the cool kids use Kotlin, now, dontchaknow. The only good part about Kotlin getting entrenched is that JetBrains is MASSIVELY invested in not letting Google switch to something else--so we may finally get some stability for a change.
  - pjmlp 8y ago
    That depends pretty much on internal politics from other OS groups.
8y ago

hugh4life 8y ago

I think Rust will get a bump in popularity when Rocket no longer requires nightly releases. https://github.com/SergioBenitez/Rocket/issues/19 https://github.com/SergioBenitez/Rocket/issues/19

pjmlp 8y ago

Languages only win long term when they get either a platform or a killer framework of some kind. For Kotlin that is Android. I am more interested to see what will happen to it if Google has one of their usual project reboots with Android. Rust still fails short in several domains, but now with Google and Microsoft's additional love we might see some improvements there.

iainmerrick 8y ago

Here’s a random question on Kotlin, hopefully not too controversial... I now use Kotlin on Android, and it’s mostly a tidied-up Java that’s slightly better in every way. The one big difference is checked exceptions -- Kotlin doesn’t have them. My question is, do Kotlin users prefer unchecked exceptions, or do you find yourself avoiding exceptions entirely now? Or even dropping back to Java when you need exceptions and you want compile-time checks? I find myself mostly trying to avoid exceptions entirely in Kotlin -- maybe not such a bad thing!

aembleton 8y ago
If I want an exception, then I don't want it checked otherwise I have to handle it at every layer in which case I may as return a nullable object and handle that. I generally find that I avoid exceptions, but where they are necessary I try and catch at the right level to handle them.
guiye 8y ago
Use some lib like vavr (ex javaslang) for catching exceptions into a Try object, a simple functional solution
- iainmerrick 8y ago
  Sure, but without checked exceptions, the compiler won’t tell you whether you’re catching/wrapping the right exceptions in the right places.
V-2 8y ago
I don't think checked exceptions have many defenders left... even among their original proponents. And no language (at least no significant one) really copied Java in this regard, as far as I'm aware. I can't speak for Kotlin users en masse, but personally I don't miss checked exceptions one bit, same as I didn't miss them in C#. And I've never encountered the practice of "dropping back to Java" for checked exceptions of all the reasons. A compelling way of emulating the presumed benefits - without the bad parts - in Kotlin would be to go sort of functional and use a Try return type from Arrow-Kt: https://arrow-kt.io/docs/arrow/core/try/ https://arrow-kt.io/docs/arrow/core/try/