HNHacker News
TopNewBestAskShowJobs

grayrest

1,959 karma · joined May 10, 2009

front end guy
submissionscomments
grayrest··on Writing a Microservice in Rust
> That does seem a bit painful to me.

It's because it's written using a low level library. Here's the first two sections (the http handling part) in Rocket:

    #![feature(plugin, custom_derive)]
    #![plugin(rocket_codegen)]

    extern crate rocket;

    use rocket::request::Form;

    #[derive(FromForm, Debug)]
    struct NewMessage {
        username: String,
        message: String,
    }

    #[derive(FromForm, Debug)]
    struct TimeRange {
        before: Option<i64>,
        after: Option<i64>,
    }

    #[post("/", data="<message>")]
    fn message_create(message: Form<NewMessage>) -> String {
        format!("{:?}", message)
    }

    #[get("/?<times>")]
    fn message_query(times: TimeRange) -> String {
        format!("{:?}", times)
    }


    fn main() {
        rocket::ignite()
            .mount("/", routes![message_create, message_query])
            .launch();
    }
grayrest··on Fear and Loathing in APL (2015)
> Has anyone ever programmed anything sizable in it?

A significant fraction of wall street operates on kdb+, which is a commercial programming environment in Q (a dialect of K), which is APL derived.

APL derived languages operate with a different idea of what makes a programming language good and there was an APL patterns presentation [0] posted yesterday. In brief, the goal is to be able to see and manipulate the entire solution to a problem at once instead of isolating subproblems into layers and abstractions.

[0] https://news.ycombinator.com/item?id=16513393

I wouldn't write a web browser in Q but I've done enough daily programming problems in it that I can see how it'd be useful for writing programs in what would be the 3-5k LoC of Python range.

grayrest··on Rust 1.24
> The only big thing I can think of is the safety of compile-time type checking to ensure you won't end up with some kind of runtime error from mismatched types. Is there something I'm missing?

It's this but designs in statically typed languages with more expressive type systems tend to push a lot of the logic into the type system so you can't use APIs incorrectly. This isn't exclusive to Rust but I do have a few examples:

The Glium OpenGL wrapper puts a lot of effort into moving errors to compile time. The overview[1] explains a bunch of them.

[1] https://github.com/glium/glium#why-should-i-use-glium-instea...

The Servo project uses the type system to tie rust code into the spidermonkey garbage collector so it can't be misused[2].

[2] https://research.mozilla.org/2014/08/26/javascript-servos-on...

More abstractly, one of the more unique features of Rust's type system (linear types) is the ability to be sure a reference is destroyed. This makes Rust particularly good at describing state machines that are compile-time checked. Using standard OOP terms, each state is a class and its methods are the valid transitions. You can't take an invalid transition because the method is missing. You can do this in any language, though it tends to be only done in statically typed languages and it's awkward in Python. What makes Rust unique is that calling the method will consume the instance so you can't accidentally make a transition twice. Trying to call the method again is a compile error. A concrete example of this is state_machine_future[3], which generates an asynchronous state machine using macros.

[3] https://github.com/fitzgen/state_machine_future#example

In a slightly different use of the type system, the Rocket framework has a concept called Request Guards that allow you to map from something in the Request to a parameter in the request handler function. The overview[4] has a simple example on the "Dynamic Params" tab that maps url pieces to a string and an int. This mapping, however, is extensible and you can map to anything. If your handler needs an AdminUser, you can have the request guard pull the user id off the request, connect to the db, retrieve the user, verify the user as an admin, and only enter the handler if all that is successful. This means you can move all the logic and error handling around this into a single place that can be reused just by putting an AdminUser parameter on a handler. I've seen this done with middleware in other frameworks but in Rocket it's on-demand per-handler. As a result, the handlers only have to implement the happy path, which keeps them more compact than I've seen in dynamic language frameworks.

[4] https://rocket.rs/overview/

So the general idea is to use the type system to help you use stuff right. As with anything, it's possible to overdo it and get crazy boilerplate heavy code where you have to convert/cast all over the place and unanticipated use cases can't be done but it tends to be helpful, particularly with autocomplete.

grayrest··on Rust in 2018: easier to use
It's part of the Multicore OCaml [1] effort.

[1] https://github.com/ocamllabs/ocaml-multicore/wiki

grayrest··on Rust in 2018: easier to use
> Has threading support improved over the years?

The main push in this area is Multicore OCaml[1]. I don't track OCaml closely enough to know how getting this into the main compiler is going.

[1] https://github.com/ocamllabs/ocaml-multicore/wiki

grayrest··on Rust in 2018: easier to use
> Ocaml almost fits the bill, but the tooling around it is lacking to put it mildly.

I know the Reason guys want to tackle project setup / build / deps in addition to their syntax changes. I've found the current release's bsb toolchain to work pretty well for js targets but I haven't tried to set it up for native compilation.

grayrest··on Rust in 2018: easier to use
I expect a "it's easier to use" evangelism push around the upcoming epoch release. There are a bunch of mostly completed but still feature flagged changes that should remove a lot of the borrow checker toe stubbing. Getting rustfmt (formatter) and clippy (linter) on stable Rust would ideally be part of the push.

Aside from the almost completed features in the pipeline, I only see procedural macros (macros 2.0) and whatever happens to make async code easier to write[1] really impacting day-to-day code for most people.

[1] I'd really like to see F# Computation Expressions instead of async/await. I know the language experts have said Haskell-like do notation doesn't work in Rust but I'm not sure if the F# tweaks would make it work or not.

grayrest··on Ask HN: Are browser notifications user-hostile?
I accept them if I knew exactly what it was used for (chat, calendar, conference) but the random ones around the net are 100% deny.
grayrest··on How Firefox Got Fast Again
The about:memory display is pretty easy to read and can force memory collections across the app. Should be fairly easy to track down the cause. I run the developer edition and tend to restart weekly or so to pick up new updates but I don't notice excessive RAM consumption.
grayrest··on Fun facts about Rust's growing popularity
There's been a number of competing names (e.g. rustler) but rustacean won out because it has the advantage of being ideologically neutral and lacking other connotations.
grayrest··on Why I'm Productive in Clojure (2013)
> Where LISP throws me off is the excessive use of parenthesis

There's a standard way to indent lisp (the emacs way, which everybody copies) and as long as it's indented properly you read it like a whitespace significant language (Python, F#, etc).

Clojure is a bit easier to read than other lisps because it uses [] for vectors, arguments, and assignment blocks and {} for maps and sets. Gives the code a bit more texture.

People writing lisp day to day use an editor feature to automatically keep parens balanced (Paredit, Parinfer). Not required since there's a learning curve but it makes editing smoother if you're going to write lisp full time. A text editor that highlights the opening paren when the cursor is on the closing one (pretty common feature) is all you really need.

grayrest··on Some Excel users pop F1 off their keyboards (2012)
> Caps lock gets remapped to ESC

15 year vimmer here. Caps -> Ctrl and use C-[ for going to normal mode.

grayrest··on “What next?”
To my knowledge, there isn't a full OSS implementation of K/Q. I do know of a K5 interpreter in JS [1] but otherwise I've only been able to find the free for personal use 32 bit Q distribution.

[1] https://github.com/JohnEarnest/ok

grayrest··on A First Reason React App for JavaScript Developers
The tradeoffs between Elm and Reason/Fable are that the former is Pure and the latter have imperative escape hatches. There are benefits to both. Elm has a neat time travelling debugger built in and enforces semantic versioning via their package manager. Reason and Fable have much tighter integration with the javascript ecosystem. This tends to lead to differences in community package philosophy with Elm mostly maintaining its own package repo (own vdom system, own date lib, etc) with the occasional ports for interacting with popular javascript libs while the more nascent Reason/Fable communities tend to write interface definitions and call the JS directly (e.g. they use React for vdom).

I group Reason (Ocaml/Bucklescript) and Fable (F#) together because F# is OCaml's sibling language on .Net. They're very similar. The two projects have similar philosophies, specifically to bring their ML variant to the javascript ecosystem in a module-by-module mixed-language fashion instead of having the language be its own island in the browser. Neither has a particularly large community but the Reason guys have been doing a better marketing push this month, at least from my perspective.

grayrest··on Serving 39M Requests for $370/Month
> Rewrite the Readability Parser API

That's at least the third rewrite of the parser. The initial version was a js bookmarklet, I did the rewrite into Python in 2008 which kind of sat around and then got turned into the app by a different group about a year later. Fun to see it go back to JS.

grayrest··on Hauberk – A web-based roguelike written in Dart
Google put up a code lab for Flutter:

https://codelabs.developers.google.com/codelabs/flutter/inde...

It's a super simple UI but you can just pretend it's Java and read through the code samples to get a feel for how things are structured/organized. As a web dev with a strong preference for functional programming I find it unpleasant but I don't think I'm the target audience.

grayrest··on Reuters' position on covering Trump
> I don't know if they ever responded to this issue, but it forever changed my opinion of Reuters.

I didn't write the code so I don't have first hand knowledge but I work for the guy who did. It was a data glitch.

grayrest··on BuckleScript: write JavaScript faster, safer and smaller
If we're just talking about compiling a typed language to javascript, gwt did it 12 years ago.
grayrest··on BuckleScript: write JavaScript faster, safer and smaller
> To me, in the WebASM world, transpiling to JavaScript is starting to seem a little old-fashioned.

It's behind a flag in a couple browsers. Even with a flag, if you're going to actually do anything with the DOM, you're going to be shipping a js support library and calling into it. Using something that works now has value, particularly when you could get wasm in the future off the same code if anybody writes an OCaml wasm backend.

> Presumably Rust (or Ocaml) compiled to WebASM will also have substantially improved performance compared to transpiled JavaScript

Bucklescript adds asm.js type hints (but not the use strings) to the js output and does a fair number of optimization passes. Aside from reducing parse time, going from its current output to wasm is unlikely to pick up much in the way of perf. I'm actually not even convinced that wasm is going to be that much faster for load+parse over an optimized js payload because asm.js/wasm have to ship the runtime (allocator, stdlib, etc) while js just has to ship the code.

> Readable JavaScript is not as important as long as we have source maps

I write Clojurescript full time, which has source map support. I completely disagree with this statement.

> Ocaml and Rust share a lot of heritage

Rust was bootstrapped off an OCaml compiler. I like Rust and advocate for it but bringing up another compile-to-js language, particularly one as nascent as Rust doesn't really have anything to do with the merits or drawbacks of Bucklescript.

grayrest··on Pixie – A small, fast, native Lisp
If this is a major concern for you, there are several clojurescript projects--Planck and Lumo--that have very fast startup. JVM Clojure is a bit faster than jsc/node clojurescript (~2x IIRC) but that shouldn't matter much for scripting/automation and lambda functions or equivalent on other clouds.
grayrest··on Crafting a high-performance TV user interface using React
I've maintained a ~20k LoC re-frame app for a year and a half. The performance of Clojure's persistent datastructures with pervasive sCU gives you generally good performance but it's not panacea. I've debugged a hundreds-of-milliseconds freeze on laptops from a poorly written hierarchical menu and I get pauses of 70-100ms if enough data comes in on our main view.

Using it with cljs-time and storing times in the app state is a really easy way to shoot yourself in the foot perf-wise since that's based on closure's date object and two equal date objects are not identical. This fails the fast identity check but will pass the structural equality check so no vdom gets generated but the check is not that much cheaper than a diff.

This is also a B2B app where we have no demand for mobile use so I haven't had to do load time or mobile perf optimization. If I did, the first thing I'd be concerned about is the bundle size since the cljs runtime plus React represents a fairly sizeable amount of overhead.

Not to say that reagent+re-frame is bad, it's just not so amazing you don't have to care about perf. I think Reagent would run particularly well on top of Inferno since the library provides lifecycle events to function components and I did experiments back in April and June on Inferno with persistent datastructures to good results. I just don't want to maintain it.

grayrest··on Compiling Rust to Web Assembly
> I especially welcome the possibility of using a safe language like rust for web development, instead of writing more dreadful javascript...

There are now a number of typed languages that have solid compile-to-js support. I've done it with OCaml (js_of_ocaml, Bucklescript), F# (Fable), and Elm. For dynamic languages, there's also Clojurescript, which is quite nice.

grayrest··on Ask HN: Senior developers, what would you tell a younger you?
What makes someone a senior developer is that they reliably reduce technical risk to a project and deliver on time. There are a lot of definitions for "senior" floating around, but that's what everybody really wants.

The main advice I give to junior developers is that state is the core of incidental complexity. Focusing on minimizing state to the degree practical is the simplest trick I know for producing well designed systems. The only place it doesn't necessarily work is high performance code.

grayrest··on What's New in F# 4.1? [video]
I don't have anything pressing and I don't know the ecosystem so I'll be waiting it out. My frustration is mainly that I think F# with Fable and Kestrel in VSCode is very compelling for JS shops and the only reason I can't recommend it is the build situation. An explanation of how to make a project, add a dependency, and run it that would make sense to someone used to npm would really help people who aren't on windows and running visual studio. I do appreciate the efforts of the F# team has always made in maintaining an open source community and I do recognize that there are lots of complications involved. Thanks for your efforts.
grayrest··on What's New in F# 4.1? [video]
So, I've been making a slightly more concerted effort to pick up F# because I've always liked F# and .Net core and Fable means that I might actually get to run it at work without the non-starter of switching stuff over to windows servers. Excellent.

The main holdup is that the build/packaging situation is disastrous.

Most stuff still relies on Mono, which is fine, but trying to get things running on core quickly runs you into articles that assume you know exactly what you're doing and how all the pieces fit together, which is also fine.

What's not fine is that the base task of wanting to download existing packages and run the result doesn't have a simple solution. The base .net core install comes with a project.json solution, which seems completely sane to me, but apparently that's deprecated and not how to do things. Then there's Nuget which is a package repo but apparently not a package manager because it's supposed to be a VS extension but maybe it is in the next version because there's a shell. There's also msbuild and some variant of it for fsharp which is mostly opaque XML but can be managed using a project called forge, which seemed to kind of work for me but also seems very opaque. There's also paket which manages dependencies from nuget, there's also Fake which seems to be a Rake-like build system.

I know I'm not the only one who's run into this. I've seen at least 4 other requests for help in various F# forums and everybody seems to pretty much shrug and say that they use VS.

If one of the F# cognoscenti could write up simple instructions on how to set up a project and run it using VSCode and .Net core, I'd be grateful.

grayrest··on My search for a MacBook Pro alternative
I'm also not thrilled with the current round of Apple hardware. The main thing that will keep me on MacOS for this round is that I really like the extra modifier key. Dropping it means I have to change up all my keyboard shortcuts and/or reconfigure everything to use the windows key as super or hyper. I'll overpay this round and see what's up in 5 years.
grayrest··on InfernoJS – A JavaScript library for building powerful user interfaces
They just went through a big github discussion about the design that finished last Saturday. It should be actually pretty soon instead of "soon".
grayrest··on InfernoJS – A JavaScript library for building powerful user interfaces
If you're bundling it into one payload it does not. If you're code splitting, it's 38k of download time and ~120k of parse time you're not paying on time to first meaningful paint. It's a couple dozen ms on desktops but can be several hundred on mobile.
grayrest··on Jq – Work with JSON on the command line
My usage is generally pretty simple as well but if people are looking for a more complex example, I wrote one yesterday for putting together some test data. Turns DynamoDB responses into newline separated flat arrays:

    pbpaste | jq -c '.actionResponses[].data.items[] | [.attributes[] | .stringValue // (.numberValue | tonumber)]'
grayrest··on React Draft Wysiwyg
It handles the more complex (e.g. CJK) input methods. The alternative is a hidden text field and you have to put more effort into emulating the cursor (e.g. up arrow/down arrow). Regularly re-generating the underlying markup removes a large class of edge cases and cross-browser incompatibilities in exchange for not being able to use the browser's native undo. It's still a lot harder than you'd expect but it seems to be working for draft and prosemirror better than my attempt to normalize the cross browser differences and rely on the browser.

P.S. I also came into this thread to endorse Prosemirror.

← PreviousPage 5 of 23Next →