>Should colleges be putting smart speakers in dorms?
No.
From the top of the article:
>Administrators say installing listening devices like Alexa in student bedrooms and hallways could help lower dropout rates.
No. Stop. Just stop.
In fact, I think installing these devices in the offices and conference rooms of administrators is a much better idea albeit just as <s>minimally</s> equally thought-out.
I picked up _Programming Erlang_ because I like Joe. I'm trying to understand why the platform, and the accompanying language(s), aren't more widely used? People seem to speak very highly about Elixir, BEAM, and OTP. It all seems really great...
I see comments like
This:
>A very interesting language on powerful platform with a promising web framework... I talked with a couple of companies that jumped on it initially, but later decided to move...
And this:
>I recently had a convo with a company that moved into Elixir because they had an easier time hiring...
I see this comment pair somewhat often.
Also,
From @hajile
>BEAM is about an order of magnitude faster than Cpython ...If you prefer Ruby syntax over Python, there is no contest here.
>BEAM is slower than the JVM, but much more stable.
The second quote seems to be a pretty reasonable trade off (my next question is, how much slower?).
This makes a lot more sense to me:
>Functional programming in general seems to be a bit of a self-selector.
I like functional programming, but experiences do tend to be either: "I love FP" or "Eh, not for me."
But are these it? I've been getting into erlang lately (to then get into elixir), but I feel like I've been "waiting for the other shoe to drop." As in, I'm wondering if there's some disadvantage that doesn't get talked about. Are there any engineering blogs that talk about using BEAM/Elixir/et al in production?
Honestly I think you are doing things backward. With all due respect to the fantastic platform and vm that the erlang folks built, it's just not as joyful as elixir. And I feel like writing legible and organized code is easier in elixir since it's opinionated, about everything from directory structure to documentation to tests, and a couple of detailey things like structs are easier to read than records and macros are more sensible than string preprocessing
Definitely agree, though I respect the effort/desire to learn Erlang first given the fact the first time I saw Erlang code I was so confused/put off by it, the syntax was so foreign (not c-like, not lispy), variable names up capitalized, atoms are bare words, source files are just tons of functions, the tooling isn’t anything like modern languages (though since Elixir and hex/mix, that situation has gotten way better), then you’ve got all the OTP behaviors which are entirely unique to Erlang/BEAM, Erlang’s documentation though excellent and extensive isn’t by any means beginner friendly (IMO), and to top it all off, unless you’re coming from another pure functional language you have to deal with working in a new paradigm. Basically, Erlang is intimidating, which is unfortunate because how powerful BEAM and the OTP behaviors are.
However, Elixir wraps up the power of the BEAM and OTP in a much more approachable package. The syntax is much more familiar (thanks Ruby), provides tooling on par with (and better than some) popular modern languages, the language itself also provides more modern user friendly features (macros, pipe operator, protocols, etc). All with a community that is very beginner friendly and willing to help.
If you want to make use of OTP/BEAM, Elixir is by far the best way to enter. When you learn Elixir, you will also learn the major OTP behaviors and concepts (Supervisors, GenServers, Applications, Registry). Eventually you’ll find that there are even more goodies in the beam not directly exposed by Elixir (genstatem, ets/dts/menisia,timer,digraph — are a few of my favorites). Fortunately though, you can call Erlang modules/code directly from Elixir (and vice-versa), so you’ll then eventually dip your way into playing with Erlang modules as needed and when you approach the docs after having experience with OTP with Elixir, you’ll notice a lot of things are familiar and the Erlang docs become much less intimidating.
Basically Elixir is a much easier entry point to Erlang. Erlang is a great language, but very different with a lot of new concepts and which can kill your motivation to learn how awesome the BEAM is, so if you want to learn Erlang, by all means give it ago, but if you find yourself frustrated/confused with it, try Elixir for a while, then come back to Erlang and I bet it will be a lot easier.
When I initially saw Erlang, I was put off, the docs were confusing and I would avoid them at all costs, always try to look for an Elixir wrapper. Now after having worked with Elixir a lot? I frequently find myself going to the Erlang docs first to find a solution instead rather than hex or whatever. I can easily grok my way through an Erlang projects source, which previously was completely foreign to me. Will I ever likely write anything serious in pure Erlang? Probably not. Am I saying if you learn Elixir you will also just pick up Erlang? Absolutely not. What it will do though is make the process of learning Erlang (if that’s the goal), and it’s absolutely massive built in library of tools/abstractions/patterns that no language I’ve seen comes close to replicating an order of magnitude easier.
You may like this: the very odd gen_statem callback pattern exists to group different callbacks by state (which you can't do because you need to group like headers together). But in Elixir, we use modules and macros to organize our code more sanely and less ad-hoc-ey:
I've only had 2 complaints with gen_statem, the docs were initially some of the most confusing/unclear and the state_functions callback mode (which I think partially is to blame for my first complaint as I was expecting a more gen_server like api with handle_* functions -- which exists but the docs use the state_functions for most of the examples and the handle_event just kinda getting some "oh by the way this exists" examples). I actually initially decided to just keep using gen_server's with a "status" or whatever value in their state as I figured it was good enough. At some point over the next few weeks I actually ended up having this talk[1] pop up in the recommend videos, and I figured I give it a watch to see if it would help make sense of gen_statem or at least just confirm that I don't need it. And while watching it, once he started explaining actions (timeouts, state_timeouts, postponing, etc) I realized that gen_statem literally solves so many problems that I've had in the back of my mind on the project I was working on like "I should figure out a way to change the state of A and do something when it doesn't receive any messages from X,Y,Z processes" (gen_statem's timeouts!) or "how should I handle messages received while attempting to recover, I guess I could put them in a queue or something..." (oh, gen_statem will let me postpone them until it's healthy!). It took a couple more re-readthroughs of the docs to fully grasp, but now it gets included in almost everything I work on, it's so useful (though I guess I should've assumed those were already solved problems by the BEAM/OTP as usual).
However, now my biggest complaint about Elixir is that gen_statem didn't get any official wrapper. StateServer looks like almost exactly what I would want out of an official Elixir wrapper. I also like to see the addition of `handle_continue` as well, because the first thing I did before migrating any of the gen_server's to gen_statem's was create a small wrapper module to a) make the handle_* return values more in like with GenServer's (basically just making it {:(no)reply, (transition|keep), data, [actions]}) and b) add a quick and dirty handle_continue callback because I use it all the time with GenServer. And this literally just looks like a more polished version of that, so thanks!
> I picked up _Programming Erlang_ because I like Joe. I'm trying to understand why the platform, and the accompanying language(s), aren't more widely used? People seem to speak very highly about Elixir, BEAM, and OTP. It all seems really great...
Watching videos of Joe talk super impressed me. He kept the same enthusiasm for programming as any college age programmer. That's impressive!
> From @hajile
>>BEAM is about an order of magnitude faster than Cpython ...If you prefer Ruby syntax over Python, there is no contest here.
>>BEAM is slower than the JVM, but much more stable.
> The second quote seems to be a pretty reasonable trade off (my next question is, how much slower?).
There was a recent web-server benchmark that illustrates the performance and stability trade-off pretty well [1] (or older web-socket one [2]). The StressGrid benchmark shows Erlang/Cowboy achieving about roughly 1/2-1/3 the speed of the compiled options (Java & Go), and roughly double that of NodeJS. Erlang/Cowboy maintained very stable latency numbers after hitting it's peak however (see graph in [3]). There's an oddity with Cowboy 2, that appears to be due to HTTP/2 support but can be disabled (though HTTP/2 in theory should support faster client responses with less multiplexing of HTTP requests).
In general I'd say BEAM is on average faster than CPython, though recent CPython 3.x versions have improved a lot. Importantly BEAM is one of the few dynamic language/VM's that supports multi-core natively (Clojure & Julia for other two main ones?).
> I like functional programming, but experiences do tend to be either: "I love FP" or "Eh, not for me."
True! It seems like either you love FP or hate it. It is a bit painful if you have a bunch of mutations you need to do on a complex object, but there's usually a way to refactor it so you avoid so many mutations. But often you have to think a bit first and be more explicit. On the other hand I modified a short Python script a few weeks back and it took me an hour to find a bug with some variable scoping/shadowing corrupting my data.
> But are these it? I've been getting into erlang lately (to then get into elixir), but I feel like I've been "waiting for the other shoe to drop." As in, I'm wondering if there's some disadvantage that doesn't get talked about. Are there any engineering blogs that talk about using BEAM/Elixir/et al in production?
There certainly are gotchas, with Erlang Distribution in general or with default tools like Mnesia (split brain, 2G file limit). One gotcha I saw from a great Youtube talk (that I can't find) was when using the standard Erlang distribution to distribute jpeg images. Erlang distribution network normally only opens one connection between each node, which when you try to send lots of large binaries will get saturated. Then things like PG2, and health checks, etc which require low latency will start breaking. That team solved their issue by creating a separate connection plane for image data, a few hundred lines of code. Similar issues can (apparently) can happen with BEAM software like RabbitMQ as well since it uses Erlang distribution internally. There's plenty of stories from people recovering from errors [like 4]. Erlang Solution's has a great collection of videos and blogs on Erlang & Elixir.
I'd agree with sibling comments, learning Elixir first is just much nicer for many devs used to Ruby or Algol family syntax. Capitalized variable names confuse me to no end in Erlang code.
Same. The repo doesn’t disappoint. It’s thorough and very well documented. I am really glad I started reading through the codebase when I did. My only regret is not reading through earlier.
Damn. Thank you. This comment had my dying in a restaurant earlier. I really enjoy writing rust and I was sad when Steve was sad. I had a similar thought, “why when actix is dead?” I’m glad actix is back.
I was coming to SHOW HN a rust tool I made when, boom, front-page: actix is dead.
@burntsushi I use ripgrep all the time. I was also able to learn how to go from 0 to release just by reading through your codebase and documentation to see what goes into a release. When I was writing my foss project I asked myself wwbsd (what would burntsushi do). Even stumbled onto how to create and maintain a homebrew tap thanks to you. I appreciate you and the work you put out, thanks!
This is cool. I agree about the pricing page. If you're going to charge, charge.
I like where this is going. You are right that humans are visual. But we are more than that; we need to create more tools that complement our biological form. This is a cool step.
hacker news has been incredibly influential on me in exemplifying what a site could be.
I too have been thinking about the philosophy of a minimal amount of "design." After a certain point or certain amount of "design" I feel like we have to ask ourselves, "what's it all for?" I've been getting into more front end territory and have been delighted with how much HTML does.
For me, it's not so much about minimalism. I feel that minimalism semantically conveys, "the absolute bare minimum possible." Whereas I like to see the design goal as, "what is necessary to fulfill the required purpose."
Shameless little plug here, this is a little experiment I've been working on:
I could not agree more; especially with the vi advice. I'm still a work in progress, but I agree this would be cool. (I have `ESC` remapped to `JJ` and I find myself trying to exit insert mode in emails, papers, etc. all the time...)
I've also structured the site in a way so that it kind of has a schema for each article and the next step was to write a little client so one could read from a terminal.
Baked into my design philosophy is "reuse" hence not opting for a custom light-to-dark-toggle. Thanks for this though, I'd just reminds me I gotta keep it up ha. Do you think browsing in the terminal would be a hassle for people?
I'm also trying not to go too far overboard, thanks!
Do you think browsing in the terminal would be a hassle for people?
No. the basics of the site make this close to zero cost and proof-by-example is the alternate textual views of the site which just work (tm)
I am trying not to be a google fanboi, but the ubiquitous consistency of keyboard accelerators in gmail, photos, docs, &c by google is one of the reasons I enjoy using their tools. They "get" keyboard warriors, in the browser.
I like that. I feel similarly towards apple products. The consistency of these google products &/or the seamless-ness of apple products means that I can focus on what's important to me.
Good tools feel like good tools. Had to re-read,"ubiquitous consistency," nice. Thanks for the value added.
I don't agree. I tried these, some time ago (I admit) and found it a less than stellar experience. It actually isn't about vi vs emacs, its about 'have sensible keyboard shortcuts' and 'have shortcuts consistent with the industry'
It's less than stellar, but still a lot better than the defaults.
I think the content and the controls should be kept separate without messing with the other, that applies to websites hijacking the scrolling as well as others trying to do creative Vim keybindings. I wish Vim browser plugins were comparable to a solution like qutebrowser though, Surfingkeys(which I use) is pretty good but the input delays of those plugins are frustrating.
No.
From the top of the article:
>Administrators say installing listening devices like Alexa in student bedrooms and hallways could help lower dropout rates.
No. Stop. Just stop.
In fact, I think installing these devices in the offices and conference rooms of administrators is a much better idea albeit just as <s>minimally</s> equally thought-out.