mmartinson

The problem is that it frequently detours from interesting discussions points to do things like dump on Greenpeace. Not interesting. Being elsewhere on the political spectrum doesn’t discount the interesting points, it just injects too many wacky ideas to make it possible to engage with. Ratio of density between interesting points and fever swamp ranting too low. Trash rag.

Y'all should enjoy drawing pictures and making mediocre music without worrying about how that relates to success or money. Your career is important, but it's only one part of a good life. Things that are enjoyable but unproductive often have a way of building skills and character that can later help you in unexpected ways.

> Humanities specialists argue that these majors open up higher-earning opportunities later in life because they don’t lock students into a narrow programming language, certification or career path. The critical thinking taught in humanities courses allows students to adapt to jobs that may not have existed when they enrolled in college.

I've experienced this exactly. I have a philosophy degree. I floundered a bit career-wise post undergrad, self-studied for a practical entry vector into a programming job, and 8 years later have a super rewarding career as a software engineer. I felt my humanities undergrad, especially the critical thinking and writing skills I developed, have helped me advance much more quickly.

If I were to change anything, I would have liked to do a CS minor.

> But chances are that a NodeJS back-end and one written in, say, Elixir, won't feel much different after the honeymoon is passed.

This is very, very far from my experience, having worked extensively with both of these particular examples.

At my current job I deep dive into a lot of years old, kinda sketchy Elixir code, and it's almost always less effort to learn/fix something than I've found in other languages, especially other dynamic languages. Except when macros are overused.

> Best strategy for becoming a high paying/good software engineer would be to think of yourselves as problem solver and language as just one of the tool for problem solving.

I'm not sure becoming a high paying/good software engineer are necessarily relevant to the stated goals of the OP's question. There can be inherent reward in working with a set of less popular, well crafted tools. Yes you might grow faster as a professional by working with a group of industry best JS programmers, but working with a small team building in Elixir and moving fast without ever hitting a NaN can be a pretty rewarding experience.

It's valuable to consider the opportunity cost of this compared to a deepened knowledge of an already productive tool

Out of curiosity for someone who is Canadian, what’s the assumed pull? Historically it would be income and career opportunities, but the tide has turned on that quite significantly in the last 5-10 years. Outside of that, it’s safe, clean, people are friendly, there are nice things. With a middle of the road tech salary the price of internet is a non concern.

That said, Canadian politics and crony capitalism are a grind sometimes, but looking over the fence it’s not totally obvious that other systems aren’t trading one set of intractable problems for another.

Nothing makes me long for boilerplate as much as seeing Ruby code with heavy use of metaprogramming.

fprof, recon trace, observer have proved to be the holy trifecta for me for debugging challenging production issues. I miss these deeply when working in other languages.

Having worked with both ActiveRecord and Ecto, Ecto is consistently easier to reason about and change than AR. It feels closer to the DB without compromising composability, and better avoids surprises. Ecto is IMO one of the killer features of the Elixir ecosystem that is undercelebrated compared to the neat things that are rarely used.

Recon trace is a worthwhile addition. I've used it for some hairy production bugs that don't reproduce locally. Allows you to unobtrusively instrument a running system and echo back function calls with their params, including process targeting if needed.

There are a number of powerful tools for BEAM runtime tracing. I prefer this one because the API is simple enough to commit to memory, and it protects against some common foot guns.

https://ferd.github.io/recon/recon_trace.html

More or less. Greater Vancouver suburbs largely unaffected. Farther out peripherals (Abbotsford, Hope) badly flooded. All regional towns and cities beyond those cut off.

I interview a lot of candidates over zoom for remote positions. For me, few to none of the specific details matter. What's important is if the candidate demonstrates that they've had the empathy and self awareness to consider how their call setup affects others' ability to communicate with them. All the suggestions in the linked article seem painfully obvious for anyone working in 2021.

I actually prefer when the candidate has some sort of uncontrollable distraction that comes up during the interview. It provides a good opportunity to see how they handle the real world challenges of remote work. For anyone not sure how to handle this, interrupting with "excuse me, I'm going to mute for 20 seconds while garbage truck passes" is completely reasonable, even in a fairly formal situation.

I’ve always found exercise to be a motivator for getting diet under control. Periods of low exercise correlates with bad eating. Building back the routine makes shifting diet much easier.

Ecto is a real unsung here of the Elixir ecosystem. It's a joy to build queries and changesets through composable data structures, and to know exactly when they're going to be executed against the DB. I miss it deeply whenever I'm working with a different ORM.

If anyone is curios and wants to get a high level overview, this conference talk by Darin Wilson provides a helpful intro to the patterns Ecto uses that differ from other popular ORMs.

https://www.youtube.com/watch?v=YQxopjai0CU

The sort of crash looping that took down their nodes is one of the parts of OTP that I’ve found to be both quite unintuitive and dangerous, for exactly the reasons described. There are controls for max retry attempts within a time window, but no obvious way from what I can tell to require a supervisor to halt rather than propagate a crash loop in a way that is easily auditable. This has caused me bad failures as well, and I’d be curious to hear what others are doing here. It’s not that it’s a hrs problem to solve, but that it’s an easy thing to overlook.

For anyone not from Ontario, "4 L bag of 1%" must sound pretty funny.

Which island is it?

I find this looks goofy, but other than the lack of physical buttons inside, this is a dream vehicle for me. Most weekends I want to drive 4 people + 4 mountain bikes a 120 mile round trip including fast highway and rough mountain roads.

Around where I live the preferred term is "cidiot". I find it to be refreshingly creative.

What are they checking for?

There are two pretty interesting things going on here. Firstly, if this goes through, it's going to force a bunch of people in Vancouver to reconcile some of their values in a way that's going to be pretty uncomfortable for them. Well to do urban-dwelling Vancouverites often hold the value publicly that reconciliation with First Nations and their right to self determination is very important, but they also really really don't like the idea of any developments changing the character of their neighborhood, despite the housing crisis we've been in for years.

Secondly, since the Squamish Nation doesn't need to follow a bunch of the typical city rules, they can do away with things like required parking spaces, and build more pedestrian space between towers with smaller footprints, and be open that they don't expect people living here will own cars. If the project and neighbourhood are successful, it could prove to be a pretty interesting counter point to the broadly successful development policies of the city that seem at risk of keeping up with the densification of the region.

I can take a stab at this. For context, my background is in Ruby, NodeJS, a bit of Golang and Java. I've been doing work with Elixir full time for the last 3 years.

I could probably write a novel about the things I like about Elixir, but here's what I'd caution about for someone looking at adopting it over another alternative.

- Elixir is not statically typed and probably won't be. If static types are a tool you value, Elixir's success typing and runtime assertions might feel inadequate.

- Pattern matching requires discipline to not create heinous coupling. Pattern matching is wonderfully convenient for control flow and helps a ton with readability and avoiding deep nesting in complex situations. It's so convenient, though, that it invites reaching through abstractions into data structures in ways that make code brittle. The language doesn't really provide any guards against this, so it requires care and policing to keep things manageable.

- Because OTP is so powerful, it's tempting to avoid industry standard tooling and "just do it in Elixir." This is great for moving fast, but has the risk of pushing problems down to the line to the point that bigger system rework might be necessary. Background processing is a good example here. In Elixir/OTP it's easy to do everything in memory, but once you start needing failover guarantees, or need split out worker processes from a web server for independent resource utilization, you may end up getting rid of the initial implementation and doing the work to move over to a setup similar to what you might using for Ruby or Node anyway.

Learning to be productive in Elixir isn't really a huge investment, even for someone with a strict OO background. It's pretty light conceptually compared to other FP languages, can be written in an imperative-ish style if needed, and has clear, simple patterns for code organization. For every place you would consider mutating, you tend to find primitives that make working with immutable data structures quite convenient.

I haven't looked at it since 2014, but this + codecademy took me from pedestrian interest in programming to writing prototypes

ha!

It's still a moving target though. Either you transpile, and your target is just a config option, or you are in the business of being super selective about which "official" language features are ok to use for your user base. I can't imagine the business case for anything but write-anything, transpileto whatever the lowest common denominator of the day may be. Outside of one-off scripts, I don't imagine many browsers actually will be running any these new ES features until they become a compile target themselves in 8 years.

What's your take on Node and backwards compatibility? Since you get to choose your runtime, is it valuable to stick with the same always-add, never remove approach as the browser? NPM taken out of the picture, I get writing one language everywhere would be nice. Do you just consider the bad parts to be the price to pay for not needing to keep track of the distinctions?

I've recently been working in Electron, and I find having app logic in both browser JS and Node to be more of a frustrating uncanny valley than a help. I suspect I'm in the minority on this one though, at least amount people with workaday skill set in client side JS.

I find these to be good points, but there is something missing for me that makes this "best possible scenario" only pretty good.

JS is a notoriously quirky and inconsistent programming language. Clearly it's sufficiently usable for writing complex, powerful and reliable programs, but it's error-prone for non-experts and encourages programming patterns that make importing accidental complexity the norm.

For many programming situations it'd be easy to just pick a different language, but obviously thus isn't the case for writing browser-based programs.

The best possible scenario for me would somehow involve deprecation and removal of the nasty parts of JS, and a path towards a smaller, simpler, more consistent language. Right now it feels like the cost of backwards forever compatibility is paid every day, in every project, and it's completely wasteful, given that transpile and polyfill is widely considered best practice.

Whether this could the job of TC39 or some other institution could go either way for certain.

Fair, JS is everywhere and serves many use cases. The implicit "we" in that statement is developers 2019 who are building client side applications that need to get a lot done, run in most installed browsers, and remain maintainable to a 5-8 year horizon. Not everyone for certain, but probably enough to generalize, at least on this forum.

> Basically when I'm figuring out what language features I care about, I'm thinking about how hard it will be for other engineers to work on the codebase. Things that are not in spec are going to be less familiar and more time to learn.

I agree, this is super important. My inclination whenever I did into a JS project has been to use lodash/underscore everywhere for everything, assuming that it is popular enough that someone will be able to maintain it without much headache, and I can actually get stuff done without breaking my brain over JavaScript's notorious quirks. I'm curious at what point this stops being a good practice. It certainly was 4 years ago.