5 ms·

My journey with Rust in 2017 — The good, the bad, the weird

85 points by fschutt 9y ago

greenhouse_gas 9y ago
1. Why are you're learning a language at the same time you're trying to launch an MVP? And a fairly involved language such as rust. 2. You're complaining about windows32 API being slow, but blaming it on .NET ("I don’t know if it was attributed to Windows or the application programmers, but I attributed Windows’ built-in functions with being slow and having shitty PDF output, which is why I refused to use anything related to Win32 or .NET"). Windows API is C (or internally C++). 3. Is display a bottleneck? I never developed GIS applications, but your display is 2D and doesn't have to be real-time. I would assume that the "back end" of the program is doing most of the calculations, and the display just outputs it (not like, say, a 3D game where the rendering engine does a significant chunk of its own work).
- pjmlp 9y ago
  I did not get that as well. Windows does not have PDF generation, its support has been recently introduced in Windows 10. So most likely it was a third party library. EDIT: It was actually introduced in Windows 10, not 8.
  - MrBuddyCasino 9y ago
    > Windows does not have PDF generation, its support has been recently introduced in Windows 8. does not compute
    - pjmlp 9y ago
      OP was most likely using Windows 7 or earlier, from what I could understand.
  - pjc50 9y ago
    Where's the Win8 PDF generation? I can't find it on MSDN. Unless we're talking about GDI print -> target "print to PDF"?
    - pjmlp 9y ago
      I was wrong. Actually it was only introduced in Windows 10. https://docs.microsoft.com/en-us/uwp/api/windows.data.pdf https://docs.microsoft.com/en-us/uwp/api/windows.data.pdf
- hobofan 9y ago
  > 1. Why are you're learning a language at the same time you're trying to launch an MVP? And a fairly involved language such as rust. Back when we decided to build Leaf[0] we were in a situation where we needed a language with the characteristics similar to the ones of C, C++, Rust (embeddable, no runtime, etc.). Before starting development on Leaf we didn't have any extensive experience in any of those languages, and I still think that Rust was the right choice for the project. I'd guess that the requirements of the MVP were similar. Since he also noted that it's his first time programming full-time, he had to learn _some_ language. Sure, it's not optimal to learn a core competency of your business while founding it, but I can also tell you from personal experience that sometimes that's still a better choice than the alternatives. > And a fairly involved language such as rust. I'd say Rust is only as involved as your requirements of it: - You don't have to deal with raw pointers? -> No need to learn `unsafe` - You're not particularly worried about extreme performance/memory usage at first? -> Clone now, learn lifetimes later [0]: https://github.com/autumnai/leaf https://github.com/autumnai/leaf
- fschutt 9y ago
  1. I knew that I had a lots of time. From a business perspective, this doesn't make perfect sense, I know. I knew C++ (sort of) and was looking for a similar language. Learning Rust took me roughly three weeks (coming from C++), it is not as complex as you think. I think the time saved hunting down null pointers has amortized that investment greatly. 2. Again, I didn't know at that time if that was the fault of Windows. All that I saw was an application that was extremely slow, written in either C++ (with Win32) or .NET (both of which are possible). Second, the application had very shitty PDF output (ex. a shape with CMYK was "emulated" by four shapes drawn on top of each other, one for black, one for magenta, etc. - lead to a completely bloated PDF). I suspected that it was the fault of the framework they were using and I didn't want to end up in a similar situation. 3. Display is actually the #1 bottleneck. You have to understand that in a real map needs to draw roughly 10000 lines, fonts, and symbols. The old program (which I had to work with), did this using Win32 drawing routines. Every time you zoom in / out, it could take 1 - 5 seconds (if lots of things were on the screen). In OpenGL, I can do it in a sub-millisecond time (using this technique - https://blog.mapbox.com/drawing-antialiased-lines-with-opengl-8766f34192dc https://blog.mapbox.com/drawing-antialiased-lines-with-openg... paired with primitive restarting in OpenGL (https://www.khronos.org/opengl/wiki/Vertex_Rendering#Primitive_Restart https://www.khronos.org/opengl/wiki/Vertex_Rendering#Primiti...). ArcGIS, for example, has DirectX acceleration, QGIS uses OpenGL. This is simply a huge annoyance when trying to work with the program.
ToJans 9y ago
I am wondering why the author didn't opt for a language/platform with a mature PDF and GUI library? If I read the article correctly, it would have halved his development time...
- pjc50 9y ago
  Which one would that be, then?
  - zokier 9y ago
    Java? If it got one thing going for it, it is maturity.
    - pjmlp 9y ago
      Yep. https://itextpdf.com https://itextpdf.com
    - INTPnerd 9y ago
      Yeah, I would have recommended Kotlin. Runs on the JVM, so benefits from the matureness of Java, but is a more modern, and better designed language. A reason to choose Rust over this is if you actually have reason to believe you will need some extra bare metal performance over a garbage collected language, or you will need multiple threads. From what I can tell, the author did not really have good reason to believe any of those things, they just wanted to stay clear of whatever was wrong with the software they used at work, which a JMV based solution should have done. I am glad it worked out for them though, and knowing Rust is a good asset to fall back on, whereas learning Kotlin should be pretty easy for them. Even so, I like that with Kotlin you can take advantage of the most mature IDE ever made InjelliJ IDEA. I think they would have completed their project faster with this. That being said, the program they ended up with sounds very fast and it probably is faster than if they wrote it in Kotlin. It was the "right" move in the sense that it seems to have worked out well for them. Was it the "best" move? Most moves are not, and they don't need to be. Whether or not Kotlin would have been better probably depends on if it was better to finish faster or have an even more blazingly fast program at the end. I don't think a Kotlin version would have been slow or had any of that wait for 30 seconds nonsense, but it probably would have been a little slower. Would that a "little slower" have mattered? It depends on who is using the program and how they are using it. It always feels nicer to have a program that feels like instantly responds to your every whim.
nemothekid 9y ago
I started a reading the article expecting a critique of Rust, and I'm halfway through and it feels like I'm reading 2014-esque React philosophies on UI management.
- fschutt 9y ago
  Well, as I said in the first sentence, the article is not only about Rust. I didn't want to write the next "memory safety is great" post, there are enough of those. I just wanted to present interesting problems and pitfalls I came across in 2017 and how I solved them using Rust.
ohazi 9y ago
Software taking half an hour to generate a PDF probably has nothing to do with the performance differences between bare metal and garbage collected languages.
- fschutt 9y ago
  Very probably, but I feared that it was the fault of some framework they were using, so I wanted to stay clear of whatever they were doing. My library can export even huge PDFs in less than 500ms - but I have heard this "half an hour for a PDF" from other applications, too. I have no idea what these frameworks are doing. They seem to be accessing the disk a lot, like a lot. I noticed that the time for exporting a PDF went down (in my old company) when we switched to Macs that had an SSD. In my library, this wouldn't make much of a difference, since the document is first generated in-memory and then written out to the disk with buffered IO. Users usually just blame their computer ("it's slow, let's grab a coffee"), but to me this performance is unacceptable.
5ourpuss 9y ago
I often dream about doing what the author is currently doing: Tooling around, writing software in a language I want to learn full-time. If I could get a patreon going... ANYWHO, I didn't come here to malign the author. I came here to ask a question. ( For clarity, I'm an experience dev, computer science degree, been a developer full time for 6 years out of college and two years while in college ) I see a lot of discussion in here about developing GUIs in Rust. Writing native GUIs with Rust sounds awesome to me, and I'm drawn to it for the obvious benefits. One of the things I want to do in 2018 is learn a new programming language. Last year I learned groovy, which is terrible, and Elixir, which is great and I highly recommend it. I'm currently tore between three languages: Rust, Reasonml, and Scala They have the following requirements: - EXCELLENT type system - Functional - Productive - Portable My goal is to write GUI applications that help me design my board games. * Scala Scala has a nice type system, runs on the JVM so we get all of that sweet sweet Java interop, is functional with a mutable escape hatch, and is a "boring" language that is used extensively. Additionally, the story for writing GUI applications for Java isn't as slick as web technologies. Listen, I'm a millennial. We don't believe in anything. I don't mind opening up a web browser to interact with a graphical user interface, so languages with a better web technologies story is more attractive to me. Scala is not much of a departure from my previous languages, so I fear I wouldn't learn much. I already have Elixir for writing restful APIs and GoLang/Hugo for static sites, so Scala over-laps with these use cases making it less productive. * Reasonml Reasonml is a newer language from Facebook that compiles to the OCaml syntax tree, and then uses the OCaml compiler to produce the machine code. Currently, Reason's only target is Javascript, but the community has already written a bunch of back-ends to have reason output to other formats. There is a Facebook-developed React library called ReactReason, so targeting web technologies is Reasons JAM. A lot of Messenger.com has already been re-written using reason. Reason has a language server implementation that hooks up to my Emacs config quite nicely, so I'm efficient in my development environment. Reason uses OCaml's type system, which has 25 years of development and is extremely effective. Reason has a compiler. After working with dynamic languages for so long, I have learned to love my compiler. Reason is designed for productive Javascript interop, so I have access to the gigantic nodejs ecosystem. The humans who are d Reason ticks a LOT of my boxes, but it has some warts: - Not a perfect story for async programming. - Does not have a swagger-codegen back-end for stubbing out types based on my API docs. - Special little snowflake language with a small community - Really only good for front-end development - Is the type system and other language primitives THAT MUCH BETTER than Typescript + ImmutableJS? * Rust Rust is the language I WANT to learn and use, but I am hesitant for a number of reasons. I want to learn rust because: - Aside from a teeny bit of C / C++ usage in college, I've not written in a low level language that requires me to think about garbage collection and I think it would be a useful exercise. - It's extremely fast. - It has some excellent concepts, like the borrow checker, that will expose me to new ways of programming. - Will be nice to have a low-level language in my tool belt. - Quickly growing community, a good opportunity to contribute FOSS. I'm hesitant because: - I'm concerned it doesn't fit my use case of writing GUIs. - I want it to be a PRODUCTIVE langauge, and MAKE STUFF, not writing glue to get the stuff I want to work.
Sammi 9y ago
He didn't link to the product he's building. So I looked up the company he's listing himself as working at at found this: http://maps4print.com/ http://maps4print.com/

85 points by fschutt 9y ago

1. Why are you're learning a language at the same time you're trying to launch an MVP? And a fairly involved language such as rust. 2. You're complaining about windows32 API being slow, but blaming it on .NET ("I don’t know if it was attributed to Windows or the application programmers, but I attributed Windows’ built-in functions with being slow and having shitty PDF output, which is why I refused to use anything related to Win32 or .NET"). Windows API is C (or internally C++). 3. Is display a bottleneck? I never developed GIS applications, but your display is 2D and doesn't have to be real-time. I would assume that the "back end" of the program is doing most of the calculations, and the display just outputs it (not like, say, a 3D game where the rendering engine does a significant chunk of its own work).

pjmlp 9y ago
I did not get that as well. Windows does not have PDF generation, its support has been recently introduced in Windows 10. So most likely it was a third party library. EDIT: It was actually introduced in Windows 10, not 8.
- MrBuddyCasino 9y ago
  > Windows does not have PDF generation, its support has been recently introduced in Windows 8. does not compute
  - pjmlp 9y ago
    OP was most likely using Windows 7 or earlier, from what I could understand.
- pjc50 9y ago
  Where's the Win8 PDF generation? I can't find it on MSDN. Unless we're talking about GDI print -> target "print to PDF"?
  - pjmlp 9y ago
    I was wrong. Actually it was only introduced in Windows 10. https://docs.microsoft.com/en-us/uwp/api/windows.data.pdf https://docs.microsoft.com/en-us/uwp/api/windows.data.pdf
hobofan 9y ago
> 1. Why are you're learning a language at the same time you're trying to launch an MVP? And a fairly involved language such as rust. Back when we decided to build Leaf[0] we were in a situation where we needed a language with the characteristics similar to the ones of C, C++, Rust (embeddable, no runtime, etc.). Before starting development on Leaf we didn't have any extensive experience in any of those languages, and I still think that Rust was the right choice for the project. I'd guess that the requirements of the MVP were similar. Since he also noted that it's his first time programming full-time, he had to learn _some_ language. Sure, it's not optimal to learn a core competency of your business while founding it, but I can also tell you from personal experience that sometimes that's still a better choice than the alternatives. > And a fairly involved language such as rust. I'd say Rust is only as involved as your requirements of it: - You don't have to deal with raw pointers? -> No need to learn `unsafe` - You're not particularly worried about extreme performance/memory usage at first? -> Clone now, learn lifetimes later [0]: https://github.com/autumnai/leaf https://github.com/autumnai/leaf
fschutt 9y ago
1. I knew that I had a lots of time. From a business perspective, this doesn't make perfect sense, I know. I knew C++ (sort of) and was looking for a similar language. Learning Rust took me roughly three weeks (coming from C++), it is not as complex as you think. I think the time saved hunting down null pointers has amortized that investment greatly. 2. Again, I didn't know at that time if that was the fault of Windows. All that I saw was an application that was extremely slow, written in either C++ (with Win32) or .NET (both of which are possible). Second, the application had very shitty PDF output (ex. a shape with CMYK was "emulated" by four shapes drawn on top of each other, one for black, one for magenta, etc. - lead to a completely bloated PDF). I suspected that it was the fault of the framework they were using and I didn't want to end up in a similar situation. 3. Display is actually the #1 bottleneck. You have to understand that in a real map needs to draw roughly 10000 lines, fonts, and symbols. The old program (which I had to work with), did this using Win32 drawing routines. Every time you zoom in / out, it could take 1 - 5 seconds (if lots of things were on the screen). In OpenGL, I can do it in a sub-millisecond time (using this technique - https://blog.mapbox.com/drawing-antialiased-lines-with-opengl-8766f34192dc https://blog.mapbox.com/drawing-antialiased-lines-with-openg... paired with primitive restarting in OpenGL (https://www.khronos.org/opengl/wiki/Vertex_Rendering#Primitive_Restart https://www.khronos.org/opengl/wiki/Vertex_Rendering#Primiti...). ArcGIS, for example, has DirectX acceleration, QGIS uses OpenGL. This is simply a huge annoyance when trying to work with the program.

ToJans 9y ago

I am wondering why the author didn't opt for a language/platform with a mature PDF and GUI library? If I read the article correctly, it would have halved his development time...

pjc50 9y ago
Which one would that be, then?
- zokier 9y ago
  Java? If it got one thing going for it, it is maturity.
  - pjmlp 9y ago
    Yep. https://itextpdf.com https://itextpdf.com
  - INTPnerd 9y ago
    Yeah, I would have recommended Kotlin. Runs on the JVM, so benefits from the matureness of Java, but is a more modern, and better designed language. A reason to choose Rust over this is if you actually have reason to believe you will need some extra bare metal performance over a garbage collected language, or you will need multiple threads. From what I can tell, the author did not really have good reason to believe any of those things, they just wanted to stay clear of whatever was wrong with the software they used at work, which a JMV based solution should have done. I am glad it worked out for them though, and knowing Rust is a good asset to fall back on, whereas learning Kotlin should be pretty easy for them. Even so, I like that with Kotlin you can take advantage of the most mature IDE ever made InjelliJ IDEA. I think they would have completed their project faster with this. That being said, the program they ended up with sounds very fast and it probably is faster than if they wrote it in Kotlin. It was the "right" move in the sense that it seems to have worked out well for them. Was it the "best" move? Most moves are not, and they don't need to be. Whether or not Kotlin would have been better probably depends on if it was better to finish faster or have an even more blazingly fast program at the end. I don't think a Kotlin version would have been slow or had any of that wait for 30 seconds nonsense, but it probably would have been a little slower. Would that a "little slower" have mattered? It depends on who is using the program and how they are using it. It always feels nicer to have a program that feels like instantly responds to your every whim.

nemothekid 9y ago

I started a reading the article expecting a critique of Rust, and I'm halfway through and it feels like I'm reading 2014-esque React philosophies on UI management.

fschutt 9y ago
Well, as I said in the first sentence, the article is not only about Rust. I didn't want to write the next "memory safety is great" post, there are enough of those. I just wanted to present interesting problems and pitfalls I came across in 2017 and how I solved them using Rust.

ohazi 9y ago

Software taking half an hour to generate a PDF probably has nothing to do with the performance differences between bare metal and garbage collected languages.

fschutt 9y ago
Very probably, but I feared that it was the fault of some framework they were using, so I wanted to stay clear of whatever they were doing. My library can export even huge PDFs in less than 500ms - but I have heard this "half an hour for a PDF" from other applications, too. I have no idea what these frameworks are doing. They seem to be accessing the disk a lot, like a lot. I noticed that the time for exporting a PDF went down (in my old company) when we switched to Macs that had an SSD. In my library, this wouldn't make much of a difference, since the document is first generated in-memory and then written out to the disk with buffered IO. Users usually just blame their computer ("it's slow, let's grab a coffee"), but to me this performance is unacceptable.

5ourpuss 9y ago

I often dream about doing what the author is currently doing: Tooling around, writing software in a language I want to learn full-time. If I could get a patreon going... ANYWHO, I didn't come here to malign the author. I came here to ask a question. ( For clarity, I'm an experience dev, computer science degree, been a developer full time for 6 years out of college and two years while in college ) I see a lot of discussion in here about developing GUIs in Rust. Writing native GUIs with Rust sounds awesome to me, and I'm drawn to it for the obvious benefits. One of the things I want to do in 2018 is learn a new programming language. Last year I learned groovy, which is terrible, and Elixir, which is great and I highly recommend it. I'm currently tore between three languages: Rust, Reasonml, and Scala They have the following requirements: - EXCELLENT type system - Functional - Productive - Portable My goal is to write GUI applications that help me design my board games. * Scala Scala has a nice type system, runs on the JVM so we get all of that sweet sweet Java interop, is functional with a mutable escape hatch, and is a "boring" language that is used extensively. Additionally, the story for writing GUI applications for Java isn't as slick as web technologies. Listen, I'm a millennial. We don't believe in anything. I don't mind opening up a web browser to interact with a graphical user interface, so languages with a better web technologies story is more attractive to me. Scala is not much of a departure from my previous languages, so I fear I wouldn't learn much. I already have Elixir for writing restful APIs and GoLang/Hugo for static sites, so Scala over-laps with these use cases making it less productive. * Reasonml Reasonml is a newer language from Facebook that compiles to the OCaml syntax tree, and then uses the OCaml compiler to produce the machine code. Currently, Reason's only target is Javascript, but the community has already written a bunch of back-ends to have reason output to other formats. There is a Facebook-developed React library called ReactReason, so targeting web technologies is Reasons JAM. A lot of Messenger.com has already been re-written using reason. Reason has a language server implementation that hooks up to my Emacs config quite nicely, so I'm efficient in my development environment. Reason uses OCaml's type system, which has 25 years of development and is extremely effective. Reason has a compiler. After working with dynamic languages for so long, I have learned to love my compiler. Reason is designed for productive Javascript interop, so I have access to the gigantic nodejs ecosystem. The humans who are d Reason ticks a LOT of my boxes, but it has some warts: - Not a perfect story for async programming. - Does not have a swagger-codegen back-end for stubbing out types based on my API docs. - Special little snowflake language with a small community - Really only good for front-end development - Is the type system and other language primitives THAT MUCH BETTER than Typescript + ImmutableJS? * Rust Rust is the language I WANT to learn and use, but I am hesitant for a number of reasons. I want to learn rust because: - Aside from a teeny bit of C / C++ usage in college, I've not written in a low level language that requires me to think about garbage collection and I think it would be a useful exercise. - It's extremely fast. - It has some excellent concepts, like the borrow checker, that will expose me to new ways of programming. - Will be nice to have a low-level language in my tool belt. - Quickly growing community, a good opportunity to contribute FOSS. I'm hesitant because: - I'm concerned it doesn't fit my use case of writing GUIs. - I want it to be a PRODUCTIVE langauge, and MAKE STUFF, not writing glue to get the stuff I want to work.

Sammi 9y ago

He didn't link to the product he's building. So I looked up the company he's listing himself as working at at found this: http://maps4print.com/ http://maps4print.com/