If you could measure development performance vs product performance, witch would win?

Are you familiar with Gleam? I don’t know how it stacks up in terms of performance (though the Gleam web server, mist, has numbers comparable to Go), but as far as syntax goes, it’s Rust and Elixir’s child. Runs on BEAM, too, with all of the benefits.

I doubt it’s as fast as Go for CPU-bound operations, but that’s what FFI is for. (And most web servers are bottlenecked by the data anyway, aren’t they?)

Besides, that might not be the case for much longer. HVM is a runtime for functional languages written in Rust, and it’s very promising:

Higher-order Virtual Machine (HVM) is a pure functional runtime that is lazy, non-garbage-collected and massively parallel. It is also beta-optimal, meaning that, for higher-order computations, it can, in some cases, be up to exponentially faster than alternatives, including Haskell’s GHC.

What do you think about this?

They did you a favor by raising red flags during the interview process. @dimitarvp made a good comment - I hope you ran away, screaming :scream:

2 Likes

Wow, everything I wanted to say, you said it first and said it better than I would have :slight_smile:

1 Like

bespoke bytes… nay, bits

In my experience the absolute prioritization of performance over most other concerns is a fairly common mindset of a lot of “senior” developers, especially particularly talented ones. But I don’t actually think it’s a virtue, I think it’s their defining vice. At best they tend to build systems that are not easily maintainable by other people, but most often they are not even maintainable by themselves, to the extent that not understanding one’s own code is basically a meme in a lot of programmer circles. Of course the implication is that it’s a weakness, but most don’t see it as a weakness on the same level as a junior programmer’s spaghetti code. And maybe not, after all, it presumably is more performant, but personally I don’t think it’s so different. CPU time is cheap compared to developer time, and my time costs the same price whether I’m untangling spaghetti code or trying to decipher some guru’s over optimized implementation so I can refactor in a new feature, or fix a critical bug.

Don’t have a lot of exp with Go so I don’t know how it may or may not lend itself to this performance obsession, but I think a lot of languages suffer from not paying enough attention to developer happiness, on the pretense that the latter is exclusively the concern of lesser (less technically gifted) mortals.

2 Likes

I think this quality is directly reflected from the companies they worked at, I never worked at big corporations, but I saw that there is a big tendency to give their developers a lot of free time and when that happens development speed no longer matters, so they focus on things interesting for them, they start reading books about performance and some patterns abominations created by someone recently. I am saying this because I’ve had a few other interviews with people of exact same mindset from other big companies, those were asking me about things like algorithmic complexity and big O notations :grimacing: .

From my experience this is a facade in 95% of cases, just so developers can motivate their time spent on either doing nothing or making these abominations. I was lucky to work on a soft realtime system developed in elixir and it not only didn’t have any performance optimizations or special constructs, until the last day the bottleneck was somewhere else in the system.

2 Likes