Hecto: Build your own text editor in Rust
philippflenker.com
philippflenker.com
Slightly OT, but it's interesting to me how common this story seems to be. It's basically my story with Rust too. In many ways Rust is the polar opposite of JS: low-level memory model, high-performance, meticulous and cohesive language design, strict-typing-first. But in terms of its culture and ecosystem there's a lot of overlap: a vibrant package ecosystem that you're encouraged to hook into, trivial cross-platform-targeting, embrace of creativity, and a closeness to the web that spans everything from first-class (de)serialization support to first-class WASM support (unsurprising given its origins at Mozilla).
My theory is that there's a whole bunch of us who use JS at work and are specifically looking for the exact opposite in our hobby projects, not because we hate JS but because we want a palette cleanser/to keep our knowledge broad, and that many of us are turning to Rust, and that this may be a driving force in the way the Rust ecosystem is evolving.
Edit: I have to wonder if there's a similar phenomenon going on with Clojure. It too is very popular with hobbyists, and less popular with companies, and positioned as both adjacent to (in terms of ecosystem and amenities) and directly opposite from (in terms of semantics and developer experience) an extremely popular enterprise language - Java - which many people use every day at work and have a love-hate relationship with.
Or Android apps for that matter.
I use Rust at work, and JS only in hobby projects :)
There is something "opposite" about these languages, but I think both coexist because there's very little overlap in their use-cases. You use Rust where JS can't be used (multicore, high-performance, or low-level native code), and use JS where Rust would be overkill (small webby things).
JS "can" do a lot of things if you know how, and cleverly implement and optimize the code, but it's a Turing Tarpit. You wouldn't implement a video codec in JS. You could, but it's not the best language for it.
It's just "being more modern than the 1980s". Rust's the first low level lang to be able to say that.
Ultimately this depends on what modern means to you, but I'm guessing you can't write the "Tiny RPN Calculator" from the D homepage as concisely[1] - i.e. My point is that Rust isn't the only language that isn't C++
[1]: dlang.org - you can play with the exact code here https://run.dlang.io/is/FiWrHF
I wrote it a few years ago (not long after I learnt the language, actually), I wasn't even trying to golf, it came almost straight away just from reading the docs. Note the use of static foreach to generate the switch cases for fun and profit.
That code is as beautiful as it is incomprehensible.
[0]: https://play.rust-lang.org/?version=stable&mode=debug&editio...
Most uses of loops break down to map, fold, or similar being able to use them cleanly can avoid a lot of bugs and API plasticity.
There is a function on nightly that would make line 16 a little nicer, but oh well.
I can deal with a fussy compiler that makes me write code in a certain way. But a langauge that compiles fine then segfaults or worse at runtime is far more trouble than it's worth (and requires me to make a big upfront time investment before I can start writing production ready code)
Not true. Even ignoring the GC we have compiler checked semantics for an increasingly large subset of features, and the language has had ways of managing code that is safe, unsafe, or trusted for years and years now.
As a newly minted employee of the D foundation, I am aiming to work to expand the memory safety features D has.
D has lots of memory safety features. It is not the same set of features as Rust. It's wildly incorrect to suggest that Rust has a monopoly on memory safety.
However, if you use @safe (that's the attribute) the compiler will hard-error if you call any code that you use that isn't explicitly also either @safe or @trusted.
There is also DIP1000 and DIP1021 which both loosen @safe semantics to perform semantic analysis to allow safe memory behaviour (A small borrow checker in effect, this will hopefully be bigger soon).
Has the ability to specificy formal proofs in the type system (SPARK).
Which basically beats the point of Rust being the only modern language happening post 1980.
Ada was just one possible example, SIGPLAN archive has a couple more to pull from.
It's really interesting to check out if you want something really powerful and able to hack stuff up quickly / differently.
And all the perl languages definitely have some of that "we code in C for boring stuff, but need something fun and powerful for what we enjoy" ethic.
There was a blog post at one point somewhere talking about a supposed divide between "East coast" and "West coast" languages, which I can't find right now...
[1] It was called "Perl 6" once upon a time...
I used Python and R mostly in work environment and always wished to leverage Julia. The overlaps between Julia and Raku made me realize how to do some stuff and have a better grasp on some Julia capabilities that where perceived as fuzzy concepts. Multi-dispatch for example but also the parallel between NativeCall in Raku and the C API access in Julia. Even if we fall more in the two languages fallacy with it, it is crazy to see how it is easy to provides binding for C, C++, Fortran or Rust libraries to Raku.
Besides that Raku is a joyful/fun language that does not block you if you want to do serious stuffs with it. For that did not come form nowhere. At each FOSDEM edition, I was always peaking for some talks in the Scheme/Raku/Perl room and each time enjoying the talks and the possibilities discovered. I was there in 2015 at FOSDEM when Larry Wall made the official announcement for Perl6, I saw a few talks by Andrew Shitov and others.
In these times where you find a load of articles "learn foo in X minutes", I really like to read more about Raku with the feeling I am "learning Raku for a lifetime".
----------------------------------------------------
I really think that the parallel between what Raku and Julia have got right from the syntax and the integration of unicode, the lisp-ish nature, etc. Julia even got a few more think as having a AST and macro around it (coming in Raku when the RakuAST branch will lend later this year), using GMP binding for arbitrary arithmetic (maybe coming to Raku/do soon).
Raku like Julia have this Lisp feeling where everything is possible to reproduce due to the flexibility of their inner working.
I've gotten a bit better with them since then, but now I'm holding off for RakuAST, else I'd probably be rewriting a large amount of code for nothing (or have some major performance hits). You can see the proposal at https://gist.github.com/alabamenhu/2fec7a8f51a24091dc1b104a2... and a very early implementation at https://github.com/alabamenhu/BinexObjex
Definitely read over the proposal and comments, as my work with binary formats is a drop the bucket of ways to work with them, and I'm always interested in hearing how others would need/use such a feature.
I don't know about the blog but afaik the notion arose from "Worse is better".[0]
https://github.com/DigitalMars/med
It's a very easy editor to understand and extend.
I did write my own editor in C and it was delightful and it addressed my pet peeve with Emacs: the two wasted lines at the bottom (on small devices every single line matters). However I don't actually use it myself because it's missing too many essential features and it would take too long to write them. Also, cross compiling C for multiple platforms is actually tedious due to silly differences between eg. macOS and Linux.
The holy grail for me is still the editor from BLS Pascal which was a full screen editor in about 2 KiB of Z80 machine code. I'm still not sure how Anders managed so much functionality in so little code, but there's just a few little things I wanted differently (which as having Enter split lines and delete joining them).