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...
Which one would that be, then?
My journey with Rust in 2017 — The good, the bad, the weird
11–20 of 27 posts
Re: My journey with Rust in 2017 — The good, the bad, the weird
#121. 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 re…
> 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
Re: My journey with Rust in 2017 — The good, the bad, the weird
#13Re: My journey with Rust in 2017 — The good, the bad, the weird
#14Earlier quoted context omitted.
Which one would that be, then?
Java? If it got one thing going for it, it is maturity.
Re: My journey with Rust in 2017 — The good, the bad, the weird
#15I 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...
Which one would that be, then?
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.
Re: My journey with Rust in 2017 — The good, the bad, the weird
#161. 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 re…
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.
Re: My journey with Rust in 2017 — The good, the bad, the weird
#17Software 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.
Re: My journey with Rust in 2017 — The good, the bad, the weird
#18Earlier quoted context omitted.
Which one would that be, then?
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?
Re: My journey with Rust in 2017 — The good, the bad, the weird
#19I 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.
Re: My journey with Rust in 2017 — The good, the bad, the weird
#20I 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...
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.