Hacker News: alquemist

New comment by alquemist in "How Shopify Uses WebAssembly Outside of the Browser"

alquemist — Sun, 20 Dec 2020 00:31:18 +0000

Rarely. Over a long enough time period though, the probability of a portability event nears 1, and the cost of such event is enormous. Right now there is a credible challenge for the x86 domination in the server, laptop and desktop markets raised by ARM, via AWS A1, Apple M1 and many others. Would be foolish to bootstrap an ecosystem locked-in to the loser, and we don't know the winner / loser over a 5-10 year timeframe.

New comment by alquemist in "How Shopify Uses WebAssembly Outside of the Browser"

alquemist — Sat, 19 Dec 2020 19:16:12 +0000

I am not following WASM closely, but it appears to be deployed in all modern browsers: Chrome, Firefox, Safari, Edge. That counts as 'large scale production deployment', even if there aren't that many websites that take advantage of this capability (yet?). https://caniuse.com/wasm

New comment by alquemist in "How Shopify Uses WebAssembly Outside of the Browser"

alquemist — Sat, 19 Dec 2020 13:18:07 +0000

In a WASM + seccomp implementation, the whole WASM runtime runs inside seccomp. Breaking out of WASM leaves one running arbitrary asm inside seccomp, which has exactly the same attack surface as directly running untrusted binaries inside seccomp. The WASM layer in WASM + seccomp simply requires an additional exploit.

New comment by alquemist in "How Shopify Uses WebAssembly Outside of the Browser"

alquemist — Sat, 19 Dec 2020 13:09:14 +0000

That's a bit of apples and oranges. JS/WASM are runtimes executing hostile code, whereas Go apps are trusted code.

New comment by alquemist in "How Shopify Uses WebAssembly Outside of the Browser"

alquemist — Sat, 19 Dec 2020 12:56:36 +0000

Assuming that Intel / ARM microarch implementations are bug free, that is correct. In the real world there are no bug free implementations.

Edit. This is the strategy Chrome sandboxing uses: a hardened runtime (JS/WASM) inside a seccomp enclosure. https://chromium.googlesource.com/chromiumos/docs/+/master/s...

New comment by alquemist in "How Shopify Uses WebAssembly Outside of the Browser"

alquemist — Sat, 19 Dec 2020 12:39:41 +0000

* Predictable performance.

* A wide ecosystem of mature language toolchains.

* Simplicity: JS implementation contain sophisticated JITs, which are harder to prove correct compared to a simple ASM translator.

* Portability: not tied to a specific HW architecture.

New comment by alquemist in "How Shopify Uses WebAssembly Outside of the Browser"

alquemist — Sat, 19 Dec 2020 12:36:09 +0000

It's not an either/or. Most likely Shopify runs WASM inside an seccomp enclosure. Possibly inside a VM as well. Defense in depth.

New comment by alquemist in "Death by 1000 layers: the perils of over-abstraction in Java (2017)"

alquemist — Tue, 15 Dec 2020 01:41:30 +0000

Mock: Adhoc guessing of what methods called on a dependency, but sometimes even between classes in the same module, might return. Guess repeated over and over as new tests are added, sometimes tens of times or even more. For example, https://site.mockito.org/#how, "when(mockedList.get(0)).thenReturn("first"); System.out.println(mockedList.get(0)); // prints "first""

Fake: A replacement module that behaves like a production module, but with certain simplifications, for example in-process vs. using rpcs, or simply cleaning up the filesystem after usage. For example, https://github.com/tk0miya/testing.postgresql. "automatically setups a postgresql instance in a temporary directory, and destroys it after testing".

New comment by alquemist in "Death by 1000 layers: the perils of over-abstraction in Java (2017)"

alquemist — Mon, 14 Dec 2020 11:37:09 +0000

Agreed. Using mocks while testing vanilla in-process code is never justified.

New comment by alquemist in "Death by 1000 layers: the perils of over-abstraction in Java (2017)"

alquemist — Mon, 14 Dec 2020 11:10:15 +0000

Fakes are not mocks. The fake is just another module. Assuming no updates, it is written once. Mocks are written 47 times, inconsistently, while focusing primarily on other tasks. If there are updates needed, better to fix them in one place than chasing 47 test code locations with inconsistent usages.

Furthermore, these are external dependencies that can't be run in-process. If a dependency can be run in-process (aka library), there is no justification to ever mock it. I've even seen codebases that mock their own class B in order to test class A. Run the production code already. Ban mocking libraries.

New comment by alquemist in "Death by 1000 layers: the perils of over-abstraction in Java (2017)"

alquemist — Mon, 14 Dec 2020 10:35:36 +0000

Fake, don't mock. Write, or ask the team that provide the external dependency to write, a small piece of code that behaves like your external dependency, but in-process. You'll thank me after about the 47th time you're guessing (inconsistently, possibly incorrectly, and definitely overly verbose) how the external dependency actually works. Ban mocking libraries.

New comment by alquemist in "Death by 1000 layers: the perils of over-abstraction in Java (2017)"

alquemist — Mon, 14 Dec 2020 10:31:43 +0000

Fake external storage / rpc dependencies.

New comment by alquemist in "Death by 1000 layers: the perils of over-abstraction in Java (2017)"

alquemist — Mon, 14 Dec 2020 10:08:27 +0000

Don't mock. Test production code, maybe with faked storage.

New comment by alquemist in "Why software ends up complex"

alquemist — Mon, 14 Dec 2020 00:38:47 +0000

"In the beginning was the word". Language shapes reality. As software engineers, the second we accept that 'product owner' is a legitimate title, that second we lost agency to push back on poorly conceived features. Say it loud and clear: you also have a stake in the product.

New comment by alquemist in "U.S. Treasury breached by hackers backed by foreign government – sources"

alquemist — Mon, 14 Dec 2020 00:25:43 +0000

https://leanprover.github.io

While it is difficult to design a secure procurement chain all the way to the SiO2, we could at least design simple enough hw/sw systems for which formal verification is an economical option. And then force government entities to use formally verified systems instead of the bug ridden crap most shops, especially the sw ones, have to ship under intense deadline pressure. The market has led us into a broken local optima, no way to get out short of state level action.

New comment by alquemist in "Monads and GATs in Nightly Rust"

alquemist — Sun, 13 Dec 2020 14:40:57 +0000

Can not resist. The tension between 'basic feature set' and an admittedly superficial reading of the docs is very funny. The manifesto links to https://github.com/commercialhaskell/rio#readme and urges us to use the rio library to get started. Upon opening the rio link and scanning for a list of the 'basic feature set', I stumble upon the first block of quoted code. After removing 39 eoln characters in respect for the HN audience, it reads:

"Our recommended [language extensions] defaults are: AutoDeriveTypeable BangPatterns BinaryLiterals ConstraintKinds DataKinds DefaultSignatures DeriveDataTypeable DeriveFoldable DeriveFunctor DeriveGeneric DeriveTraversable DoAndIfThenElse EmptyDataDecls ExistentialQuantification FlexibleContexts FlexibleInstances FunctionalDependencies GADTs GeneralizedNewtypeDeriving InstanceSigs KindSignatures LambdaCase MonadFailDesugaring MultiParamTypeClasses MultiWayIf NamedFieldPuns NoImplicitPrelude OverloadedStrings PartialTypeSignatures PatternGuards PolyKinds RankNTypes RecordWildCards ScopedTypeVariables StandaloneDeriving TupleSections TypeFamilies TypeSynonymInstances ViewPatterns"

39 language extensions just to get started. This screams 'incredibly complicated', even if perhaps reality is rather more mundane. Consider the 40th language extension: GradualTyping, so perhaps those that would rather write code about data than about types using a half baked and evolving type language (which taken to its logical conclusion will have to become a full fledged theorem prover in the Coq / Idris / Agda / Lean lineage anyways) could get their jobs done.

Wish you guys all the best!

New comment by alquemist in "Monads and GATs in Nightly Rust"

alquemist — Sat, 12 Dec 2020 02:01:42 +0000

99% of the time a loop works just fine, because there are no measurable gains to be had from parallelism. For the 1% where performance matters, it's usually a bit more involved that simply using a map or fold, and hopefully already packaged as an off-the-shelf library. To have measurable gains from parallelism one has to be very intentional in balancing communication vs computation. Think carefully designed libraries like cuDNN.

New comment by alquemist in "Monads and GATs in Nightly Rust"

alquemist — Fri, 11 Dec 2020 21:22:58 +0000

'FP' covers 2 meanings:

A. Pure functions + immutable data structures.

B. Expressive type systems, all the way to compile-time metaprogramming and dependently typed proofs.

Writing programs in style A. is tremendously valuable. Expending too much effort in the fine points of the type system, which invariably is simultaneously both under-expressive and over-expressive, is a complete waste of time. Some critical projects require high defect-free confidence, and for those it's legitimate to go full in formal proofs and take the 10x-100x productivity slowdown. For mere mortals, documenting the structure of the data (json) manipulated by the respective functions suffices.

New comment by alquemist in "Monads and GATs in Nightly Rust"

alquemist — Fri, 11 Dec 2020 21:07:27 +0000

Haha, I'm the wrong person to ask. I was fortunate enough to be in a hands on senior role, and I promoted a very light Java++ style, to be learned in a 2 hours seminar: immutable collections, case classes, pure functions, impure logging & exceptions, sparingly used interface polymorphism, recursion, filter/map/flatmap/fold. Scala: The Good Parts. To this day I have not learned the first thing about implicits or type variance, and probably there are many many many more Scala features I haven't even heard of. The biggest challenge was helping the rest of the team avoid writing inscrutable sbt plugins. The plus side, it makes little difference Scala2 vs. Scala3. The downside, some teams may scoff at such a mundane approach.

New comment by alquemist in "Monads and GATs in Nightly Rust"

alquemist — Fri, 11 Dec 2020 20:51:20 +0000

I used Scala2 professionally for a few years. Recently picked up Typescript, it has become a very usable Java++ language.