You can hire any senior dev and give them the elixir book and a week to read it. You can also pick up someone junior who hasn’t learned anything wrong and coach them for a few months. I’ve successfully done both. The org I work in was one of the Elixir lang case studies and we still love using it, and have very little trouble hiring. It would be different if we had to hire 50 devs in less than 6 months, but we just don’t need to do that.
That's great, but pretty tangential to my point. The person I was responding to seemed baffled that hiring Kotlin devs would be perceived as easier than hiring elixir devs, which is itself pretty baffling given that Kotlin is one of the top 15 most popular/used programming languages and elixir rarely even makes the list.
Elixir is a functional language, which is definitely a less common paradigm than OO languages like Java, which Kotlin is very similar to. Plus you can hire Android devs.
Yeah of course, but the FP stuff is not very complicated in Elixir land. The heady stuff from ML family languages just isn’t there. The process model takes some time to adjust to, but a lot of JVM folks have used akka which is inspired by the BEAM.
The tooling an docs all guide you in the right direction and usually code in the wild aims to be straightforward.
I’ve really never had trouble onboarding people to Elixir unless they had started learning it solo as a Ruby dev, then they typically have to unlearn some stuff.
If you are getting your daily dose of HN comments for a long time like me, you may also think there would be not a single dev that chooses Electron to develop desktop applications.
You're hanging around crowds that talk about FP. :)
Right now I'm working with a team where we're trying to introduce FP and reactive programming, and most of them have never heard of either one, or if they have, have never really used it.
functional programming overall isn't that difficult. day to day elixir work doesn't require you to understand currying, abstract types or monads. If anything it really only makes you pickup immutable data, pass by value, immutable bindings (with implicit lets)
Functional programming gets really hard when you try doing stuff like state and IO monads. Elixir in contrast gives you genservers for state which is very simple by comparison as well as having dead simple IO. you don't have to make special functions marked as IO or use any type of exotic type theory.
TLDR: yes Elixir is functional but its the 80% that is easy to learn. you don't have to bother with that last 20% of functional programming rabbit hole crazy town.
source: me with 6 years of elixir experience and having built the entire backend for my startup in elixir over the last 3 years. Elixir is s a platform that fits a nice sweet spot where you need to knock something out fast and still have something reasonably maintainable (and refactorable) that also happens to be really fast(performance wise) for the level of day to day developer productivity you get.
better is subjective so I'd rather not go into that too deeply haha.
Its all about the tradeoffs you're going after. If you absolutely need to cut down errors to a minimum and are willing to sacrifice developer speed/productivity, Haskell with IHP is certainly a compelling offer. (yes I know an experienced haskell dev will probably be jsut as productive as a experienced elixir dev but it will take much longer to train someone from another language to haskell than to elixir.)
conversely, if you want speed at all costs, rust is certainly nice.
now if we're talking Pareto efficient intersection of performance, developer productivity and maintainability, yea elixir hits that sweet spot well. I haven't encountered a language that does that better yet. Python comes close if you're willing to take a drastic hit on performance. The tooling is descent, the day to day ergonomics let me focus on solving our startup's problems rather than wrestling with the platform. It's not perfect (lord knows I wish there were more libraries).
Man I joined an elixir team to start my engineering career and while I love the language, and it isn’t too hard to pickup and read until you have to start mocking stuff and all the &’s start popping up. But still the pipelines and functional approach was solid.
The problem was actually getting the stuff deployed or running into weird niche issues that require a couple days to fix. I was a bit out of comfort level at that point but the exaws sdk’s, confex, releases, supervisors. Made me really appreciate how much more support and just easier mode/python has been in my current job.
Just a question when you are hiring and posting job descriptions do your job posts use language like "6 years experience in Elixir" ?
Reason I'm asking is because I love this attitude and I think it works so long as your team will provide the support for someone to ramp up, but I seldom see these kind of job posts saying we're fine if you learn the stack.
I share the parents attitude. My job postings though don't say explicitly that we are fine if you learn the stack, however they list the stack as nice to have rather than must have.
IMO, everyone needs to learn a from of stuff for every job. Thus understanding of high-level concepts and ability to learn are paramount. If you tell me though that your primary language is XYZ and you cannot answer basic challenges with it we encounter during the interview then that's a really bad sign even if I don't care much about that actual language.
Seriously, there are so few circumstances where a good developer absolutely requires deep experience in a specific language (or framework) on day one. Smart people can learn, and they can learn pretty quickly if it's not radically different.
I'm currently doing a ton of C# work and it's great - my relevant professional background is basically all C++, with some Java in the very distant past.
Yeah, I mean I hired a great Java dev to do Go work and she picked it up in 3 months... but I knew she was awesome, so I wasn't worried about it at all. But hiring someone you don't know, which is typical ... retraining in a new language feels like it surely adds to the already substantial risk of hiring.
I think everyone in this chain should admit that hiring the kinds of developers you can 'throw x language book at' and a week later you have a competent x lang developer is an incredibly expensive and time consuming processthat most companies will never be able to afford.
Even if you can, you then have to solve the issue of keeping a department stocked full of senior devs happy when you have limited promotion/perk/raise options and so churn will likely be relatively high even in a healthy environment.
It's a nice fantasy view of the market as an ideal world simulation but does not reflect the reality of hiring software engineers.
You can't buy a book, keep it on a shelf, lend it to new hires, and afford to have an employee take a week out of being productive to learn something? Or you can't afford salaries for a company of people who have more than 5 years of development experience?
I think it really depends. If all you're doing is slinging JSON over an API then sure.
If you're dealing with concurrency and distributed systems at medium to high scale you really want your senior people to be familiar with the language.
On the contrary, I think that people familiar with generic concurrency and distributed primitives will easily transfer their knowledge between languages (I mean, a race is a race, and starvation is starvation...), whereas you can be very senior in a language yet never experience the edge cases of parallel programming.
Sure, each language has different tools to solve corresponding issues, but I prefer to understand the problem I am solving to intimately knowing the tools I need to use.
Unless they have experience in the language runtime handles them, and how they might differ across implementations, they are in for a surprise when debugging parallel code.
I’d argue the language matters even less as folks with true experience in distributed systems know that the real problems arise between thread/ process/host boundaries which are mostly language-agnostic.
>"If you're dealing with concurrency and distributed systems at medium to high scale you really want your senior people to be familiar with the language."
I've written my first application level thread/concurrency library for DOS in the 80s. So you can count me as experienced. In my opinion as long as one is senior developer and knows the subject language does not mean fuck all as long as it adequate and language / libraries support needed primitives. I've written distributed middleware with multithreading / concurrency in many languages including ones I did not know before starting the project.
You can challenge anyone with this type of arguments. I was doing this kind of programming and delivering successful solutions since the 80s. If you chose to doubt my expertise it is your right. Does not mean your opinion has a shred of truth in it.
That can be mitigated by hiring senior engineers that understand engineering leadership, and having competent engineering management to specifically encourage knowledge transfer.
Kotlin is actually booming in backend, especially in financial services/fintech. Most are converted Java programmers ofc but many are also new to the JVM coming from Ruby/Python/etc.
I suppose part of the concern is finding people who actually want to use your tech stack too, though.
I interviewed a company a while back that was using elixir which I thought was cool, but I ended up not taking the job. Part of what worried me was realizing just how much they struggled to find interested candidates, and it seemed like they were willing to compromise to hire as a result. Perhaps I was a compromise, haha.
The CTO and other devs on the team painted a bleak picture of building the team, and elixir seemed to be the main obstacle.
The other issue they faced, though I doubt it was as much of an obstacle, was that they were working on pet insurance. That was a major deterrent for me. The compensation and working conditions were excellent though, so I suspect many people wouldn’t care and would gladly take the compensation and flexible work life – were it not for elixir.
I found it surprising but I’ve seen people work on worse things for less money using more popular languages. Perhaps more people are afraid to learn something new than it seems.
I had never used Kotlin before but picked it up day 1 of the job easily and was committing and pushing PRs immediately. There’s always a few gotchas with any language but Kotlin to me was basically JS/Python meets Java. Pretty trivial to get going - always some nuances to learn but contributing was trivial.
I have no idea about Elixir but it doesn’t look as conventional.
What is the IDE support like in Kotlin? I've never had to look at it professionally. I use VSCode because it works much better with my screen reading software then IntelliJ. As far as I can tell to get a decent develop experience IntelliJ is your only option?
Not a backend dev. At least Spring officialy supports Kotlin since v5, and I see most Java devs (including myself) have little difficulties migrating to Kotlin.
Scala or Clojure, on the other side, is more radically different.
Kotlin in is very similar to Java. There are tons of Java devs. And tons of Kotlin devs who program for Android. There has to be an order of magnitude of magnitude (at least) more Kotlin devs than Elixer.
I think for the same reason Vue.js is more popular in China than almost anywhere else. Chinese was also the only non-English docs language at the beginning.
Lua is pretty nice, especially if you can use the JIT. I think there were some elixir consultancies in Brazil other than Plataformatec that did a lot of work in finance so it spread around.
We do LEAN and “agile” where I am now, and if you can’t explain how your work makes it saves money you’ll be gotten up to speed on that quickly. Our business folks are very sharp and focused, and tech tries to match that, in a good way.
Saving some should be in the service of the former, and only as one of the tools in your arsenal (obviously, creating a product or service people would pay for should be the first).
This honestly seems like an example of how to handle layoffs well. After the repeated messes of Better, the non-layoff layoffs at Meta, and a bunch of smaller examples over the last year and a half, it's actually nice to see them handled well.
They always suck, but being transparent, ripping the band-aid off, and giving the people laid off as much support as possible is the way to go. They're also far enough from the holidays that people can still job search, but close enough that most people in tech could eat a few weeks of savings to take an extended holiday. Don't know if that was deliberate, but it seems well timed
Yea, if you look at the benefits for those laid-off, it's pretty supportive (at least from my American experience). They are paying at least 2 months severance, you keep your hardware, you get 6 months healthcare, and they weren't dicks about doing this. I would say this is better than most recent layoff announcements and the fact that they even state that they will re-hire anyone later on as a priority shows that they aren't trying to blame "low performers" or something, it's just some colleagues that they can't keep on right now due to business reasons.
Now, maybe their business reasons are dues to their own ineptness or bad luck or whatever, but they handled this pretty well.
I say this all because we tend, on HN and other places, to focus on the shitty aspects of every bad news story, and rarely speak up when something goes right that is still shitty, like this.
Letting employees keep computers seems pretty rational. It generates goodwill, and if the company demanded the computers back, they'd have nothing to do with most of them (except newer ones that could be given to existing employees who happen to have older machines).
They could sell them used, but not for much (especially after paying for prepaid shipping boxes).
Remember that it you give the employee the computer, you need to pay payroll taxes on the value of the computer, and the employee needs to pay income taxes on the same.
That's why many people reject 'free' gifts from their employer.
Due to the way depreciation works, it ends up being a minimal impact. When my wife left a university job after 2 years, they sold her the laptop she'd been using for about $250. It wasn't high end, but this was about 25% of what it cost new, and 35% of what it would have cost my wife to buy a similar computer new at that time.
Being taxed on a couple hundred dollars is roughly the cost of a dinner out. It is definitely better to accept a free computer at such a discounted valuation and turn around and sell it. In no event would you come close to losing money — the taxable value of the computer would be far lower than what you could sell it for, and your tax on the taxable value would be just a fraction of that.
Especially companies which claim to have solid runway blaming "the macro environment" is perplexing.
But then, venture capital backed companies generally (arguably by design) are not profitable, so their ability to weather storms is likely weakened and maybe the boards get squirrely when faced with the threat of bad weather.
Promising but pre-profit VC-backed companies don't want to raise in the next 2-3 years since there is a huge risk of down-rounds. Everyone is trying to squeeze their runways out over that time period.
Unfortunately, if your customers are mostly other tech companies, they are doing the same thing.
It seems like a bunch of healthy companies are putting on the brakes hard enough to collectively cause the recession they are trying to avoid.
They spend every cent (and then some) on growth. The model is to capture the market. You have to spend to do that. Once you do that, you can set the terms.
Also, it happens to bring growth company valuations and a nice exit. What happens after that (ie if the entire thing was unsustainable), honey badger VC don't care.
You also don't have a choice but to play the game. If you don't, your VC funded competition will outspend and destroy you.
> Meanwhile unemployment is still at an all time low.
That is incredibly circular logic. So companies shouldn't be doing layoffs because unemployment is low?
Are you arguing that the macro environment isn't bad? A G7 country is in a mexican standoff with its bond market and pension funds to avoid a systemic collapse in the next 3 days. How much worse is the macro situation supposed to get before businesses should worry?
The economy _is_ to blame if your business strategy is to burn VC money at a faster and faster rate, which is the goal of most billion dollar growth stage startups. I know HN likes to rip on these types of businesses, but that is literally the strategy. You can not like it, but blaming it on incompetence is foolish.
When the economy turns you have to adjust that strategy, which is what they are doing now.
I’d be curious what the numbers look like in the next quarter, also I recall that the US has some absurd definition of unemployed that conveniently undercounts the unemployed.
That said I think the real story now is that the previous recessions haven’t really impacted the big tech companies, but this time it is so we’re seeing the first mass layoffs that this generation of developers has likely ever encountered. Couple that with the “tech” companies that are essentially just advertising companies that write software (obviously FB and G, but many of the startups aren’t too different) discovering that attention based advertising isn’t as stable a revenue stream as was thought, and you get a _lot_ more “safe” jobs disappearing.
The percentage you see flying around doesn’t include people who aren’t actively looking for jobs u-3.if you include them it goes to 4.4 go to bls.gov and find alternative measures of labor underutilization. Its not undercounting just different levels/definitions of unemployment qualifications
Right, but there's all sorts of issues in how that is counted. For example if a person is stuck in a town where there are no jobs (say a large employer going out of business), that person isn't looking for a job because there are none, but then they also no longer count as unemployed. A person who just got laid off and is having a break on their termination benefits is also not "unemployed".
But there's also just simple lag on the unemployment numbers as companies like Facebook, etc have only just started large scale layoffs.
As a side note, I am curious how much the less fragile companies are going to be using current events to get rid of "expensive" or "unproductive" employees. Previously companies got around legal reporting requirements by simply laying off people in groups of < N people where N is a legal "laying off N people in X days must be reported" - do "current macroeconomic" effects provide a different path? I write code, not legal docs so know nothing of such things and am kind of curious how it goes
The "the government is lying about unemployment" narrative is foolish. The number presented in most media headlines is just one number that the government publishes. Right alongside U-3 they publish numbers using definitions that include more people. It'd be a pretty stupid conspiracy to lie and publish the "true" numbers right next to your lie.
Both U-3 and U-6 are near historical lows. Even if you don't believe that U-3 is meaningful, you can compare the U-6 numbers now against other times in history and see that unemployment is indeed low right now.
I mean the feds goal is to raise unemployment at this point (to slow down inflation) so in that sense this the fear of a recession is in fact creating a recession?
Is this something openly known or just some kind of guess from you? Jez, if we've reached the point where the US goverment forces unemployment (with all the suffering it implies to ordinary people) in order to protect the overall economy (the elites and goverment itself)....if that's not something to make everyone to lose any remains of faith on the system then I don't know what it is.
It's a good racket if you can pull it off. Start some kind of "disruptive" company, raise a shitload of money off being 6 foot 4, hire 1,000 people to "disrupt" shit (they don't even have a banking charter!), cash out tens of millions of dollars at the Series D, write a tearful mea culpa when it all falls apart, buy the estate in Hillsborough and the Bentley Continental and try it again in five years.
I met with the founders sometime in the second half of 2017, I think before they had launched. I was looking for an eng leadership job and the just wanted / needed ICs. So it didn’t go anywhere.
But I came away with a strong sense that they would be quite successful. They just had this confidence and clarity of vision, that also didn’t seem like bullshit. And past experience building a company in the financial services space.
One funny thing I remember was Pedro (I think) saying their tech stack was Elixer, “maybe that’s crazy”. And interesting to see they have since started moving away from it. Seems they had some doubts about it from the start.
Of course, it was a flippant remark, but it's more that there are some people who have the right "polish" (looks/Stanford/wit/connections/etc) and they can raise hundreds of millions of dollars for their companies regardless of whether it's a smart investment.
AFAIK, typical banks don't provide virtual cards you can spin up on a click to give to your employees for expenses, right? My company uses Brex and the few times I've had to use the card, it was really convenient.
I'm not a user, but from the marketing, it seems like a product that's "nice to have", not a "must have". Normal banking and corporate cards can pretty much do all of what they do, albeit with a slightly worse user-experience.
Businesses like this are skating on thin ice. People are willing to pay a premium for design and user-experience when the times are good. But when they're not, these "nice-to-haves" are first on the chopping block.
> Equity: For those with less than one year at Brex, we’re waiving the equity cliff. For those with options, we’re offering to extend the exercise period to seven years.
I wonder how they could have arrived at "seven." Why not go with the max allowable of ten? This seems a bit miserly in an otherwise pretty decent package.
Sucks for those who were affected but when Brex pivoted from small businesses to well funded startups and shut down 10s of thousands of accounts, I think the market lost all trust. Ramp & Mercury provide way more value now. Absolutely no reason to use Brex anymore.
I think they also pivoted from doing individual cards to just corporate. I had a Brex account and card and they ended up closing all that off. I never got around to using it. I did find Mercury Bank to be pretty good for a business account FWIW.
I don't think 11% is tiny at all. According to the article, that's 136 people. At an extremely low-end conservative cost of $200k per employee (I'm sure it's more than that), that's nearly $30M per year. If they truly believe that $30M wasn't being spent well, that's good money saved.
lay-offs 2 years ago
Switched tech stacks 11 months ago to among other things be able to hire more devs
Acquired Pry for $90 million 6 months ago
Were tossing out long standing customers 4 months ago
and now they're having lay-offs again.
Quite the ride...