mirror of
https://github.com/bspeice/speice.io
synced 2025-07-01 13:56:11 -04:00
Use an actual drafts folder
This commit is contained in:
@ -1,40 +0,0 @@
|
||||
---
|
||||
layout: post
|
||||
title: "4 reasons I think Python is broken"
|
||||
description: "but are super technical and not super convincing."
|
||||
category:
|
||||
tags: []
|
||||
---
|
||||
|
||||
I'm going to put on my hipster hot takes hat for a moment:
|
||||
|
||||
*I think Python has kinda made some mistakes.*
|
||||
|
||||
|
||||
|
||||
> [Not me because I can't grow facial hair but wish I could][hipster]
|
||||
|
||||
And I get it; [there are two kinds of languages][stroustrup], and Python definitely
|
||||
belongs to the "languages people complain about because they actually use them" camp.
|
||||
That said, these are the reasons why I'm not super thrilled about Python and am
|
||||
avoiding it. The time has come to acknowledge that there are some bits of Python
|
||||
that qualify as mistakes.
|
||||
|
||||
In no particular order, allow me to present my issues with Python.
|
||||
|
||||
# 1: No Boolean operator overloads
|
||||
|
||||
Language reserves `and`, `or` as keywords. Leads to issues in Pandas
|
||||
where special care must be taken because bitwise `~` takes precedence over
|
||||
comparison operators (`<`, `==`).
|
||||
|
||||
# 2: Poorly specified overloads
|
||||
|
||||
Specifically, `x < y` is not necessarily equivalent to `y > x`.
|
||||
|
||||
# 3: Global variable scoping
|
||||
|
||||
|
||||
|
||||
[hipster]: https://flic.kr/p/Tg9Cdv
|
||||
[stroustrop]: https://en.wikiquote.org/wiki/Bjarne_Stroustrup
|
||||
@ -1,124 +0,0 @@
|
||||
---
|
||||
layout: post
|
||||
title: "Isomorphic Desktop Apps with Rust"
|
||||
description: "and other buzzwords"
|
||||
category:
|
||||
tags: [rust, javascript]
|
||||
---
|
||||
|
||||
Forgive me, but this is going to be a bit of a schizophrenic post. I both absolutely hate Javascript
|
||||
and the modern ECMAScript ecosystem, and I'm stunned by its success at doing some things I think
|
||||
are really cool. And it's this duality that led me to a couple of nights up at 2 AM over the past
|
||||
weeks trying to reconcile myself.
|
||||
|
||||
See, as much as [Webassembly isn't trying to replace Javascript](https://webassembly.org/docs/faq/#is-webassembly-trying-to-replace-javascript),
|
||||
**I want to replace Javascript**. I cringe every time I hear the word "Webpack",
|
||||
and I think it's hilarious that the [language specification](https://ecma-international.org/publications/standards/Ecma-402.htm)
|
||||
dramatically outpaces anyone's ability [to actually implement](https://kangax.github.io/compat-table/es2016plus/)
|
||||
the specification. The answer to this conundrum is of course to have a "polyfill" that actually recompiles
|
||||
code from newer versions of the language to older versions of the language. At least
|
||||
[Babel][babel] is a nice tongue-in-cheek reference.
|
||||
|
||||
And yet, for as much hate as [Electron][electron] receives, it does a stunningly good job at solving
|
||||
a really hard problem: *how the hell do I put a button on the screen and react when the user clicks it*?
|
||||
GUI programming is hard, straight up. But if browsers are already able to run everywhere, why don't
|
||||
we take advantage of someone else solving the hard problems for us? Don't reinvent wheels. I hate
|
||||
that I have to use Javascript for it, but I apparently don't hate Javascript enough to want to
|
||||
whip out good ol' [wxWidgets][wxwidgets].
|
||||
|
||||
Now, there are other "native" solutions ([libui-rs][libui-rs], [conrod][conrod], [oh hey wxWdidgets again!][wxRust]),
|
||||
but those also potentially have their own issues with distribution, styling, etc.
|
||||
With Electron, I can `yarn create electron-app my-app` and just get going, knowing that distribution/upgrades/etc.
|
||||
are built in.
|
||||
|
||||
So the question I want to answer is: **Are we Electron yet**?
|
||||
|
||||
<span style="color:white;">No. No we are not.</span>
|
||||
|
||||
# Technology Survey
|
||||
|
||||
The truth is, WASM/Webassembly is a pretty new technology, and there aren't a lot of nice tools. I knew going in
|
||||
that there were going to be some rough edges, but was curious to see what could be done. Before I get to that
|
||||
though, I need to explain a little bit of what the state of play is. **If you're already familiar with the WASM ecosystem,
|
||||
[skip ahead a bit](#building-an-electron-app).**
|
||||
|
||||
First things first, we're going to skip [asm.js][asm.js] and [emscripten][emscripten]. Truth be told, I couldn't
|
||||
get either of these to produce a usable binary, and so I'm just going to say [here be dragons.][https://en.wikipedia.org/wiki/Here_be_dragons]
|
||||
|
||||
So how does one go about producing a "Webassembly"? That's done by compiling to a separate *target*.
|
||||
First, make sure the target is installed:
|
||||
|
||||
```
|
||||
rustup install nightly # Just trust me on this one
|
||||
rustup target add wasm32-unknown-unknown
|
||||
```
|
||||
|
||||
And then we can build the project with:
|
||||
|
||||
```
|
||||
cargo +nightly build --target=wasm32-unknown-unknown
|
||||
```
|
||||
|
||||
Now, this produces a Webassembly/WASM file (in `target/wasm32-unknown-unknown/debug/`) that we can load in the
|
||||
browser. However, the resulting blob isn't really easy to use; you'd have to write a lot of extra code
|
||||
for Javascript to figure out what functions are actually usable. Fortunately, [wasm-bindgen][wasm-bindgen]
|
||||
handles a lot of that for you (and is part of why we need nightly). The end result is that we can
|
||||
easily allow Javascript to access Rust code.
|
||||
|
||||
This only gets you one-direction communication though. If you want to interact with Javascript,
|
||||
[js-sys][js-sys] acts as a "header" library; it tells the Rust compiler "no trust me, these functions
|
||||
will totally exist at runtime" and allows the compiler to generate your code.
|
||||
|
||||
If you want to interact with the Browser the answer is a bit complicated at the moment.
|
||||
There are currently [three][stdweb] [different][percy-webapis] [libraries][web-sys]
|
||||
that seek to do that, and only one of them has made it past version `0.0.1` ([stdweb][stdweb], it's stdweb).
|
||||
That said, I expect [web-sys][web-sys] to be the long-term solution, so keep an eye on that one.
|
||||
|
||||
But we don't want to just interact with the browser, we want to build an entire application.
|
||||
And since We Totally Need An Application Framework™, there are a couple of options available:
|
||||
[virtual-dom-rs][virtual-dom-rs] (a.k.a. [percy][percy]), and [yew][yew]. From what I gather,
|
||||
`virtual-dom-rs` is attempting to be [React][react], and `yew` is attempting to be [elm][elm].
|
||||
|
||||
Testing your applications is a bit tricky at the moment, and to be honest, I didn't manage to get that far.
|
||||
If you're brave though, [cargo-web][cargo-web] has some nice handling to actually run your tests
|
||||
inside a browser (we're using WASM, remember?). As a practical example, [percy][percy-test] has
|
||||
a unit test or two to demonstrate, but it's pretty basic so far.
|
||||
|
||||
And while we won't cover it here, if you want to ship Webassembly code to NPM, you can do that
|
||||
via [wasm-pack][wasm-pack]. It attempts to handle some of the difficult bits so that people who want
|
||||
to use Javascript (not me) can get access to your code really easily.
|
||||
|
||||
So, that's a quick tour of the state of play. Things are in the early stages, so it's a bit difficult
|
||||
to figure out who's doing what and why they exist, but this hopefully at least sets the stage.
|
||||
|
||||
# Building an Electron App
|
||||
|
||||
Now that you've managed to piece your way through a fragmented ecosystem ([not][gulpjs] [unlike][typescript]
|
||||
[current][vuejs] [ECMAScript](https://benmccormick.org/2015/09/14/es5-es6-es2016-es-next-whats-going-on-with-javascript-versioning/)),
|
||||
it's time to actually build an application. The code I'll be referring to is
|
||||
[over here](https://github.com/bspeice/isomorphic_rust).
|
||||
|
||||
[wxwidgets]: https://wxwidgets.org/
|
||||
[libui-rs]: https://github.com/LeoTindall/libui-rs/
|
||||
[electron]: https://electronjs.org/
|
||||
[babel]: https://github.com/babel/babel
|
||||
[conrod]: https://github.com/PistonDevelopers/conrod
|
||||
[wxRust]: https://github.com/kenz-gelsoft/wxRust
|
||||
[wasm-bindgen]: https://github.com/rustwasm/wasm-bindgen
|
||||
[js-sys]: https://crates.io/crates/js-sys
|
||||
[percy-webapis]: https://crates.io/crates/percy-webapis
|
||||
[stdweb]: https://crates.io/crates/stdweb
|
||||
[web-sys]: https://crates.io/crates/web-sys
|
||||
[percy]: https://chinedufn.github.io/percy/
|
||||
[virtual-dom-rs]: https://crates.io/crates/virtual-dom-rs
|
||||
[yew]: https://github.com/DenisKolodin/yew
|
||||
[react]: https://reactjs.org/
|
||||
[elm]: http://elm-lang.org/
|
||||
[wasm-pack]: https://github.com/rustwasm/wasm-pack
|
||||
[cargo-web]: https://github.com/koute/cargo-web
|
||||
[percy-test]: https://github.com/chinedufn/percy/tree/master/examples/unit-testing-components
|
||||
[asm.js]: http://asmjs.org/
|
||||
[emscripten]: https://kripken.github.io/emscripten-site/
|
||||
[gulpjs]: https://gulpjs.com/
|
||||
[typescript]: https://www.typescriptlang.org/
|
||||
[vuejs]: https://vuejs.org/
|
||||
Reference in New Issue
Block a user