grayrest

I took up cycling. When I was 35 I was having trouble with back pain that I assumed was rooted in not exercising. I find cycling to be the least objectionable form of exercise. My hip popped back into socket after a couple weeks and that was the main cause of back pain but I find I feel significantly worse and am less productive if I don't keep up with the exercise.

For purely code stuff, I tend to learn a new language when I don't want to program anything. I particularly like ones with non-mainstream philosophies as they provide a different perspective on the craft. I don't do much with the languages I learn but it usually kicks me back into regular coding.

> How could it be more productive to write 4x code for the same result?

Lines of code in Elm is not directly comparable to Clojure. The standard Elm formatting uses very short lines and lots of vertical whitespace. Without looking at it, I'd guess 1.5-2x more actual code bytes for Elm. As for why the increased size would be more productive, Elm is content to trade verbosity for lower cognitive load/fewer concepts so it's slightly boilerplate and every app I've run across shares the Elm architecture so the patterns are similar.

I prefer Clojure/Clojurescript and re-frame in particular for the task but I can see how someone with different preferences would be faster in Elm.

Location: New York City (NYC)

Remote: Yes

Willing to relocate: Yes but prefer not

Technologies: Full stack web, frontend, backend

Résumé/CV: http://gr.ayre.st/s/Karl_Guertin_resume.txt

Email: username at my domain or gmail

If you do switch, check out the temporary containers addon. It makes use of the Firefox containers tech to provide the anti-tracking benefits of incognito but maintains history and isn't detected by websites as incognito mode.

> How many times has Google done this? And then gotten bored of their own work?

Google's history on this sort of thing isn't good but this will be much more stable than their other offerings. Dart is the primary language of the ads (i.e. money making) side of Google and Flutter is their best shot at making the language relevant elsewhere. I'm still not in a hurry to learn it but I'd be very surprised if it's in the trash bin within 5 years.

Software engineering is about state management and team dynamics.

I'm fairly poor at the second so all I'll say is that being good at the politics/communication becomes more important as you become more senior and is ultimately more important for your career than being good technically.

Technically, the most important thing I learned after I graduated is that state is the most important thing in production systems. Programming paradigms, system architectures, and design patterns are all rooted in managing state. Almost always by constraining it.

For me the critical talk on this was Rich Hickey's "Are We There Yet" but I'd been writing functional code for a couple years when I saw it. When I've directed people to it they find it weird/confusing and have more success with "Simple Made Easy" which I find similar but less insightful. A focus on state first has been the cornerstone of my development philosophy since 2009. It's not universal (e.g. data oriented design) but it's my one weird trick.

I'm a visual thinker and visualize a piece of state as a gas that leaks through calls and variable scope. If it's in the database it leaks through queries accessing the table and the services that expose it. The fewer things state touches, the better because people fundamentally are terrible at understanding interactions over time (e.g. three body, double pendulum). Seeing the state flow through the system tells you how well it's designed/built and where the problem points are.

> If you zoom in on the Upper East Side, there's a tiny corner that's not rich, or at least wasn't in 1993. It's called Yorkville, and that was my new home.

From my apartment at 83rd & 1st, it still isn't particularly rich. I thought it'd change with the new subway line opening but I haven't noticed much of a difference.

No and it's not useful. It's literally just editing `src/link/Wasm.zig` and changing the `--export-all` line to `--export=addInc` (to use the zig wasm example's naming) and copy/pasting the line if I wanted to export more stuff. The compile invocation is:

    zig build-lib add.zig -O ReleaseSmall -target wasm32-freestanding -static

You can debug the linker invocation with `--verbose-link` on the end of that.

The issue tracking the problem is: https://github.com/ziglang/zig/issues/7133

I've spent a good amount of time this last year playing around with WASM options in anticipation of it being a major runtime environment for cloud computing.

Rust has the most developed ecosystem but the best experience I've had otherwise was with Zig. It's reasonably easy to write and can produce excellent final wasm size. The only problem is that the compiler is currently exporting every public symbol in the standard library but when I hacked up the compiler to only export a hard coded list of symbols I got ~150 bytes for add (the WASM hello world) and easily sub 1k for the type of modules the post is discussing.

There are similarities but Fire is more of a space opera and Deepness is more of a character drama. The tech details in Fire are more fantastical since they involve superluminal communications/travel and the book centers around the mechanism that makes that possible. I like Fire more because I like the pacing and the xenos better (space operas are fun) but the tech and its implications are far better in Deepness. I like the depiction of computing/programming in both and both have the history of technology as a major theme, which is one of my favorite topics.

> What's with the lengthy discussion of lattices, and related terminology?

It's how the author thinks about the values. All the operations move a value up (|) or down (&) the lattice and those operations are associative, commutative, etc. Moving down past the concrete values gets you bottom, the error value, so 1 & 2 is _|_. It fits into things like default values where (using # for * because HN formatting doesn't do escape sequences) a: int | #1 and a: int | #1 unify to 1 because #1 & #1 = #1 but a: int | #2 added would result in a: int because #1 & #2 = _|_ so there is no default anymore.

I don't think the extended discussion on lattices is particularly useful. A much better intro is the tutorial [1] plus the concepts page [2]

[1] https://github.com/cuelang/cue/tree/master/doc/tutorial [2] https://cuelang.org/docs/concepts/logic/

The motivation is clearly to build a tool for configuring kubernetes but I see the combination of data, validation, and order independence as being valuable outside that use. I've definitely had projects where it'd fit. The main reason I'd think twice is because it does add a LOT of concepts for something that can be pretty simple on most projects.

I found out about algebraic effects a year or two ago when I ran across the efforts to bring them to OCaml. Async/await was a preliminary thing so I though algebraic effects would be a more complete solution and more in line with the Rust ethos. After asking around in some NYC meetups and on Reddit , my impression is that there isn't a lot of appetite to break additional new ground in terms of bringing fringe language features (I'm unaware of a non-academic language that features them in a production release, OCaml is closest AFAIK) into a language that already has a fairly high barrier to entry.

> is it going to last? Is it yet another thing Google will abandon?

It's apparently the primary language for Google Ads. As such, I expect it to be maintained as long as Google continues to sell ads and if they do move away from it you'll have plenty of warning.

It IS why Mozilla sponsored the language. The early "why Rust" presentations had a stat that (paraphrasing) 50% of Mozilla security bugs would have been prevented by the borrow checker.

This has been covered in the NY Times [1] and I've read more detailed breakdowns of other projects in more transit/government focused publications. The short version is that the government doesn't do a very good job with planning despite spending a ton on it and the combination of union labor and the hiring structure leads to workers getting paid several hundred dollars an hour during overtime (which happens due to the planning) and more workers performing a task than similar transit efforts elsewhere in the developed world.

[1] https://www.nytimes.com/2017/12/28/nyregion/new-york-subway-...

> What's it like to work with? Do you prefer it to JS/PHP/Python for web related projects?

Of the popular frameworks in languages you mention, Rocket is fairly close to Flask in terms of feel. Rust is a typed language and Rocket uses code generation and function's type signatures to automatically check the incoming parameters.

This can be fairly simple, like verifying+converting a param to a number. It can be fairly involved like setting it up so that if one of your handler function's arguments is an AdminUser, Rocket will take the user id from the request/cookie, connect to the database, and verify that the user is an admin. This is doable with middleware in many frameworks for the languages you mention but the difference is that this is on-demand based on the argument types.

> Can you iterate on code quickly, or is there a compile step on every iteration?

Rust is a compiled language. There's a compile step when you make a code change.

> Are there stable libraries for interacting with MySQL/Redis/Postgres asynchronously?

There are libraries for interacting with all those things. That said, the Rust async ecosystem is in a transition period at the moment. If you're familiar with the JS transition from callbacks to Promises to async/await, it's basically that. Check back in 6 months.

> Is there good IDE support, for example in Atom?

IDE support in Rust isn't particularly good yet. In general, find references and go to defintion work but autocomplete does not.

The plan was always to get on stable[1]. Sergio just wasn't willing to compromise on the API to make it happen sooner and I appreciate that since it's a motivation to stabilize the things Rocket depends on. The release notes being discussed here mention that Rocket should be on stable with the next major (Rocket) release.

[1] https://github.com/SergioBenitez/Rocket/issues/19

edit: specify Rocket release, not Rust release

As a whole, Rust developers see 1.0 as a stability commitment and to my knowledge, everybody (well, not Rouille) wants to be async and depend on Futures 1.0. I believe Futures 0.3 is most of the way to where the Futures team wants 1.0 to be and the initial roadmap was trying for 1.0 in 2018 so my uninformed guess is that we'll see Futures 1.0 in the first half of 2019. I expect the whole Rust network server ecosystem to shift around over the coming months as Futures and async/await come online in the next few months.

An anecdote:

I own a recumbent bike. Learning to ride it wasn't difficult, I was able to wobble around and had to regularly put my foot down the first couple minutes and got my balance for real within a day. I let other people ride it when they ask me about it and my experience seems fairly normal.

By contrast, at one point I went 10 years without riding a bike. When I got back on, I could immediately ride. No wobbling, no learning curve.

I've seen videos of other adults learning to ride bikes and it doesn't take them long to learn how to ride but it's not immediate.

I'd agree with the 10 year timeframe. Before that browsers were basically aiming for HyperCard. It was only after the combination of the WhatWG and the emergence of the app store as an ecosystem threat that the browser vendors have pushed the browser towards OS replacement.

It's in an early stage but the Saturn [1] project is aiming to compete with Phoenix more directly. The owner is a fairly prolific F# open source contributor and presented it at NYC F# last month but that's about all I know about it.

[1] https://github.com/SaturnFramework/Saturn

Om isn't so much a take on React as it is a take on the state management layer and it uses React under the covers. I believe it's been largely superseded by re-frame [1], which follows the Redux / TEA model. There is an Om Next and that's basically a take on Falcor / Relay using the Datomic pull syntax but I haven't heard that much about it outside the talks where he was announcing it.

[1] https://github.com/Day8/re-frame/

There's a couple different stages and you can stop at pretty much any point: being able to read it, understanding all the ideas, writing with correct idioms, writing fluently, being able to design projects/systems effectively in it, and finally coding stability.

I know a lot of languages and learning new ones gets easier as you learn more of them. I can read pretty much anything aside from some APL variants. It usually takes me 2-3 hours to get the ideas for most. I can usually get to writing reasonably good code over a weekend and that's usually enough to fix bugs or contribute code following someone else's design patterns but it's fairly slow going. From there things slow down a lot because you need to work your way through the ecosystem learning the common libraries and their interfaces so it's usually 2-3 weeks full time before I really feel fluent and 6-8 weeks full time before I'd be confident in adopting it professionally. I find that my coding style stabilizes (I look at code I wrote 6 months ago and would still write it that same way) in a language after about a year and a half.

This timing varies a lot depending on the language. Languages that are designed to be familiar to C#/Java/JS devs like Dart or Go and you fall in that camp, you can blast through the tutorial to get the syntax and be into learning idioms. If you're significantly shifting paradigms (e.g. picking up your first functional, logic, or concatenative language) then you can expect to spend a couple weeks being blocked in the ideas phase. Switching domains is similar so if Rust is your first systems level langauge, you're going to spend a LOT of time on OS and memory details that other languages handle for you.

I believe that'd be a follow-up to the host bindings proposal [1].

[1] https://github.com/WebAssembly/host-bindings/blob/master/pro...

> What's the relevance of learning Rust for someone into web development?

Rust is a language that cares a lot about correctness. If I were particularly interested in making sure the code I wrote worked in production, Rust would be my first choice in the set of a dozen languages I know.

Rust is probably quite a bit faster than whatever you're using for web development. The normal counterpoint to this is that web requests tend to be rate limited by the database. This is mostly true but using Rust pretty much guarantees this will be the case. I believe that this point isn't that compelling with current architectures but would be worthwhile in a CQRS architecture where formatted data gets pushed/cached by the web servers and servicing requests stays on-machine.

Rust is one of the more compelling web assembly languages due to not needing a garbage collector. Demos exist but this is mostly in the exploratory stages.

Longer term, I expect Rust to have a unified async networking stack. You can do blocking IO networking in Rust but I expect most network clients/servers to be mostly async once the Tokio stack settles. This is all expected in node but the networking libraries tend to be fractured in most languages.

I don't think you should run out and switch over to Rust for general web development. There's going to be a big release in the fall that rolls up a bunch of ergonomic/convenience stuff that should make it easier to pick up and less annoying to use. I also think that IDE support will be important for a lot of people learning Rust. The situation is improving but the support is not up to par compared to more mature languages. All told, it's serviceable but I don't expect it to be particularly compelling as a web development language for at least another year or two.

The bottleneck varies depending on the specifics of the JS, DOM and CSS. I find that when something is slow the culprit is usually someone doing something dumb in JS. For non-dumb causes, layout is usually the bottleneck (reflow, applying styles, building the display list) but it can be other things. As an example, I worked on a site 5 years ago or so where the bottleneck was on paint, mostly due to lots of shadows. I believe caching of rendered shadows has made its way into most engines but it caused us issues at the time.

Mozilla has been doing a lot of work on this front. The Servo project demonstrated you can do style and reflow in parallel. Pieces of that effort have been pulled into Firefox under the "Quantum" label but not the actual reflow part. They're in the process of finishing and incorporating WebRender to make paint more efficient and GPU driven and there have also been efforts at building new drawing APIs (PathTracer, Lyon) as part of that project.

I know Chrome had been doing experiments with implementing DOM methods in Javascript to avoid having to cross the JS/C++ barrier in v8 but I haven't heard about that in a while nor any other major DOM-related perf projects out of them.

Fairly long answer to a short question. If the new APIs retain the synchronous nature of the current DOM APIs where reads against the DOM state force previous DOM manipulations are blocked until a forced layout happens (I hope they are) then it'll still be possible to DOM thrash and kill your perf that way. I also suspect there's enough overhead in JS->DOM calls that WASM could pick up a double digit perf gain in microbenchmarks but not an order of magnitude with the caveat that's a fairly uninformed guess.

I used the redesign for two days and rolled back. The designers went for a river of news app-like design.

I've always had trouble putting individual items in context in river of news designs and prefer to switch from one topic (subreddit in this case) to another and scan each one. The hamburger menu makes this a lot more awkward.

I also really dislike mobile-driven UI designs on a desktop. I know why they're done. I've implemented them myself. They annoy me.

It's a contrived example and doesn't make a whole lot of sense aside from demonstrating what he means by handle. I'm not an expert but I'll have a go at explaining it.

Start at the `Data` struct. It contains a Copy on Write (`CoW`) reference to a vector of bytes (`u8`) with a lifetime labeled `'a`. This is the Handle for the data. You get one by calling `Data::new` and passing in something that can be converted to the CoW.

The example is hard coded to work with a vector of u32s (driven by the `Slice<u32>` in `Header`). To use it, you'd call `get_target` with an index and get a u32 back. The other methods on data are doing the pointer math (offset) and casting (`transmute`, `from_raw_parts`) the byte array into a slice of u32s in a safe way.

I don't see anything verifying that the byte array passed in is, in fact, a bunch of u32s so I assume that's a given.

> When did RSS go out of style anyway?

It went away when Google killed Reader. Reader had more or less killed off the independent RSS reader market. When it got shuttered, alternatives weren't well developed and people shifted more or less entirely onto Twitter. The Twitter shift had been happening already but the shutdown kind of forced the issue.

> For example, when gcc yells about comparing signed and unsigned ints, I find that there rarely is a true safety concern involved. I hope Rust is better than that.

In Rust these are treated as two completely different types so this is a compiler error and not a warning. You need to explicitly cast one of them to make the comparison and integer types are not automatically converted in any way. You have to do the same for any other operation involving the two types (e.g. addition).

You could certainly define the `ParitalOrd` trait for the two types to make the comparison possible (I don't know the implications off the top of my head). The language defaults to safe and explicit.