
My journey with Rust in 2017 — The good, the bad, the weird - fschutt
https://medium.com/@fschutt/my-journey-with-rust-in-2017-the-good-the-bad-the-weird-f07aa918f4f8
======
greenhouse_gas
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
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.

~~~
pjc50
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
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)

------
ohazi
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
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.

------
ToJans
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
Which one would that be, then?

~~~
zokier
Java? If it got one thing going for it, it is maturity.

~~~
INTPnerd
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
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
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.

------
Sammi
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/)

------
5ourpuss
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.

~~~
twic
_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.

~~~
Sammi
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.

