My journey with Rust in 2017 — The good, the bad, the weird(medium.com)
medium.com
My journey with Rust in 2017 — The good, the bad, the weird
https://medium.com/@fschutt/my-journey-with-rust-in-2017-the-good-the-bad-the-weird-f07aa918f4f8
26 comments
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.
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.
Where's the Win8 PDF generation? I can't find it on MSDN. Unless we're talking about GDI print -> target "print to PDF"?
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
> Windows does not have PDF generation, its support has been recently introduced in Windows 8.
does not compute
does not compute
OP was most likely using Windows 7 or earlier, from what I could understand.
> 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
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
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-openg... paired with primitive restarting in OpenGL (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.
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-openg... paired with primitive restarting in OpenGL (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.
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.
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.
Users usually just blame their computer ("it's slow, let's grab a coffee"), but to me this performance is unacceptable.
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...
If I read the article correctly, it would have halved his development time...
Which one would that be, then?
C++. You could use Qt and there are probably a bazillion PDF generation libraries - it's not that hard to make your own really depending on what you need to output.
Well, I expressed my opinions on C++ libraries in the first few paragraphs. None of the C++ libraries I looked at support PDF layers for example (and as a graphic designer, you need that when working with maps, as maps are separated into layers).
QTPDF (used in QGIS) supports it, but the output quality is sub-par when working with Illustrator, at least in my experience. This could be a bug in QGIS, yes. But I didn't want to invest time into something that would probably fail (if the QGIS team failed using it, I would probably do so, too).
QTPDF (used in QGIS) supports it, but the output quality is sub-par when working with Illustrator, at least in my experience. This could be a bug in QGIS, yes. But I didn't want to invest time into something that would probably fail (if the QGIS team failed using it, I would probably do so, too).
Java? If it got one thing going for it, it is maturity.
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.
Any browser. The article has no detail but I suspect that doing it all with a web stack, or even just PDF output with wkhtmltopdf (or a similar solution) would be much quicker than writing a PDF generator from scratch.
The concern was quality, too. Yes, I thought about Electron, hell I even made a prototype for that. But in the end quality counts (to me), not speed of development. I knew that I had lots of time on my hands (no investors or anything, just my own money).
I didn't have anything to lose. So if you have the chance to make it perfect (versus taking some off-the-shelf tool and possibly ending up with a PDF that isn't quite what you want), would you risk it?
I didn't have anything to lose. So if you have the chance to make it perfect (versus taking some off-the-shelf tool and possibly ending up with a PDF that isn't quite what you want), would you risk it?
Self financed, quality before speed of development, no investors that need to be impressed. Awesome, more people should do that!
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.
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.
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/
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.
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.
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.
I did a bit of Scala in a previous job. I'm not sure i'd call it boring. Not because it's exciting - because it's infuriating. Way too many features, way too much overthinking, way too many clever-dicks in the community. If you want to learn an excellently-typed, functionally-inflected, productive, portable language on the JVM, i'd look at Kotlin. It's like the 20% of Scala that gives you 80% of the power.
Rust is pretty great. I came to Rust from a 95% Java background, and picked it up fairly quickly. I wouldn't say i've mastered it, but i can get things done. I have no idea what it's like for writing GUI apps, though.
I did a bit of Scala in a previous job. I'm not sure i'd call it boring. Not because it's exciting - because it's infuriating. Way too many features, way too much overthinking, way too many clever-dicks in the community. If you want to learn an excellently-typed, functionally-inflected, productive, portable language on the JVM, i'd look at Kotlin. It's like the 20% of Scala that gives you 80% of the power.
Rust is pretty great. I came to Rust from a 95% Java background, and picked it up fairly quickly. I wouldn't say i've mastered it, but i can get things done. I have no idea what it's like for writing GUI apps, though.
My impression of Scala is that it has no taste, design, direction, or style. It's just a huge pot of poorly integrated features. It's like PHP 4 in this regard.
I'll take a language with some resemblance of a coherent design like e.g. Kotlin any day over it.
I'll take a language with some resemblance of a coherent design like e.g. Kotlin any day over it.
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).