jpittis

Keep in mind that "one zone" has durability implications:

> In the unlikely case of the loss or damage to all or part of an AWS Availability Zone, data in a One Zone storage class may be lost. For example, events like fire and water damage could result in data loss.

Not to mention large parts of the community using a pointfree, single character variable naming style that's hard to read. If Haskell could consistently be written in a more predictable style, that would be much more suited to collaboration IMO.

This idea of missing something simple really speaks to me.

I remember “factorization” not clicking for me for the longest time in public school. My grades slowly got worse, until the right teacher came along and explained it in a way that clicked. I proceeded to have a successful math focused education in high school and university.

I wonder if part of it is that kids are at the mercy of what their teachers want to teach / the curriculum. I think kids often know which things they struggle with… they need help articulating it, and then someone to work with them through it.

Quality isn't only sacrificed due to mismanaged loss in the pipeline. It's also at odds with delivery speed, feature breadth, cost, and itself. Quality is at odds with quality, because quality is not single dimensional!

I once plugged my Linux thinkpad into a projector via HDMI during a programming interview, and my laptop started smelling like it was burning. Never again!

Is Elixir really the general purpose productivity tool that comments here (and on other HN posts) make it out to be?

I've loved playing with Erlang and Elixir. The concurrency model and approach to failure are fascinating and clearly powerful for certain problems. Elixir's Pheonix feels as productive as Rails. I've read most of Joe Armstrong's books and watched most of his talks.

However, I feel like I can throw my daily driver programming languages including Go, Ruby, Rust... even Haskell at any problem and give or take performance, come out the other end with high quality software at scale.

When I last wrote Elixir, it felt great when I was doing basic Rails shaped work or lower level concurrency heavy networking (I was playing with TUN/TAP interfaces), but I really can't imagine it as a general purpose programming language.

For example I can't imagine scripting in Elixir, but I can and do in the other languages mentioned above. Also I remember trying to write a parser library and it felt way more verbose and unmaintainable than the equivalent Haskell or Rust.

This is hand wavy, but does anyone feel what I'm getting at? Any thoughts?

Hey antirez,

Your work that’s had the most impact on me isn’t Redis but kilo! It taught me how to have fun hacking on C back in university. Me and a couple friends cloned the repo and started adding fun features.

Here’s to more 1000 line whatevers! <3

Which means “bag” in French

I interpreted it more as a story about aging. I guess both!

It completely changed the way I write Go. This is editor specific though.

I use Vim for programming Go and have a few custom scripts built on top of https://github.com/fatih/vim-go.

To add to this, editor commands to quickly switch to your test file, auto generate test boilerplate and run the currently highlighted test are super helpful to speed up this loop.

I’ve often had similar feelings to you.

Something that blew my mind recently was using a Lisp repl which was integrated with my text editor.

I just wrote out the code I wanted to toy with in my text editor buffer, and then highlighted it and hit a key command to evaluate it at the repl without even needing to switch over to the repl window.

It would be so cool if we had great support for something similar in non Lisp languages.

Yup. I misspoke. We’re both right.

Having unwrap() in your Rust code is like littering your code base with panic(). It’s not appropriate to use in most production code, but is convenient in prototypes, examples and tests.

Your example re Go errors is incorrect. The go compiler allows you to ignore errors in returns without any compiler error.

For example

err := doThingThatErrs()

and

doThingThatErrs()

are both valid Go code.

> I typically find it very difficult to understand complex functions

It seems to me like "complex" and "ability to understand" mean the same thing, so this phrase doesn't have much meaning.

It's difficult to define "ability to understand" / "complex" without using either of those words in the definition. For example, you mention lines of code, nesting and multiple concepts.

I tend to agree with your examples, however not necessarily the lines of code. I've seen single large functions that represent an algorithm in a way that's easier to understand than the implementation that breaks it up into tens of little functions. It made liberal use of comments to explain each section of code in the function. I believe its advantage was that when reading, you could simply scroll down the function line by line rather than having to jump all over the file.

Good point. The article didn’t point out that Docker does have a valuable use case that as you say, can be solved in other ways.

> What is Docker for? You can take your old Python and Ruby and Perl apps and wrap them up in Docker, and thus those old apps can make the transition to the modern world of cloud computing.

There's no reference to isolation with namespaces and cgroups.

> There are older, mature options, such as Java and C# and Erlang, and there are many newer options, such as Go or Elixir or Clojure.

The JVM, BEAM, or Go process still needs to run on a machine and interact with an OS. They still need to be scheduled across thousands of machines that are constantly breaking. They still ought to be isolated from each-other when running on the same machine. There is nothing magical about these platforms that solves these problems.

It's interesting that there's so much resistance to Clojure given it's modern / being used in production a fair bit.

I've had a number of great experiences working on toy projects using Clojure but nevertheless feel resistance to adopt it fully "because of the JVM".

I've pinned my own resistance down to three things:

- Slow startup times. (Most of my use cases are not long running servers.)

- Not "unixy". (I write programs to run on linux and OSX exclusively and am used to using non-portable APIs maybe?)

- I've been lead to believe Java is "gross" and "enterprisy".

Really, of those three reasons only the first one has merit.

It kind of sounds silly when I put it this way: When I'm hacking on fun projects, I enjoy using a "hacker" language and Clojure doesn't feel like one.

One implementation you didn't mention that's pretty neat is Chicken Scheme [1].

[1] https://www.call-cc.org/

And then you get the lovely benefit of not knowing whether someone explicitly passed in zero or didn't specify an option at all. There are a lot of ways around this: Use pointers, specify default arguments, etc. I does frustrate me though whenever the language creators bless a hack approach to get around deficiencies in the base language.

> I think the smaller differences are also large enough to rule out extraordinary claims, like the ones I’ve read that say writing a compiler in Haskell takes less than half the code of C++ by virtue of the language

Specifically the "by virtue of the language" part:

Seems to me like it's unreasonable to claim the languages are on equal footing because fancy parser libraries aren't allowed to be used for the project. The fancy parser libraries exist for certain languages specifically because the languages enable them to be written. (For example in Haskell: monadic libaries, libraries that take advantage of GADTs, etc.)

Does anyone have any links to examples or docs for how the “binding operators” work?

Conj always makes me so envious. So many good talks.

This one, the Rich Hickey one on Maybe, the Stuart Halloway one on REBL.

Any other must watches?

Hickey: https://youtu.be/YR5WdGrpoug Halloway: https://youtu.be/c52QhiXsmyI

The Haskell style comma before the next element is soooo nice for adding and removing elements over time. I wish more languages used that style.

Your reference to "embedding the complexity into the code" makes me think of the first half of the "Out of the tarpit" paper where they discuss accidental vs essential complexity. It sounds like your "embedded complexity" is essentially "essential complexity".

I've read his book cover to cover and have enjoyed and learnt from a number of the concepts he discusses.

That being said, after recently reading "Out of the tarpit" and being a long time Rich Hickey fan, I completely agree that the model of complexity presented by the book feels simplistic.

I can't quite put my finger on why though. Maybe cause complexity in software has a lot more to do with understanding the problem domain rather than just the structure of the code. IMO it was worth the read, but I was slightly disappointed and it was without a doubt not a be all end all reference. (And it would be unfair to expect it to be.)

I feel like this is a problem rooted in Ruby’s mettaprogramming system. Class state (new methods, changed methods, inheritance hierarchies, etc.) and unexpected control flow materialize out of seemingly nowhere at runtime because you happened to load some library. There’s lots of power here but it would be incredibly dishonest to call it simple. (As you say, hard to track and explain.)

I find it really depends.

Small variable names for iteration variables and the `this` equivalent in struct methods are fine.

As for other situations... I guess it's an art?

Relevant blog post and HN comment thread about tracking space leaks in Haskell.

https://news.ycombinator.com/item?id=10263964