smashedtoatoms

"We need something to remind us that we should be civil and grateful for FOSS contributions."

You mean like having the legitimate risk that maintainers will take their ball and go home when people are cruel and others stand around and let it happen?

This is everyone's fault who didn't dogpile the people who were being terrible. We all need to be calling out people being horrible, and provide a little emotional support to maintainers. We worry too much about the feelings of people who contribute nothing, and not enough about the people who build the things upon which we rely.

Not to mention provisioned lambdas if you're on AWS.

Word

Do you actually listen to one unique album on repeat all day every day? You ever have a month where you listen to one record, or one record's worth of tracks every day? Now you pay $10... Or play it on random to have background noise and effectively pay nothing for a month. Or, more likely, play random to have music going all the time and pay effectively nothing, put tracks you like on a playlist, and then eventually buy all the songs on that playlist over time as you listen to that playlist. It will probably cost more, but not much more, and the distribution to the artists is more likely to be ethical.

This actually seems a lot more likely to be sustainable than the current model, which just grinds all but a few dozen artist's bones to dust until they quit music and get real jobs.

If this results in musicians being able to make a living, I love it. If not, at least it's trying. Pandora paying out $2700 for 40 million plays is bullshit. I don't mind paying for something that affects my life as positively as music does. I hope this works or leads to something that works.

I generally prefer static types. Elixir is the exception. Immutable variables and structs, coupled with OTP, make it arguably as safe for me as Typescript (whose types can lie if you get unexpected data from an api that doesn't match your type definition, for example). Refactors kind of blow though. Refactors are where I actually miss types, otherwise, I don't really notice.

Same. Wsl is great. Running ides in wsl even works great, but with vscode, I don’t even do that much anymore. It’s like being on Linux for dev, but having Windows for power management, high dpi settings, drivers, etc. It’s working great, hardware selection is nice, games work. I’m really digging it lately.

Maybe because some mega corp will figure out how to offer it as a service, and they'll get nothing for it. I support them defending themselves with a way to maybe make money on it. If they can't eat, they can't update the code.

I have no idea how people convince themselves to contribute to open source and/or participate regularly in online discourse. It’s basically working really hard for the easiest-to-offend and least-likely-to-appreciate-anything-you-do people on earth, so they can throw shade at everything you do, and then get mad because you did something different than they would have done.

FWIW, I appreciate everything you all are doing, even the stuff I’m not using right now. You all don’t hear it enough, and you’re certainly not getting paid enough for what you’re doing.

Yea, this project is mostly batch processing of things, so cold starts don’t matter. There is one api endpoint that we left in go for quick responses. I thought about doing a C# to js transpile, but have not had time to look into it. That being said, our cold starts are < 2 seconds with dotnet core 2.1, which isn’t great, but isn’t too bad.

The domain experts all write C#, and I don’t have strong language preferences, so it’s easier for me to switch to C# than it is for them to switch to Go. There isn’t a real technology reason, it’s just team ergonomics.

1st million calls on lambda are free... then ~$1.80/million calls/month after that. No ops once you deploy... like none. Dotnet runs on it fine after being written on a Mac, with code completion and linq hints etc. No visual studio in site. I didn’t even install mono.

Your uncool technologies might be cooler than you think. ;)

I’m in the process of porting a bunch of go code to dotnet core 2.1 on AWS lambda. I’m on a Mac using vscode. I never installed mono, just the dotnet sdk.

Honestly, I’ve been amazed at how good the tools have been. For cli and serverless dev, it’s been surprisingly great. It’s fast. C# is decent. The cold starts are not as fast as go, but not terrible. Memory usage is low.

It’s been a legitimately positive experience. When I started the port I was skeptical, but it is legit cross-platform. I would consider starting a project in it for lambda... I never thought I’d say that about a MS product.

Something over there is different, and I suppose it has been for awhile. I think it could get a lot more popular as non-ms devs realize that MS has built dotnet to work really well on Mac/Linux cli, far away from the weird tightly-coupled Windows/VisualStudio-hit-f5-to-do-the-magic-with-the-15-billion-auto-generated-magical-xml-files world. It feels well engineered instead of thrown together, which is nice.

Also, So far, I’ve pulled in no external libs other than the AWS sdk for the port either. C# with linq is a pretty complete toolset. I’m sure I’ll pull in more as I get more familiar, but it’s been solid on its own. Really nice surprise.

That’s fair. Api Gateway is definitely the lock-in as well.

You’re spot on. It’s really not good for any scenario where an occasional random long response time is a deal breaker. It gets particularly crappy when you have lambdas dependent on other lambdas. That being said, if an occasional long request is ok, it’s pretty great. It just depends on what you’re doing with it.

Sure, but why would you do that? If you’re running Django, set up your ec2 instance, and run Django. If you’re running lambda, don’t spin up an entire framework in it to run for individual requests. That basically defeats the purpose. You’re not running a tiny little function, as you said. Your running an entire web framework that’s running one tiny function. Instead of doing that, write an actual simple function that does the one thing it needs to do. It will take 200-300 ms to spin up and run the first time, as well as on requests when it scales up, but otherwise will run in 2ms. Keep it really simple and stateless. If some part of that doesn’t work for your use case, then don’t use lambda.

It was not meant to run an entire framework in. If you’re reaching for an entire framework to run a simple function in a lambda, I’d bail on one or the other. Don’t use a framework, or don’t use lambda.