I would add also PCBs for hardware prototyping. Ordering custom PCBs is ridiculously cheap and easy now.
Things that used to be hard and are now easy
301–310 of 316 posts
Re: Things that used to be hard and are now easy
#302Earlier quoted context omitted.
It works for pure Rust code but once you bring in C, you need another tool chain too. Same as Go, as far as I know. Zig has both beat right now, as you do not need anything else in either case.
Even if you don't bring in C, you need a cross linker and some libraries to link against. Rust doesn't come with those, except maybe for the mingw target.
I don't think of downloading the libraries as being a "cross toolchain", but that is true.
Common cross-compiled components default to lld, which is a cross linker.
That said, yes, there are some *s here depending on what exactly you're doing.
Re: Things that used to be hard and are now easy
#303Earlier quoted context omitted.
When was this? Maybe If you’re talking exclusively about FAANG.
I’m too young to know from my own experience but from what I’ve heard early 2000s.
I was around in the early 2000s, and you certainly didn’t need a 3.5 GPA from a top tier school for anything but a very small handful of companies.
In the early 2000s, you could get decent work just knowing HTML.
Re: Things that used to be hard and are now easy
#304IE support for JS/CSS has been massively simplified by not supporting IE any more.
I browsed the Washington Post and NYTimes with IE11 the other day and was pleased to see they looked like absolute garbage. :-)
Re: Things that used to be hard and are now easy
#305As someone who leans frontend, I find firebase and serverless (somebody else’s server) solutions really powerful for prototyping an idea or building a proof of concept. You can get something in front of your users tomorrow. I would second guess SaaS startups that start by building the infra/data models unless they’re going for a highly technical play (aerospace, hardware, etc) or already have a ton of market knowledg…
> As someone who leans frontend > I would second guess SaaS startups that start by building the infra/data models unless they’re going for a highly technical play Do you not see the problem with these 2 statements. Of course not dealing with non JavaScript is easier for a JavaScript developer. > You can get something in front of your users tomorrow. This is something we’ve been able to do with Rails or Django for nea…
In my experience, if you're not using Heroku, getting a Rails/Django app launched requires at least a day or two dedicated to devops faffing about (creating server instances, setting up CDNs, making sure the database is minimally correct, having some kind of deploy script or something). This won't even get you nice to have things like multiple environments with CI and deploy previews. Switching over to serverless can reduce that to less than one day and get you deploy previews. Is that a good tradeoff? It just depends on the app, and how long lived it will be, what the performance requirements are, the costs of hosting, etc. For my needs, it's often easiest to just use Netlify's AWS Lambda adaptors.
Re: Things that used to be hard and are now easy
#306Earlier quoted context omitted.
Even if you don't bring in C, you need a cross linker and some libraries to link against. Rust doesn't come with those, except maybe for the mingw target.
I don't think of downloading the libraries as being a "cross toolchain", but that is true. Common cross-compiled components default to lld, which is a cross linker. That said, yes, there are some *s here depending on what exactly you're doing.
AFAICT, rust doesn't ship lld, though.
Re: Things that used to be hard and are now easy
#307Earlier quoted context omitted.
I don't think of downloading the libraries as being a "cross toolchain", but that is true. Common cross-compiled components default to lld, which is a cross linker. That said, yes, there are some *s here depending on what exactly you're doing.
AFAICT, rust doesn't ship lld, though.
If you are using the various ARM targets or wasm, it'll also include the llvm-tools component of rustup, which does.
Re: Things that used to be hard and are now easy
#308> Things that used to be hard and are now easy: > Concurrency, with async/await (in several languages) The number of times I've been bitten by the very specific semantics around async/await in JavaScript makes me wonder if I've hit some kind of a ceiling in trying to grok it. Coming from the world of threads, I've found Kotlin's structured concurrency approach the best of the lot I've used so far, even if it isn't wi…
Oh yes. I hate async/await so much. If I could uninvent one thing in programming it would be async/await. I wrote async/await code in C# for about a year. I did really try to learn it. I invested a lot of time. I did read Stephen Cleary. It often made sense for a split second only to fade away immediately. Usually the software would work, but i didn't understand what was going on in my own code. And others don't unde…
I've never had any trouble with async await in JS and Python. It's pretty close to being just like threading if everything were under one giant GIL.
It's just "Stop here and wait till the task finishes" and "Only one thing happens at a time and you don't go till someone stops".
If you quit rather than got fired, it seems like you must have learned async well enough to do your job.
I almost wonder if C/C++ et al aren't teaching people bad habits of thinking about how things work behind the scenes instead of just just trusting the language.
Haskell probably has the same effect, but it is also said to have some benefits too. It teaches people to look for underlying mathematical patterns in everything.
The thing with modern programming is it seems to be designed assuming you're thinking in terms of the language and libraries you are using at the moment, and building your architecture the way the language designers intended.
As soon as you try to actually understand how it works, or you try to get creative and do anything outside their opininated boxes, it gets ugly, otherwise it's usually fine.
Re: Things that used to be hard and are now easy
#309Earlier quoted context omitted.
Oh yes. I hate async/await so much. If I could uninvent one thing in programming it would be async/await. I wrote async/await code in C# for about a year. I did really try to learn it. I invested a lot of time. I did read Stephen Cleary. It often made sense for a split second only to fade away immediately. Usually the software would work, but i didn't understand what was going on in my own code. And others don't unde…
I think async/await is kind of a didactic mistake. It’s marketed as a way to not have to think about the underlying abstraction, but lack of the understanding about how it works under the hood will almost certainly bite you in this ass. This I find to be especially true when people are writing mixed async and sync code. The best way for me to learn was writing all of the code before the async/await sugar existed (sca…
I think the intent is that you don't have any sync code at all.
Re: Things that used to be hard and are now easy
#310Earlier quoted context omitted.
Oh yes. I hate async/await so much. If I could uninvent one thing in programming it would be async/await. I wrote async/await code in C# for about a year. I did really try to learn it. I invested a lot of time. I did read Stephen Cleary. It often made sense for a split second only to fade away immediately. Usually the software would work, but i didn't understand what was going on in my own code. And others don't unde…
I hope someone can reply to this and help me learn more about async/await in c#. I'm finding it confusing too, and I can't put my finger on why.
If you don't know what a thread is, start there. Otherwise, you might read this.
https://blog.stephencleary.com/2013/11/there-is-no-thread.ht...