8 ms·

Just how prevalent is Rust in the industry? I remember trying it out back in 2014 and saw nothing of interest, as a Haskell user. A lot of the main "selling poi

by li4ick 6y ago

Just how prevalent is Rust in the industry? I remember trying it out back in 2014 and saw nothing of interest, as a Haskell user. A lot of the main "selling points" of Rust are getting introduced in C++. Also, what is it about Rust that gets automatic top view on HN?

adamnemecek 6y ago
The fact that you can actually ship an app. I've been writing my app (it's an IDE for music http://ngrid.io http://ngrid.io) in Rust after trying it in cpp and swift and it's a joy to use. Haskell is cool and all but every time I tried it, I spent too much tle with package management for example. Also you can't really ship an app in Haskell.
- LandR 6y ago
  I dont know Haskell, why can't you ship an app in Haskell?
  - nine_k 6y ago
    You totally can. I use pandoc regularly (though some would say it's a "utility" and not an "app").
    - adamnemecek 6y ago
      I mean like a desktop app.
      - nine_k 6y ago
        xmonad? :) Frankly, I did nit see people releasing proper desktop apps for some time now :( Electron apps do not count.
- diath 6y ago
  What is "ship an app" supposed to even mean here? Being able to build a binary for distribution? Both Swift and C++ can do that, and likely Haskell too.
  - adamnemecek 6y ago
    I was talking about shipping in haskell. Technically yes, practically few people do it and for good reasons.
- dman 6y ago
  What are you using for the UI layer?
  - adamnemecek 6y ago
    I'm building my own using femtovg https://github.com/femtovg/femtovg https://github.com/femtovg/femtovg
    - auggierose 6y ago
      Well, if you have to do that in order to "actually ship an app" :-D I'll stay with Swift for now.
      - adamnemecek 6y ago
        It depends on your app, but for me, cocoa didn't quite cut it. Given my app uses some shaders.
        auggierose 6y ago
        You can write Metal shaders and call them from Swift. I'd say that is easier than to write your own UIKit ;-)
      - outworlder 6y ago
        have to? No. https://www.areweguiyet.com/ https://www.areweguiyet.com/
        auggierose 6y ago
        According to that link, you pretty much have to.
    - outworlder 6y ago
      I am a fan of OpenGL based GUIs. I built my first one before Y2k. There's something nice about crafting UI widgets, with all their behaviors that scratches a particular itch I can't explain. That said, it is really really tough to get all the little behaviors that people rely on. Including all keyboard shortcuts (across all platforms), double/triple clicking words, etc. I guess that this may not matter that much for specialized software (but please focus on the damn textboxes, they are hard to get right). I'm just commenting in case other people decide to follow the same path. Also, for a broader audience: be mindful of accessibility. Usually, this kind of thing doesn't work with screen readers.
- offtop5 6y ago
  Any screenshots of the application your working on. I seriously love working on music and I'm down to try anything, but I have no idea what your app actually is
  - adamnemecek 6y ago
    I'll be shipping soon.
    - scns 6y ago
      Please do a Show HN
      - adamnemecek 6y ago
        I'm definitely planning on doing that.
- sunshinerag 6y ago
  curious about your experience with Swift? can you share?
  - adamnemecek 6y ago
    I think the language is nice however the niceness comes at the cost of performance. Swift has a relatively unique performance in that it's faster than garbage collected languages but slower than C or Rust due to some hidden runtime locks. Another problem is with the package ecosystem. It feels like most of Swift ecosystem is wrappers around Apple APIs. There are also some strange workflow edge cases like the fact that you currently cannot use Metal shaders in Swift Packages. This is due to the fact that Xcode projects are supposed to be ephemeral (not version controlled, but generated when you clone the package). However if you want to compile Metal, you have to add some compiler options. As a result, every time you add a dependency, you have to regenerate the XCode project file, you have to fuck with your XCode project to add the compiler options. Ironically, you can use Metal in Rust crates just fine. Rust is also truly cross-platform. Windows and Linux have first class support. To summarize my argument, Swift feels like daddy Apple is telling me what is best for me which may or may not be true. Rust feels like true empowerment. If there is something that doesn't suit me for whatever reason, there is generally a way of working around it. I guess it depends on what you are doing. Swift is OK for iOS/macOS development but other than that Rust is more advanced. Rust macros are really powerful, things that need to be added explicitly to the Swift compiler can be implemented as Rust macros.
    - pjmlp 6y ago
      > Swift has a relatively unique performance in that it's faster than garbage collected languages but slower than C or Rust due to some hidden runtime locks. Yep blazing fast indeed. /s https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages
eloff 6y ago
Programming languages can be a very personal thing. But I will offer my perspective having used C++ extensively (both modern and awful), Go, Rust, a little Haskell and some 20 other languages in my two decades career. Rust is one of the nicest languages out there. Very well thought out, elegant, full low-level control for real systems programming (sorry Go!) AWS uses it a lot, Microsoft is starting to use it. Go, or even Python is better if you just want to make a backend API for a (web) app. You'll be more productive with it over Rust because you have a GC and can ignore the whole ownership issue for the most part. Python for very small teams likely to stay small for a long time, Go otherwise. C++ has come a long way, but it's still hairy and loaded with footguns and baggage. I would only use it these days if I needed to use a big C++ library (like a game engine). I am no longer willing to use Haskell, PHP, Perl, Java or JVM languages, .NET or anything else that's not Go, Rust or Python. With the same caveat as C++ above. I pass over job postings that require them. That's not saying those languages are bad, just that in my personal opinion there are better tools out there, and if I'm going to work with it day in and day out, it had better be in something at the top of my list - because life is short.
- ragnese 6y ago
  Have you played with OCaml recently (last year or two)? Wondering what your opinion is on it, especially in relation to Haskell and Rust.
  - adamnemecek 6y ago
    Speed, developer ergonomics and community. It depends what you are building I guess but for example audio processing or graphics is still impossible in either of those.
- aprdm 6y ago
  Saying AWS uses it a lot is very misleading. Same for Microsoft. I won’t dispute that there are some teams using it but the majority of new projects aren’t in rust and there’s no trend for it.
  - 6y ago
steveklabnik 6y ago
Rust in 2014 and Rust today are very different; specifically, 2014 to 2015 was a very tumultuous time. 2015 saw the release of Rust 1.0, and so a lot of stuff happened to get things ready for that, including some very large changes to the entire standard library, a removal of most of the runtime... all sorts of stuff.
voxl 6y ago
If you're a genuine Haskell user then it shouldn't take more than a second to realize that true borrow checking is not the same as C++ pointer types, and that Cargo is thee best dependency manager. Although, being a Haskell user, you might suffer stockholm syndrome in regards to the dependency hell that is cabal or stack.
- deleted 6y ago
  [deleted]
- higerordermap 6y ago
  Noice troll.
pjmlp 6y ago
It depends pretty much on the domain. Just think that it took C++ 40 years to reach where it is now and still there are domains where C rules, a systems language that people forget is only 10 years younger than COBOL.
gameswithgo 6y ago
>Just how prevalent is Rust in the industry? It has been picking up a lot lately, Apple, Amazon, and Microsoft are all showing some adoption, for instance. > I remember trying it out back in 2014 and saw nothing of interest, as a Haskell user The interest for a Haskell user would be that you have some of the functional programming features you like (such as discriminated unions!) with C/C++ levels of runtime performance/efficiency. For someone who has no need for that level of low level control/performance, Rust is generally not a language you want to use, for sure. > A lot of the main "selling points" of Rust are getting introduced in C++ It is true that you could, with sufficient coding standards and linters, get something approximately like Rust by using C++, where the linter disallows any non safe pointers, any use of null or nullable types without wrapping it in a variant, disallowing all cases of undefined behavior, and so on. However you would have something a lot less pleasant to use than using Rust in the first place, build times would probably end up worse with those thing enforced as a build step, and setting up such an environment would be non trivial and you basically are just building rust out of C++, twine and gum, so why not just use Rust?
- jcelerier 6y ago
  > and you basically are just building rust out of C++, twine and gum, so why not just use Rust? my 100% honest answer: Rust does not have Qt
  - pizza234 6y ago
    As a non-Qt developer: which are the limitations of using Qt bindings?
    - heavyset_go 6y ago
      They're incomplete and the last time I looked, you needed to create Qt bindings for Rust using some code generator.
    - csnover 6y ago
      Rust doesn’t support object inheritance (only traits). It also doesn’t have function overloads or default arguments. Qt relies heavily on all of these C++ features; inheritance is fundamental to how Qt works (for example, it is impossible to respond to mouse/keyboard events without subclassing to override virtual methods), and function overloads with default arguments are used everywhere. As a result, it’s a struggle to shoehorn this object model into Rust. rust-qt[0] doesn’t support inheritance at all, so you can only connect to things in Qt which accept callbacks using slots. It requires `'static` lifetime on those callbacks, so as far as I can tell you are also forced to use `Rc`s whenever you are doing something with a rust-qt object even if you should be able to use a plain reference. The code is auto-generated, so all APIs are `unsafe`, and no function overloads means names are gross because the function signatures must be expressed in the function name (e.g. the `QMessageBox` constructor[1] becomes `QMessageBox::from_icon2_q_string_q_flags_standard_button_q_widget`). This could be improved by using `Option`s for arguments with defaults, but right now this is what it looks like. qmetaobject-rs[2] has some support for inheritance but as far as I can tell it’s limited to a couple of base types only. It’s also designed around using QML, so it doesn’t actually expose most of the Qt API. As such I don’t have too much experience with it. I’m unaware of any other usable Rust Qt bindings right now. I currently make things work by using rust-cpp[3] to create C++ subclasses and smuggle events, but this sucks because it also means the objects on the Rust side need to have the Qt API re-exposed manually since AFAIK there isn’t a way to have Rust handle that without using a code generator. (There might be some hackier ways to make this work, or maybe someone with more Rust experience than me knows of something smarter that could happen, but in any case the ergonomics right now are not good for the average developer.) [0] https://github.com/rust-qt/ritual https://github.com/rust-qt/ritual [1] https://doc.qt.io/qt-5/qmessagebox.html#QMessageBox-1 https://doc.qt.io/qt-5/qmessagebox.html#QMessageBox-1 [2] https://github.com/woboq/qmetaobject-rs https://github.com/woboq/qmetaobject-rs [3] https://github.com/mystor/rust-cpp https://github.com/mystor/rust-cpp
oconnor663 6y ago
> I remember trying it out back in 2014 and saw nothing of interest The 1.0 release was in 2015, and there wasn't much industry adoption before that. Today most of the big tech companies are using it for something. Microsoft published a series of articles this year about using Rust internally. > A lot of the main "selling points" of Rust are getting introduced in C++. In the C++ world, Rust's biggest selling point by far is memory safety. The safety story is based on notions of ownership, borrowing, and lifetimes that are built into language itself. Most of the standard library, and many foundational crates like Serde and Rayon, have designed their APIs around these concepts. These things tend to go "all the way down": Every single function or datatype that deals with references defines its lifetime requirements for those references, and every single callsite of one of those functions or variable of one of those types is statically checked to meet those requirements. I wouldn't go so far as to call this an "all or nothing" thing. Languages like TypeScript make it clear that you can get good value out of a strict type system even when much of the ecosystem isn't strict. But there's a lot of value in being on the "all" side of the fence here -- especially for languages with pointers and destructors -- and I think it's unrealistic to expect an established language like C++ to make that many changes. > Also, what is it about Rust that gets automatic top view on HN? Having a new, serious contender in the C/C++ world is exciting! And maybe Rust being more challenging to learn makes people more excited about being "in the club" when they do learn it. On the other hand, all the talk about memory safety seems to make some people kind of...self-righteous?...about the language, which we would all prefer to see less of :p
simias 6y ago
I'm currently rewriting the "industry" application I started 4 years ago in Python into Rust. At the time I wasn't sure if Rust was mature enough to use it for a critical application, and I needed to get started quickly so Python seemed like the right choice. Now that the application has grown to be quite huge I really struggle to maintain the python code, I miss static typing. Big code changes are a pain to validate and regressions always manage to slip in the cracks. Meanwhile I've used Rust for some smaller, less critical components and it Just Works. C-tier perfs and zero crashes in 4 years. I'm definitely optimistic for the future of the language at this point. The community is thriving and the language keeps improving, while not breaking backward compatibility and forcing me to update my code to make use of the latest features.
- heavyset_go 6y ago
  I've found that religiously applying type annotations in Python helps, and using a mypy LSP plugin[1] allows for type checking as I'm writing Python code. [1] https://github.com/tomv564/pyls-mypy https://github.com/tomv564/pyls-mypy
  - simias 6y ago
    I've given it a try but I found it really half-baked. For one thing I don't really believe you can successfully tack a type system as an afterthought onto a dynamic language but beyond that the fact that the default Python implementation effectively completely ignores these annotations make them borderline useless for me. If at the very least I could generate a runtime error on type mismatch that'd be worth it. As they stand I thought that they took a lot of effort to write and maintain for very little practical value.
jug 6y ago
I think contributing to the popularity here is that Rust is interesting to discuss out of an academic perspective due to the niche it has carved out, with the compiler able to see already at compile time whether your code is thread safe with no race conditions, and without memory leaks and buffer overruns. This without support like a garbage collector or a virtual machine overseeing things. OK, it's not bullet proof, but large swathes of issues are prevented that often aren't in other big languages, and you kind of have to go out of your way to shoot yourself in the foot. As for use in the industry, I see it mentioned every now and then and I keep being surprised because I have low expectations of its adoption, but then suddenly there are big things like Dropbox rewriting their synchronization core (Nucleus) in Rust, and Microsoft releasing Rust bindings for their next-gen Windows API (WinRT). So I guess it's still rare in the very large realm of software development, but probably more popular than one may expect for a bit of a fringe language. One that I first thought would remain a proof of concept and point of discussion in computer science circles. I'm happy to be wrong because I think it does solve some long standing problems in certain projects.
- saghm 6y ago
  > the compiler able to see already at compile time whether your code is thread safe with no race conditions Obligatory clarification: the compiler enforces that there are no _data_ races; there can still be other types of race conditions.
  - pjmlp 6y ago
    Between threads. The compiler does nothing to prevent data races over shared memory IPC mechanisms across processes, which happen to be the way everyone that cares about security is turning back to, concurrency + processes.
- qchris 6y ago
  I just wanted to mention that I don't believe memory leaks are technically considered memory unsafe, and so while a leak is generally more difficult to create, it is possible to do in safe Rust vs. something like use-after-free.
adamch 6y ago
We use it for many projects at Cloudflare. My team, Argo Tunnels, uses it for our backend and our end-to-end monitoring/healthchecks.
programmarchy 6y ago
One reason I'm interested in Rust is because it has the best toolchain for compiling to WebAssembly.
leetcrew 6y ago
> I remember trying it out back in 2014 and saw nothing of interest, as a Haskell user. this isn't surprising; it's a very different kind of language. > A lot of the main "selling points" of Rust are getting introduced in C++. kind of true, but also really not. features from rust are indeed being copied to c++, but imo the key difference between the languages is the attitude towards memory safety. memory safety is "opt-in" with c++, while it is "opt-out" in rust. I doubt this will change anytime in the near future.
woah 6y ago
“Lack of practical use in industry” isn’t a PL criticism you usually hear from Haskell users!
_carli__ 6y ago
I guess Rust related stuff is often ranked high at HN (and reddit/programming) for mainly two reasons: 1. It is a very interesting language. Personally I find it fascinating (coming from imperative languages). Some blog posts are really worth the high ranking. 2. It's an enthusiats language. They tend to be emotional on their subject. That's why Rust is indeed overpromoted compared to other languages. People getting their stuff done are often using boring tools like Java, C/C++ or Go and are not hanging around here in language threads very often. Rust is not prevalent in the industry at all. People reporting how it's used by Microsoft and Amazon etc. are not telling lies, but often forget to see the big picture. Compared to C/C++ or Java Rust's usage is tiny. Less than 1%. I'd say even less then 0.01 % worldwide in terms of people using it, lines of code written daily, project budget spend on. But how often are people writing posts "Why we adopted Java" or "How we improved backend performance by 300% using C++"? Rust is kind of vocal, so the overall picture of it's usage is quite distorted. Still, the usage of Rust has been going up the last 5 years. So it is gaining. And it's a great fit for certain tasks.

by li4ick 6y ago

adamnemecek 6y ago

The fact that you can actually ship an app. I've been writing my app (it's an IDE for music http://ngrid.io http://ngrid.io) in Rust after trying it in cpp and swift and it's a joy to use. Haskell is cool and all but every time I tried it, I spent too much tle with package management for example. Also you can't really ship an app in Haskell.

LandR 6y ago
I dont know Haskell, why can't you ship an app in Haskell?
- nine_k 6y ago
  You totally can. I use pandoc regularly (though some would say it's a "utility" and not an "app").
  - adamnemecek 6y ago
    I mean like a desktop app.
    - nine_k 6y ago
      xmonad? :) Frankly, I did nit see people releasing proper desktop apps for some time now :( Electron apps do not count.
diath 6y ago
What is "ship an app" supposed to even mean here? Being able to build a binary for distribution? Both Swift and C++ can do that, and likely Haskell too.
- adamnemecek 6y ago
  I was talking about shipping in haskell. Technically yes, practically few people do it and for good reasons.
dman 6y ago
What are you using for the UI layer?
- adamnemecek 6y ago
  I'm building my own using femtovg https://github.com/femtovg/femtovg https://github.com/femtovg/femtovg
  - auggierose 6y ago
    Well, if you have to do that in order to "actually ship an app" :-D I'll stay with Swift for now.
    - adamnemecek 6y ago
      It depends on your app, but for me, cocoa didn't quite cut it. Given my app uses some shaders.
      - auggierose 6y ago
        You can write Metal shaders and call them from Swift. I'd say that is easier than to write your own UIKit ;-)
    - outworlder 6y ago
      have to? No. https://www.areweguiyet.com/ https://www.areweguiyet.com/
      - auggierose 6y ago
        According to that link, you pretty much have to.
  - outworlder 6y ago
    I am a fan of OpenGL based GUIs. I built my first one before Y2k. There's something nice about crafting UI widgets, with all their behaviors that scratches a particular itch I can't explain. That said, it is really really tough to get all the little behaviors that people rely on. Including all keyboard shortcuts (across all platforms), double/triple clicking words, etc. I guess that this may not matter that much for specialized software (but please focus on the damn textboxes, they are hard to get right). I'm just commenting in case other people decide to follow the same path. Also, for a broader audience: be mindful of accessibility. Usually, this kind of thing doesn't work with screen readers.
offtop5 6y ago
Any screenshots of the application your working on. I seriously love working on music and I'm down to try anything, but I have no idea what your app actually is
- adamnemecek 6y ago
  I'll be shipping soon.
  - scns 6y ago
    Please do a Show HN
    - adamnemecek 6y ago
      I'm definitely planning on doing that.
sunshinerag 6y ago
curious about your experience with Swift? can you share?
- adamnemecek 6y ago
  I think the language is nice however the niceness comes at the cost of performance. Swift has a relatively unique performance in that it's faster than garbage collected languages but slower than C or Rust due to some hidden runtime locks. Another problem is with the package ecosystem. It feels like most of Swift ecosystem is wrappers around Apple APIs. There are also some strange workflow edge cases like the fact that you currently cannot use Metal shaders in Swift Packages. This is due to the fact that Xcode projects are supposed to be ephemeral (not version controlled, but generated when you clone the package). However if you want to compile Metal, you have to add some compiler options. As a result, every time you add a dependency, you have to regenerate the XCode project file, you have to fuck with your XCode project to add the compiler options. Ironically, you can use Metal in Rust crates just fine. Rust is also truly cross-platform. Windows and Linux have first class support. To summarize my argument, Swift feels like daddy Apple is telling me what is best for me which may or may not be true. Rust feels like true empowerment. If there is something that doesn't suit me for whatever reason, there is generally a way of working around it. I guess it depends on what you are doing. Swift is OK for iOS/macOS development but other than that Rust is more advanced. Rust macros are really powerful, things that need to be added explicitly to the Swift compiler can be implemented as Rust macros.
  - pjmlp 6y ago
    > Swift has a relatively unique performance in that it's faster than garbage collected languages but slower than C or Rust due to some hidden runtime locks. Yep blazing fast indeed. /s https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages

eloff 6y ago

Programming languages can be a very personal thing. But I will offer my perspective having used C++ extensively (both modern and awful), Go, Rust, a little Haskell and some 20 other languages in my two decades career. Rust is one of the nicest languages out there. Very well thought out, elegant, full low-level control for real systems programming (sorry Go!) AWS uses it a lot, Microsoft is starting to use it. Go, or even Python is better if you just want to make a backend API for a (web) app. You'll be more productive with it over Rust because you have a GC and can ignore the whole ownership issue for the most part. Python for very small teams likely to stay small for a long time, Go otherwise. C++ has come a long way, but it's still hairy and loaded with footguns and baggage. I would only use it these days if I needed to use a big C++ library (like a game engine). I am no longer willing to use Haskell, PHP, Perl, Java or JVM languages, .NET or anything else that's not Go, Rust or Python. With the same caveat as C++ above. I pass over job postings that require them. That's not saying those languages are bad, just that in my personal opinion there are better tools out there, and if I'm going to work with it day in and day out, it had better be in something at the top of my list - because life is short.

ragnese 6y ago
Have you played with OCaml recently (last year or two)? Wondering what your opinion is on it, especially in relation to Haskell and Rust.
- adamnemecek 6y ago
  Speed, developer ergonomics and community. It depends what you are building I guess but for example audio processing or graphics is still impossible in either of those.
aprdm 6y ago
Saying AWS uses it a lot is very misleading. Same for Microsoft. I won’t dispute that there are some teams using it but the majority of new projects aren’t in rust and there’s no trend for it.
- 6y ago

steveklabnik 6y ago

Rust in 2014 and Rust today are very different; specifically, 2014 to 2015 was a very tumultuous time. 2015 saw the release of Rust 1.0, and so a lot of stuff happened to get things ready for that, including some very large changes to the entire standard library, a removal of most of the runtime... all sorts of stuff.

voxl 6y ago

If you're a genuine Haskell user then it shouldn't take more than a second to realize that true borrow checking is not the same as C++ pointer types, and that Cargo is thee best dependency manager. Although, being a Haskell user, you might suffer stockholm syndrome in regards to the dependency hell that is cabal or stack.

deleted 6y ago
[deleted]
higerordermap 6y ago
Noice troll.

pjmlp 6y ago

It depends pretty much on the domain. Just think that it took C++ 40 years to reach where it is now and still there are domains where C rules, a systems language that people forget is only 10 years younger than COBOL.

gameswithgo 6y ago

>Just how prevalent is Rust in the industry? It has been picking up a lot lately, Apple, Amazon, and Microsoft are all showing some adoption, for instance. > I remember trying it out back in 2014 and saw nothing of interest, as a Haskell user The interest for a Haskell user would be that you have some of the functional programming features you like (such as discriminated unions!) with C/C++ levels of runtime performance/efficiency. For someone who has no need for that level of low level control/performance, Rust is generally not a language you want to use, for sure. > A lot of the main "selling points" of Rust are getting introduced in C++ It is true that you could, with sufficient coding standards and linters, get something approximately like Rust by using C++, where the linter disallows any non safe pointers, any use of null or nullable types without wrapping it in a variant, disallowing all cases of undefined behavior, and so on. However you would have something a lot less pleasant to use than using Rust in the first place, build times would probably end up worse with those thing enforced as a build step, and setting up such an environment would be non trivial and you basically are just building rust out of C++, twine and gum, so why not just use Rust?

jcelerier 6y ago
> and you basically are just building rust out of C++, twine and gum, so why not just use Rust? my 100% honest answer: Rust does not have Qt
- pizza234 6y ago
  As a non-Qt developer: which are the limitations of using Qt bindings?
  - heavyset_go 6y ago
    They're incomplete and the last time I looked, you needed to create Qt bindings for Rust using some code generator.
  - csnover 6y ago
    Rust doesn’t support object inheritance (only traits). It also doesn’t have function overloads or default arguments. Qt relies heavily on all of these C++ features; inheritance is fundamental to how Qt works (for example, it is impossible to respond to mouse/keyboard events without subclassing to override virtual methods), and function overloads with default arguments are used everywhere. As a result, it’s a struggle to shoehorn this object model into Rust. rust-qt[0] doesn’t support inheritance at all, so you can only connect to things in Qt which accept callbacks using slots. It requires `'static` lifetime on those callbacks, so as far as I can tell you are also forced to use `Rc`s whenever you are doing something with a rust-qt object even if you should be able to use a plain reference. The code is auto-generated, so all APIs are `unsafe`, and no function overloads means names are gross because the function signatures must be expressed in the function name (e.g. the `QMessageBox` constructor[1] becomes `QMessageBox::from_icon2_q_string_q_flags_standard_button_q_widget`). This could be improved by using `Option`s for arguments with defaults, but right now this is what it looks like. qmetaobject-rs[2] has some support for inheritance but as far as I can tell it’s limited to a couple of base types only. It’s also designed around using QML, so it doesn’t actually expose most of the Qt API. As such I don’t have too much experience with it. I’m unaware of any other usable Rust Qt bindings right now. I currently make things work by using rust-cpp[3] to create C++ subclasses and smuggle events, but this sucks because it also means the objects on the Rust side need to have the Qt API re-exposed manually since AFAIK there isn’t a way to have Rust handle that without using a code generator. (There might be some hackier ways to make this work, or maybe someone with more Rust experience than me knows of something smarter that could happen, but in any case the ergonomics right now are not good for the average developer.) [0] https://github.com/rust-qt/ritual https://github.com/rust-qt/ritual [1] https://doc.qt.io/qt-5/qmessagebox.html#QMessageBox-1 https://doc.qt.io/qt-5/qmessagebox.html#QMessageBox-1 [2] https://github.com/woboq/qmetaobject-rs https://github.com/woboq/qmetaobject-rs [3] https://github.com/mystor/rust-cpp https://github.com/mystor/rust-cpp

oconnor663 6y ago

> I remember trying it out back in 2014 and saw nothing of interest The 1.0 release was in 2015, and there wasn't much industry adoption before that. Today most of the big tech companies are using it for something. Microsoft published a series of articles this year about using Rust internally. > A lot of the main "selling points" of Rust are getting introduced in C++. In the C++ world, Rust's biggest selling point by far is memory safety. The safety story is based on notions of ownership, borrowing, and lifetimes that are built into language itself. Most of the standard library, and many foundational crates like Serde and Rayon, have designed their APIs around these concepts. These things tend to go "all the way down": Every single function or datatype that deals with references defines its lifetime requirements for those references, and every single callsite of one of those functions or variable of one of those types is statically checked to meet those requirements. I wouldn't go so far as to call this an "all or nothing" thing. Languages like TypeScript make it clear that you can get good value out of a strict type system even when much of the ecosystem isn't strict. But there's a lot of value in being on the "all" side of the fence here -- especially for languages with pointers and destructors -- and I think it's unrealistic to expect an established language like C++ to make that many changes. > Also, what is it about Rust that gets automatic top view on HN? Having a new, serious contender in the C/C++ world is exciting! And maybe Rust being more challenging to learn makes people more excited about being "in the club" when they do learn it. On the other hand, all the talk about memory safety seems to make some people kind of...self-righteous?...about the language, which we would all prefer to see less of :p

simias 6y ago

I'm currently rewriting the "industry" application I started 4 years ago in Python into Rust. At the time I wasn't sure if Rust was mature enough to use it for a critical application, and I needed to get started quickly so Python seemed like the right choice. Now that the application has grown to be quite huge I really struggle to maintain the python code, I miss static typing. Big code changes are a pain to validate and regressions always manage to slip in the cracks. Meanwhile I've used Rust for some smaller, less critical components and it Just Works. C-tier perfs and zero crashes in 4 years. I'm definitely optimistic for the future of the language at this point. The community is thriving and the language keeps improving, while not breaking backward compatibility and forcing me to update my code to make use of the latest features.

heavyset_go 6y ago
I've found that religiously applying type annotations in Python helps, and using a mypy LSP plugin[1] allows for type checking as I'm writing Python code. [1] https://github.com/tomv564/pyls-mypy https://github.com/tomv564/pyls-mypy
- simias 6y ago
  I've given it a try but I found it really half-baked. For one thing I don't really believe you can successfully tack a type system as an afterthought onto a dynamic language but beyond that the fact that the default Python implementation effectively completely ignores these annotations make them borderline useless for me. If at the very least I could generate a runtime error on type mismatch that'd be worth it. As they stand I thought that they took a lot of effort to write and maintain for very little practical value.

jug 6y ago

I think contributing to the popularity here is that Rust is interesting to discuss out of an academic perspective due to the niche it has carved out, with the compiler able to see already at compile time whether your code is thread safe with no race conditions, and without memory leaks and buffer overruns. This without support like a garbage collector or a virtual machine overseeing things. OK, it's not bullet proof, but large swathes of issues are prevented that often aren't in other big languages, and you kind of have to go out of your way to shoot yourself in the foot. As for use in the industry, I see it mentioned every now and then and I keep being surprised because I have low expectations of its adoption, but then suddenly there are big things like Dropbox rewriting their synchronization core (Nucleus) in Rust, and Microsoft releasing Rust bindings for their next-gen Windows API (WinRT). So I guess it's still rare in the very large realm of software development, but probably more popular than one may expect for a bit of a fringe language. One that I first thought would remain a proof of concept and point of discussion in computer science circles. I'm happy to be wrong because I think it does solve some long standing problems in certain projects.

saghm 6y ago
> the compiler able to see already at compile time whether your code is thread safe with no race conditions Obligatory clarification: the compiler enforces that there are no _data_ races; there can still be other types of race conditions.
- pjmlp 6y ago
  Between threads. The compiler does nothing to prevent data races over shared memory IPC mechanisms across processes, which happen to be the way everyone that cares about security is turning back to, concurrency + processes.
qchris 6y ago
I just wanted to mention that I don't believe memory leaks are technically considered memory unsafe, and so while a leak is generally more difficult to create, it is possible to do in safe Rust vs. something like use-after-free.

adamch 6y ago

We use it for many projects at Cloudflare. My team, Argo Tunnels, uses it for our backend and our end-to-end monitoring/healthchecks.

programmarchy 6y ago

One reason I'm interested in Rust is because it has the best toolchain for compiling to WebAssembly.

leetcrew 6y ago

> I remember trying it out back in 2014 and saw nothing of interest, as a Haskell user. this isn't surprising; it's a very different kind of language. > A lot of the main "selling points" of Rust are getting introduced in C++. kind of true, but also really not. features from rust are indeed being copied to c++, but imo the key difference between the languages is the attitude towards memory safety. memory safety is "opt-in" with c++, while it is "opt-out" in rust. I doubt this will change anytime in the near future.

woah 6y ago

“Lack of practical use in industry” isn’t a PL criticism you usually hear from Haskell users!

_carli__ 6y ago

I guess Rust related stuff is often ranked high at HN (and reddit/programming) for mainly two reasons: 1. It is a very interesting language. Personally I find it fascinating (coming from imperative languages). Some blog posts are really worth the high ranking. 2. It's an enthusiats language. They tend to be emotional on their subject. That's why Rust is indeed overpromoted compared to other languages. People getting their stuff done are often using boring tools like Java, C/C++ or Go and are not hanging around here in language threads very often. Rust is not prevalent in the industry at all. People reporting how it's used by Microsoft and Amazon etc. are not telling lies, but often forget to see the big picture. Compared to C/C++ or Java Rust's usage is tiny. Less than 1%. I'd say even less then 0.01 % worldwide in terms of people using it, lines of code written daily, project budget spend on. But how often are people writing posts "Why we adopted Java" or "How we improved backend performance by 300% using C++"? Rust is kind of vocal, so the overall picture of it's usage is quite distorted. Still, the usage of Rust has been going up the last 5 years. So it is gaining. And it's a great fit for certain tasks.