Threads for gaustin
-
tschellenbach
3 years ago
|
link
| on:
Thoughts On Elixir: Pros And Cons Of The Most Popular Tool For High-Load Dev
The most popular tools for high load dev:
- C++
- .NET
- Java
- Go
- …. a thousand other things
- Elixir?
I use Go for everything, but I do realize that its by no means the most popular tool. Whats up with these Elixir fan clubs?
-
Whats up with these Elixir fan clubs?
It’s a genuinely decent language which is suited for web development and which has easy performance gains for devs used to Ruby or Python.
That said, the spread of it I believe is up concerted marketing efforts and (well-meaning) misinformation.
A lot of folks get to do “Proof By BEAM” when asked about their technology choice, saying something about WhatsApp and the BEAM and Erlang and waving hands while riding the coattails of a few golden and/or mysterious projects.
-
Elixir is a natural choice for existing Ruby developers/shops.
You get a huge performance bump, even with naive solutions. The syntax is really close to Ruby and so is an easy switch in that respect. Phoenix is a great framework.
If you go beyond that there’s lots of battle-tested gravy in the BEAM VM and OTP.
-
-
No fixed plans.
I hope to remember to pick up a book or magazine whenever the Internet seems empty…
-
Me and my friend are reading to each other out loud. We hope its going to help keep us more honest about that kind of stuff.
-
-
-
I thought I was alone in this.
I started a new medication around the same time I started trying to listen to books on my commute. Narrowly averted an accident, and so stopped the meds. Again, narrowly averted an accident and realized it was the books causing me to wander.
I can do music most of the time. It somehow seems to occupy a different part of my brain… unless I start analyzing. That wasn’t a problem until I started to learn to play an instrument.
-
You are definitely not alone in this!
I don’t drive, so I don’t have this problem, but I can’t listen to audio books when I’m at work for exactly this problem.
I either stop paying attention to the book or stop paying attention to the code I’m writing :) One or the other.
I even have to be careful about the kind of music I listen to -heavy lyrical content can totally distract me as well since I start parsing the lyrics.
Same reason I can’t fall asleep to TV like some people, my brain gets involved in the dialog no matter how AWFUL it may be!
-
-
-
-
-
-
-
-
Help team members when they’re stuck.
Plan your projects’ work.
Create new projects.
For me it’s unclear how this is specific to a senior engineer, I would expect this from anyone in my team.
One thing I left out is “make estimates”. Making estimates is something I’m still not very good at…
Being a senior developer is all about experience, and making estimates benefits from exactly that, work experience. I have to admit that making estimates how long a project will take is hard for me as well, but this should be definitely on the list of things to expect from a senior engineer.
Make sure work is allocated in a fair way.
Make sure folks are working well together.
Those responsibilities are on everyone in the team. If I see someone struggling with the amount of work they have then I try to help them. The same goes for working together in a team, if there are conflicts in the team then one should not wait on the manager to solve them (which is hopefully not what was assumed in the article) because this is how a Kindergarten works.
In general I like jvns’ articles, but this time I can’t take much from it. Those are only my 2¢.
edit: formatting
-
For me it’s unclear how this is specific to a senior engineer
I don’t want Jr engineers planning projects nor creating new ones. They can try to help other team members, but who knows how successful that will be, might just be tossing hours down a hole.
If I see someone struggling with the amount of work they have then I try to help them.
Again, I am not sure I want Jr engineers even attempting this.
if there are conflicts in the team then one should not wait on the manager to solve them
Please consider waiting for your manager or team lead – you probably don’t have all the information. Many attempts to “fix” stuff on a team of engineers makes it worse. Waiting for people with more information than you to give some external feedback isn’t the mark of kindergarten – it is the mark of maturity.
-
Agreed.
A further observation, I recently got promoted to manager. A coworker I worked with at a previous employer got promoted to lead engineer at the same time. Eventually, we both realized that many of the responsibilities we had both been considering “Senior Engineer” for years were actually what most folks would call lead engineer.
The gradient of skill levels can seem compressed when you spend a big slice of your career in a very high-pressure/high-performing arena. (Given the lack of diverse skill-sets, you might even call them dysfunctional.) Consequently, our ideas of what responsibilities are appropriate gets skewed.
-
I don’t want Jr engineers…
Again, I am not sure I want Jr engineers…
Ok, I said everyone in my team, but this doesn’t mean that there are only juniors and seniors, I was referring mostly to those developers with some experience who are in between both levels.
I don’t want Jr engineers planning projects nor creating new ones.
For me this is okay for internal projects of smaller scale and they should be involved in the process for larger ones.
-
Ok, I said everyone in my team, but this doesn’t mean that there are only juniors and seniors
Mentally replace “Jr” with “non-senior” if that makes it more clear to you.
For me this is okay for internal projects of smaller scale and they should be involved in the process for larger ones.
Involved in the process for sure, that is how they learn. Creating or planning, no. Smaller projects and internal projects both tend to grow and most of the cost of a project is maintenance, should never be entered into lightly.
-
-
-
-
often if i read about something invented in linuxland, i have to think about plan9, and how good some concepts would fit todays distributed computing.
-
-
well, you can compose your environment: take the filesystem from one system, the processing power of another and something else to use as terminal handling input/output, all by using a rather simple network protocol.
-
-
-
I have been doing remote work for 5 years and I think the “work room for work” and “don’t work in your pyjamas” rules are overrated. I am doing just fine typing this from my couch while waiting for a build to finish.
-
-
Same here; I think the rules for “transitioning from office-based work to remote work” are very different from “effective remote work for someone who’s used to it”.
-
I found out that when my home office became my work office my new home office was the coffee shop after working hours.
-
-
I work from home about 2 days a week (at my last job it was 3 to 4). I often didn’t shower until the end of my work day and I’ve never been in a place large enough to have a separate work room.
I do run multiple X servers. Ctrl+Alt+F8 is my work X11 instance and I have a different username for it. My git repos have my work/home laptops as each others remotes so I can push branches back and fourth without touching origin. (I often squash some of those intermediate commits before creating a real origin pull request).
I often find my time at home is way more productive. Open work spaces such and even my fancy noise cancelling headphones can’t drown out some of the chatter around me.
-
-
Everyone here seems like a morning person…
-
-
Hey, same as me! I kept trying to shift to an earlier schedule since bosses tend to prefer it. Brain just doesn’t agree with it. They and I are happier if they schedule me in a bit later to leave a bit later.
-
-
-
-
-
-
if it were up to me I’d work in fits and starts from about 10am to midnight. Unfortunately an office job comes with an expectation of visibility, and an attempt to travel at the same time as other road users.
-
-
The theme is nice, but with all the effort put into this, all the logos and all the branding does make it appear somewhat too commercial, imo.
-
Given I don’t have to pay for it and haven’t seen any ads, it seems more professional to me than commercial.
It does seem like an awful lot of effort to put into an editor theme. Better than the other end of the spectrum where someone builds a theme for their editor and then implementations for other editors get released with varying, often poor, quality.
-
-
This article has a very low quality: it reports on two not interesting facts (retrieving code via http and loading a DLL from current directory). Why is it upvoted so much?
-
Two relevant points at least: (1) an unverified binary is downloaded and installed and (2) on Windows outdated and likely exploitable versions of OpenVPN and OpenSSL are installed.
Then there’s the other more trivial stuff in the article that may or may not be interesting.
Despite the abrupt nature of the article, it seems worth talking about.
-
Yeah, I’m kind of appalled that the author completely glanced over the setup step where you download the script asking you to send your password over an unsecured connection. Forget about a man in the middle attack that switches the script, all you need is to log the HTTP requests and you get the user’s password.
-
-
-
-
-
I think it’s great that you posted this. More people should speak up about it. I also liked that you called out the potential for ableism. It’s ironic that an industry that professes to value diversity goes and shoots itself in the foot with exclusionary tactics like this.
I just found out the company I’m working for is setting up a 4month engagement to build an app with Pivotal, which is all XP. Im excited about the project but dreading having to do pairing 8 hours a day… funny thing is I’ve actually introduced a lot of pair programming into the company and am certainly a proponent of it but only for 1-2hrs a day and in certain situations (onboarding, difficult problems, etc).
-
-
I kind of feel like Elixir is a fad which adds complexity - if you want to use erlang, just write erlang.
-
It’s certainly a fad, just like Ruby and JS. Which is to say something that is going to deliver a ton of business value over the next decade and foster its own pop culture in a feedback loop we’re all accustomed to.
As someone who learned a good bit of Erlang 10+ years ago, I was initially worried about added complexity. Especially after being burned by the CoffeeScript nightmare.
I started writing Elixir daily at work about 10 months ago. A couple weeks of using Elixir disabused me of that. Elixir is a really seamless implementation and provides valuable support for everyday programming. The only reason I might end up reading Erlang code is if I have a problem with a dependency.
If you’re a glutton for punishment you can call Elixir code from Erlang.
-
Saša Jurić wrote up some excellent points about why elixir. Not saying we all should do it, but there are some advantages, helpful features and superb Erlang interoperability.
Another thing that I enjoy about Elixir is the community. Not just the people, but the community is a “melting pot” different communities - Erlang and Ruby mainly but there’s also a good amount of people from Haskell, JavaScript and others. Together ideas meet and new concepts and ideas emerge.
-
-
-
For user login they suggestion going from:
User u = UserService.login(username, password);to
User u = UserService.getUser();And claim the latter is better. But what happened to the username and password? Where is the user that is returned from
getUserstored? They also make this vague claim that in the first version it’s unclear what you should do with theUserwhen done, “should you log it out?” etc. Ok, but how does the second version solve that problem? How is it clearer that I should or should not log the user out? I don’t see how this is better. It doesn’t even make sense to me.Maybe login() returned the User so it could return null when it failed? We are tempted to return error codes from a command if it fails to change state. But it’s better to throw an exception, maintaining the convention that commands return void.
Why? If you’re language is good and has a
resulttype why wouldn’t I use that instead of exceptions? Comparing exceptions tonullis a pretty poor comparison.This post is pretty crappy. How do I do anything that requires giving me a proof of my success? For example, logging in often returns a token that you can use in future requests as proof you logged in. What about atomic operations? There might be good reasons to use Command Query Separation (I haven’t seen one) but this article does not make a compelling case.
-
I agree. This article fails at a basic level. I don’t see how it really introduces or advocates the topic.
Just by the name alone (and the “rules” listed late in the post) I would expect you to login a user with one call and retrieve a logged in user with another.
In the error handling discussion. Why not use the NullObject pattern?
-
The point is to separate it into two steps. One that gets the user and one that actually does the login:
User u = UserService.getUser(); u.login(username, password);A clear delineation of usage. If you want the token, you ask for it. No reason to return it here.
Token t = u.getLoginToken();No side effect, no confusion, no (possibly) unnecessary value returned.
-
That API is not any better as you’ve created a new way to make uninitialized variables, which are fairly universally considered a source of bugs. What happens if I call
.getLoginToken, or any other method, on a user that has not had.logincalled on it or failed to login?If I were confronted with that API the first thing I’d do is wrap it in a function called something like
doLoginwhich wraps getting a user, logging it in, and returning it. I never want to see a user that hasn’t logged in.If you want to go CQS on this, you probably need a
LoginRequestobject which has.loginand.getUsermethods, that way I can only get aUservalue after it’s logged in. But, again, I’d wrap this up in adoLoginfunction because theLoginRequestobject just exists to live up to CQS and isn’t really providing any value.
-
-
-
I find it especially difficult to distinguish between personal and company time being full-time remote. I might sleep in an hour or two one day, and work until 9pm. It isn’t until I realize I’ve sent a work-related email, timestamped at that hour, that I pause to think “does this set the expectation that I or my peers ought to be working this late?”
I wonder if it would be appropriate to say something like, “hey, I worked pretty late last night, so I’m going to knock off early today” in order to help set the expectation that while I may sometimes choose to work extra/different hours, I am still keeping an accounting of my time spent.
-
I’ve worked on a remote team for a long time, and no matter how mature the team, people still do pay attention to the timestamps in emails, unfortunately. I wish it weren’t the case but I haven’t come up with a good solution, short of scheduling my emails to be sent out the next day, instead.
-
-
-
-
My office is in an orchard – one hundred yards from anyone. No one bugs me. If I roll down the outer (metal) door, I don’t get cell phone service, which can be handy.
http://logonpro.com/office.jpg
The walk to the soda machine kinda sucks.
I’d show you a picture of my big monitors inside, but which part of “Private Property” don’t you understand? :)
-
Oh, but even though the soda machine is not nearby, the hen house is.
http://logonpro.com/office-desktop.jpg
How’s that for glossy architectural marketing photos?
-
-
Thanks for asking.
Office is one end of a 40ft x 8ft cargo container. Here are outside photos. The remainder is used for storage.
Construction was basically framing-in the inside of container. The floor is made partly of wood, so that helps. Then adding electrical, insulation, window, door, and drywall. The container came with a light “rollup” door on the office end. The framing is a little over-engineered since it’s not structural.
- http://logonpro.com/images/office-construct.jpg
- http://logonpro.com/images/office-construct2.jpg (yeah, that is a Donkey Kong)
- http://logonpro.com/images/office-construct-ceiling.jpg
I am a slob, so I have no nice inside pictures. Here is an early one, although, now I’ve added a few bookshelves on the walls above the table.
-
-
- Grade spot for container, gravel base: $300
- Slightly used container, painted, 2 rollup doors, vents, delivered: $4125.
- Framing: $600 incl labor.
- Electrical: $200 (not including labor)
- Insulation: $100
- Door, Window: $200, used
- Drywall: $200
- Air-conditioner: Had one lying around
- Ceiling fan: $40
- Permit for installing container: Depends on location.
- Other permits: Depends on location.
NOTE: You may not be able to obtain building permits for this type of project, depending on location.
-
-
-
-
-
-
We tried this where I work and didn’t get much value from it. We were either doing speculative refactoring that wasn’t necessarily as high value as we initially thought or we just didn’t do it at all because of other time pressures.
We even had some refactorings that we didn’t end up merging because the scope of change was so huge we weren’t comfortable they were correct. We did eventually get those changes made, but in smaller steps over the course of a number of releases. You could say “write more/betters tests” and “be more confident” but the reality is smaller steps was a better way for us to maintain our comfort level and production stability.
What we found did work was to take the time to refactoring as we did our usual tasks. This resulted in changes that addressed pain points as they were encountered and in a scope proportional to that pain.
In the end I guess it’s our fault the dedicated refactoring time didn’t work out. However, I do think we converged on a practice that gives us more or less the same benefits.
-
That was actually one of my concerns with the idea (the post is not mine, I just found it). It seems that this is a practice you might make temporary. Perhaps when it is apparent that you have a piece of code that your team is working on that has a lot of cruft to it.
With regard to your mention of comfort with large-scale refactoring, I never feel comfortable with it unless there’s a pretty robust test suite or at least you have validation rings (I work on a service and we can test that sort of thing on <1% of machines).
-
I’d really like to see some evidence that elixir is the most popular tool for “high-load” dev.
Maybe not Elixir, but Erlang is pretty popular: https://twitter.com/guieevc/status/1002494428748140544
“90% of internet traffic goes through Erlang-controlled nodes” and Cisco ships 2M Erlang devices per year.
Elixir is in a certain sense just some developer friendliness on top of the Erlang VM. Still, most popular for application development? Probably not, but I’d say definitely mature enough to handle whatever you want to do with it.