Anyone have invites? This is intriguing to me, I’m hopeful about the broader move away from VC funding, at least for things that aren’t really capital intensive.
There’s a limited-invite thing on their subreddit about every week or so, and you can also email invites@tildes.net (don’t know the success rate with that one).
I’m baffled by how many people continue to use emacs/vim for editing code. I’ve tried them both (and neovim) but I have no interest in spending my days configuring or figuring out why it’s not working as expected anymore when there are so many “out of the box” things that just work. Feel free to flame me below for not being trve kvlt on programming.
Anywho:
Geany on my low-spec notebook because it’s lightweight and runs well.
For my part, the ‘out of the box’ editors don’t just work. I can’t run a shell in one, or manage my passwords in another, or work with git repos in that one over there, or connect a running REPL to my window manager in yet another.
Emacs is a Lisp operating system. It is how I use my computer. It is my computer.
I have TikTok installed on a tablet that I don’t have anything else really installed on (a couple games like solitaire). I see a LOT of people talking about how TikTok changes how people think or interferes in election stuff, but my feed is a bunch of horses, dogs, and people cleaning cow hooves. I’ve never even seen a political video on it before so I’m not sure how it gets to that point.
I agree with him that people should be free to choose to watch what they want, but I also agree with the gov that government devices should not allow TikTok on it. That seems pretty obvious.
I’ve watched a few of those because it was interesting. But also disgusting. Then YT kept putting more on my home screen, so I had to “don’t recommend channel” a few times to stop seeing them.
It’s so bizarre to me how Adobe botched Flash/ActionScript so badly. If you were around in UI at that time, you’ll know just how huge it was. The funny thing for me career-wise was that I was a JS expert when no one wanted it. I had jobs tell me to ditch JS and go all in on AS2 (and AS3 later). Then when Apple said no more Flash, it totally flipped and they were asking me to teach people how to use JS.
Looking at what JS has become is nuts in comparison. I did like AS (and still do) and really wish it were viable. Maybe projects like this and Ruffle will give it new life. But man I wish Adobe would do right by it and modernize/open source it.
They’re both forms of ECMAscript (now) but were more siblings or cousins than slightly modified. AS had packages, classes, typing, etc that made it look much more similar to Java in many cases.
Curious how many of you are using perl and what you think of it after all these years. I used it for some Advent of Code a few years back but found it a bit clunky (the last time I had used it was probably 2001 prior to that)
This seems incredibly hard for some people to understand, but I actually like JavaScript and do understand types. In fact, I use strongly typed backend languages all the time! I also see TS as unnecessary overhead for what basically amounts to “I feel better because a class of bugs that almost never happens won’t happen.”
I always see the runtime error excuse yet I’ve never seen anyone actually have issues with “I passed the wrong type into a function and broke the site.”
The only one that has merit is the IDE support, but unless you’re making a library (which is the time I do find TS worth using), you’re not going to notice this part much if at all.
I’ve been coding in JS since the late 90s. I’ve seen a lot of really bad code. I’ve also seen some really awesome code. I’ve also had to use TS everywhere for work and saw Enterprise Java infect it. You can make some terrible code with TS.
If you like TS, go for it. But don’t assume I don’t understand it because I don’t prefer it.
And for what it’s worth, optional typing is very likely coming to vanilla JS in the near future. When it’s built in, I’ll be happier to see it. I don’t want a whole ecosystem of dependencies for it.
I’ve worked on projects with brilliant programmers, and this still was a problem. Once the codebase is larger than what a single person can fit in their head, and old enough that it needs refactorings, types save a lot of pain.
I’ve worked with absolute beginners and really experienced people over the years. If you have people breaking production because they passed e.g. a string instead of a number, your tests aren’t good enough.
And to be clear, you don’t test for type. You test behavior and functionality.
A type checker is equivalent to an automatic and concise test for behavior at every call site that involves a string or number that you can’t forget to write.
I always see the runtime error excuse yet I’ve never seen anyone actually have issues with “I passed the wrong type into a function and broke the site.”
Not only have I seen this happen with Javascript, but with Ruby and Python as well. However, I don’t believe strong typing is in service to preventing such things. Rather less directly it’s about enabling the powerful type-aware tooling that prevents such things regularly during development and subsequently improving developer efficiency.
If you like TS, go for it. But don’t assume I don’t understand it because I don’t prefer it.
I think this is a valid point that strong typing advocates should hear.
The only one that has merit is the IDE support, but unless you’re making a library (which is the time I do find TS worth using), you’re not going to notice this part much if at all.
Maybe another way to consider it is accident-proofing. I tend to find that by shifting some of the load to the computer, it frees me up to focus more in the logic I’m trying to implement, or change.
You might not need that support, but other folks in your team might, and might even be uncomfortable admitting that.
I can see an argument for TypeScript simply because of how many things you have to more or less memorize to understand what JavaScript will do in a given situation. Introducing a layer of abstraction which doesn’t require that memorization, which lets you write simpler code without worrying about it, and which then compiles to JS that will do what you intended, has utility for me. Though a lot of modern JavaScript has cleaned up the worst bits anyway, so it’s not always a necessity.
As to other benefits of TypeScript… well, I’m not sure I see them, and to be honest I’m not sure I see them in Python (my main day-to-day language), either.
Some of this is just that dynamically-typed languages are different. I think that’s the single biggest hurdle – people who are used to static typing have a certain mindset about how they write code, and often have difficulty adjusting it. I’ve seen people write the equivalent of:
def some_function(param_1, param_2, param_3, param_4):
if not isinstance(param_1, str):
raise TypeError("param_1 must be string!")
if not isinstance(param_2, int):
raise TypeError("param_2 must be int!")
# ... etc.
And then they write unit tests where they call the function passing in a bunch of random things just to assert that it raises the expected TypeError.
Which is not how I write code. And not how people who are actually used to dynamic typing write code. There’s a level of what I can only call trust: that if you do by some chance pass, say, a str to something that expected an int, it will be caught by the test suite. Not because the test suite contains exhaustive checks for all possible types being passed to every function, but because the test suite will exercise the codebase as a whole and the bad path will execute somewhere in there and blow up.
And for the most part people don’t go around doing things like passing completely wrong types into functions. After all, dynamically-typed languages have documentation! Including easily-accessible documentation that your editor or IDE can display inline for you! This is actually the only real use case I currently have for type annotations in Python – they’re much less cumbersome than the alternatives, and most tooling now picks them up automatically, so they streamline the documentation process. Which means that instead of writing Sphinx param declarations to get that part of my docs, I just put in type annotations for most things. I don’t actually run mypy or any other checker, though (for a variety of reasons).
But I do think most of it comes down to that lack of trust. I’ve worked on lots of codebases in dyamicallv-typed languages. Including huge codebases with large teams and even teams of teams involved. And I’ve never seen dynamic typing fail to “scale up” the way people always insist it will. Which isn’t to say I’ve never seen failures, just that I’ve never seen failures that were attributable solely to choosing a dynamically-typed language. Scaling up a team/codebase is difficult, and often fails even in projects that use statically-typed languages. People just like to selectively blame languages/type-systems/etc. for issues that were not technical in nature.
I have once or twice seen people who came in with a chip on their shoulder about type systems and tried their best to “prove”, through committing deliberate mischief, that dynamically-typed code can never be trusted. But that’s a people problem, not a programming-language problem. And I’ve seen people who never really were able to let go of their fear give up and just went back to static typing. Where, amusingly, they rarely actually need the type system to yell at them because they do exactly the same things that would have worked in the dynamically-typed languages (like referring to documentation before calling into unfamiliar functions/methods).
Plus, everybody who’s ever tried to rigorously prove that static typing produces better code has failed. Dan Luu’s literature review on this is old, but still very relevant for pointing out the common flaws in such attempts.
Pretty much all sizes you can imagine. This goes back pre-jQuery to my current role, from little startups to giant corporate behemoths. Some of the worst code I’ve seen is Java devs trying to write TypeScript at Capital One.
Some companies I’ve worked at that you may have heard of: Capital One, USA Today, ESPN, Nickelodeon
I also see TS as unnecessary overhead for what basically amounts to “I feel better because a class of bugs that almost never happens won’t happen.”
In my experience, removing certain classes of bugs is only half of it. A typed language is also an excellent form of documentation that can’t be matched by manual approaches such as JSDoc.
Approaching a large code add without any types is scary and difficult, especially if the functions use JS tricks such as arguments and dynamic function signature overloading.
For small systems that one person can keep in their head, then sometimes a typed language can slow you down or feel like it gets in your way. When you have a legs system worked on by 100+ engineers, you are going to pay a heavy price for not using a typed front end language.
And for what it’s worth, optional typing is very likely coming to vanilla JS in the near future. When it’s built in, I’ll be happier to see it. I don’t want a whole ecosystem of dependencies for it.
Yeah. Imagine instead of adding in a bunch of transpiling libraries you would just have the ability to add a plugin to your IDE to give you the same info. That’s the big benefit there.
…the language in this specification favours TypeScript as it is the most popular type-system…
A few years ago I, like you I think, dismissed TypeScript as another CoffeeScript. It would, at best, influence JavaScript. Eventually the languages would diverge and TypeScript codebases would be marooned with an antiquated version of JavaScript as its compile target—hip today, embarrassing tomorrow.
Instead, a couple of things happened that surprised me. First, TypeScript has maintained (with one exception) a commitment to being a superset of JavaScript and had thus far done a good job of staying up to date with its parent language. Second, it has become immensely popular, the result of which is that the parent language is deferring to its child in this proposal, the intent of which appears to be that we will be able to run TypeScript from source in JS engines without any compilation. TypeScript would presumably then itself be run much as you envision: as a static analysis plugin for IDEs.
The elephant in the room is TypeScript’s enum, which breaks the “fully erasable” in “fully erasable type system.” This proposal explicitly will not support it. I would like to see TypeScript kill it in its next major version.
Perhaps a more important change is that the entire team became “full-stack” developers, instead of having a hard front-end/back-end split. That’s huge, in my opinion
One challenge I’ve found in that front is that if you want good frontend developers it’s very hard to find those that are also willing to deal with backend development, or having much of any skill there. There are many good backend developers that are alright at dealing with frontend, but above a certain quality bar it’s basically impossible.
I do think it’s great to be able to have people who can really handle the entire stack, but there are issues with mandating fullstack-ness, so you gotta be a bit careful there. This is “solvable” by pairing people up but then you get into another can of worms based on who you have on the team.
Is that split really front-end vs back-end or infrastructure vs UI? I’ve not done serious web development, but my guess would be that it’s hard to find good interaction specialists but much easier to find people who can write code that runs on either end of a network connection. Are there teams where ‘UI designer’ is a separate role but the engineers work on the whole of the application stack?
Are there teams where ‘UI designer’ is a separate role but the engineers work on the whole of the application stack?
So I’ve worked on a team that ended up almost there. There was one “pure” UI designer, and another who was UI design but liked coding. There were a lot of growing pains because he couldn’t properly prototype stuff due to our backend being hard to run for people not used to the terminal.
They both could get work done provided the right tools! But the tooling we had was made (essentially) for backend engineers, so it was a huge amount of friction. That and there was just a different kind of workflow.
But yeah, the overall lesson was that there were people able to do the work we really were missing from the team (remember, the other engineers could write code in both domains! Just the frontend code wasn’t great), but those people could not really work on the team without us adjusting expectations about infra-related demands
Yes, but we have strong evidence from the old days, pre-SPA frameworks, that server-rendered templates are manageable for developers who also do back end work.
It was only when SPAs and their attendant complexity came along that the split between front-end and back-end became pronounced.
I haven’t observed that at all. Real frontend specialty, like advanced CSS and UX stuff, has always been taken care of by frontend specialists. Everything in between, pretty much anyone can do.
The evidence being that full stack development was a relatively common thing pre-SPA era.
Not saying that there won’t always be designers involved, especially once you start talking about externally facing applications. But htmx puts full stack back on the table as a potential option in a way that SPA libraries and their attendant complexity do not.
I don’t think I would put much stock into it as a hiring manager simply because everyone editorializes their job history and duties. I also don’t care what you made at various places.. why should I? We have a range set and will offer what we think you should be paid (50th percentile of national average for that position, generally). If you agree to it, awesome! Your past pay doesn’t come into the equation.
I have an M1 air because I hate the touchbar, but I think those are gone now on pros. To be perfectly frank, any of them since they fixed the keyboard issues are going to be great in terms of build quality. It really comes down to what you want to spend.
It’s interesting what’s being included under the umbrella of “Typescript” in this post. As someone who’s been writing JS for the better part of 20 years, it’s generally been clear to me what’s JS, what’s Node vs browser, and how Typescript is a layer over JS. But if I was coming in today and trying to learn Typescript I would totally conflate all these things, too.
Some concrete examples:
The ecosystem is also pretty impressive. With over 1.3M npm packages available.
I would bet that the vast majority of the packages on npm are pure JS with no Typescript support. Factor in popularity and you’ll see a lot more TS, but npm is a Javascript package repo, it predates Typescript by several years. It’s where you get Typescript-supporting packages from, but it’s not of Typescript.
Typescript is also very async-friendly, and everything is single threaded.
Javascript is also very async-friendly …
But if I had to choose the thing I disliked the most… that would be the module system
100% agree, and this is a place where adding in Typescript does makes things more confusing. It is massively frustrating when you run into module issues, and the sooner the ecosystem can get on the same page, the better. Though I suspect this pain will stick around for years. But the module issue also isn’t really of Typescript.
I accept that these are probably all pointless distinctions to someone who’s trying to write some Typescript and deploy their code!
Aside, since the author is here: I’m not sure if the bit about checking for a successful request is just an example for the blog post, but in case it’s not: Rather than checking the status code, from fetch you probably have a Response object, so you likely want the Response.ok property
I’ve noticed this as well, similarly having used JS for 20+ years. It’s actually somewhat frustrating to me to hear people argue for TS using JS features because it shows a fundamental misunderstanding or lack of knowledge of the ecosystem and language itself.
Not that this blog is arguing these points, but seeing TypeScript thrown around where it’s really just JavaScript is still difficult for me to see. JS is demonized while people sing the praises of TS, but quite frankly, if you could only use JS, you wouldn’t really notice that much of a difference.
Yeah. I am actually aware of some of those distinctions. But you captured my point correctly! As a newcomer, as much as I am aware of those distinctions now, the post documents my journey learning through all of that, so I included some things even though today I know better (And I wish I had taken more notes!)
All in all I am pretty happy: having started my career in the kernel, and now writing Javascript/Typescript… maybe I am finally full-stack?
Thanks a lot for the Response tip! I’m learning stuff every day.
Personally I found it hilarious, the bit with the response code. Here comes a hard-core systems-language, low-level guy, complains about types and stuff, then assumes that 2.03 equals 2. Like, I thought you guys are precise!
Anyway, nice post for people trying to deal with TypeScript.
I accept that these are probably all pointless distinctions to someone who’s trying to write some Typescript and deploy their code!
Yes, but I’m going to pick on you a bit even though you “admit” this.
The way you describe your examples as “That’s JavaScript, not TypeScript” or by distinguishing between JS, a browser engine, and Node.js is very similar to a scenario in which someone said “I’m switching from Rust to Java” and I chimed in and said “Actually, you’re writing Java on the Oracle JVM.”
“Switching from Rust to TypeScript” could only possibly mean that the code they are authoring is written in TypeScript and that it’s running in whatever runtime matches the use-case that the Rust code would’ve been used for (so, likely Node.js).
Is there anyone who doesn’t know that TypeScript is just a broken type system on top of JavaScript?
100% agree, and this is a place where adding in Typescript does makes things more confusing. It is massively frustrating when you run into module issues, and the sooner the ecosystem can get on the same page, the better.
One thing that helps in this regard is that libraries are starting to ship ESM-only, meaning if you’re still on the old CommonJS system or you’re using an older version of Node (pre-12), you can’t use that library anymore. This is going to incentivize a lot of people to upgrade, or rethink how they’re approaching JavaScript.
that’s what one would logically assume would happen. But then look at python2 vs python3, which did a similar thing… Took at least 10 years to resolve.
I definitely get that, and as someone who dealt with that whole transition in my own software, I distinctly remember the pain being caused by accidental upgrades to Python 3 or downgrades to Python 2.
But I think the JavaScript package ecosystem is a bit different for a couple reasons:
Python packages have classically been (and especially were around that time) much larger than JS packages. It takes longer to upgrade these packages, as they have a lot of interdependent code and potentially external libraries needing to be linked. A package like left-pad would have never existed in Python (you know, assuming Python didn’t have a proper standard library), because it just goes against the culture of packaging in that language. Instead, you might find a library that does all of the string manipulation functions. This is great for a language like Python where you are typically running it on a server, but not so great when you are thinking about pulling dependencies from all sorts of places on the web, essentially trusting the network with your package management.
(somewhat related to the first point) JS packages are a lot more numerous than Python packages. As a result, we have all those memes about how node_modules/ is denser than a black hole or whatever, but the truth to that is due to all of the tiny packages in the JS ecosystem, just a single one updating to be ESM-only can cause some real peril in your dependency tree. This is why most libraries are doing CJS/ESM these days, but there are a few that are only distributing as ESM in order to help speed this transition along.
Multiple runtimes depend on this package management standard. “ESModules” is effectively “standard JavaScript modules” at this point, as not only does this work in NodeJS, but it also works in Deno, BunJS, browsers, Blueboat, Duktape, etc. If a library author is writing something simple, that isn’t depending on runtime-specific stuff such as filesystem access or standard library functionality, compiling for ESM makes a lot more sense than maintaining a special CJS version just for customers of a single (albeit, the largest) runtime. It starts to make a lot less sense when that particular runtime gives you the option to not use CJS.
I’m not saying that “oh this time it’s different trust me bro”, but I am saying that while there are similarities here, I think the incentive here for not only application developers but also library developers to upgrade is much greater than it was in the Python world when they switched to v3. It also feels a lot easier to me, as someone who had to go from Python 2->3 and has also seen JavaScript go from a language without basic shit like conditionals into the juggernaut that it is today, than Python was because there are tools to compile your code for different environments, like you couldn’t e.g. write a Python 3 program, compile it down to Python 2, and then distribute both versions in the same package. (or can you? if so that’s pretty cool but I had no idea it existed back then)
I think this would be better if it saved to SVG by default or had the option to do so. I looked through the docs very briefly and didn’t see any mention of image format, but maybe it’s there somewhere. PNG is ok, but in the world of handheld through giant devices, SVG is better.
I switched from Firefox to Vivaldi when they released the last UI update a few years ago and also broke the setup for everyone I had tried to convert. Every browser has problems, choose which one you can deal with. I’ve learned to love horizontal tabs with tab groups. The UI can be a little slow sometimes, but I’m also a pretty heavy user with 5 windows open and hundreds of tabs. As far as tracking I remember Firefox doing all kinds of phoning home. Most privacy addons exist for Chrome and there are multiple privacy focused variants. I do backups, so I can restore if something fails. Overall I dislike how the article frames it as only two browsers existing in the world.
I’m also a Vivaldi user and I recommend it every time I can. The UX is great, privacy is a real concern, and they really seem to care about the community.
I have a wordpress blog I manage - maybe I’ll give this a go to see if it is as easy to use. I prefer static site (and right now have my WP outputting static files), but the whole wordpress environment is a hot mess to get into if you want to mess with templates and internals.
From almost-personal experience (my non-techie wife has Publii), I can say I like it more then something like wordpress. But like wordpress, if you want a lot of flexibility (besides from just a static blog generator), it’s going to come in your way sooner or later.
For regular blogging, however, I like it just fine.
I had issues with it importing my wordpress site. It totally broke the client, made no posts show up, but if I previewed it, it did build correctly. Very strange, but also a deal breaker as I can’t edit old posts or even see new ones.
Position(s): Many open roles, but I have 2 openings on my team specifically for backend software engineers
Location: Remote (we have offices in Richmond VA and San Francisco if you’re interested in them though)
Description: Because there are so many open roles, it’s hard to pinpoint one description here. I can tell you that we have multiple products, including credit cards, debit cards, and a gigs app to help people find/track their gig income and make informed decisions about how they earn money. (Mission Lane, Mission Money, and Earn by Mission Lane in the app stores)
Regardless which team you work on, you will own your team’s domains and services from start to finish. You’ll build your app, deploy it, and monitor/maintain it. We work closely with our product owners (who are part of the team, not separate and distinct) to put out the most impactful features we can. You will be responsible for writing code, reading code, reviewing PRs, mentoring others, and rotating on-call for your own apps (you won’t be on-call for things you don’t own). While we’re at work, we work! But we take time off and encourage you to maintain your personal life. You will not be expected to work overtime or weird hours. Your time is your own outside of work. There is unlimited PTO, but we truly do encourage people to take it off and not burn out.
Compensation: Depends on the pay band, but we pay based on national rates, not local (no matter where you are). Unlimited PTO (that we actually encourage you to take), 401k - 100% on the first 3%, 50% on the next 3% up to 6% for a total company match of 4.5%
Contact:https://boards.greenhouse.io/missionlane – or if you really want you can message me and ask questions. I’ve worked here for about 3 years as both a tech lead and (now) an engineering manager. Happy to give you straight facts on the company / how it is working here.
I use native/vanilla JS for all of my personal projects. There is definitely a learning curve to it, but you can do some really interesting things with no dependencies at all, especially if you only cater to modern browsers. There’s no compilation, transpilation, or even an npm file if you don’t want one.
The problem is that people don’t keep up with the native/vanilla APIs (or in some cases haven’t even seen them), so they make uninformed decisions based on antiquated arguments (e.g. cross browser issues) that no longer apply.
Custom Elements are really quite easy to get a handle on and interesting to use. I’d recommend anyone working in JS on the UI side take a look at them and see if they do provide what you need. Personally, I use a whole lot of addEventListener to use pubsub with native APIs. Completely decouples your code and it’s really easy to use.
This post can be summed up by “I prefer promise syntax.” The argument that try / catch sucks but somehow Promise.then().then().then().catch() is better or easier to understand is subjective at best. I’ve never met someone who has written a lot of JS who prefers promise syntax to async/await, but I guess there’s a lid for every pot.
I prefer promises to async/await. Async/await is a bad, leaky abstraction. For anything non-trivial you have to fall back to promises (eg Promise.all). If I’m going to have promises anyway, I might as well just use them everywhere. The other thing is that async/await doesn’t compose at all while promises do.
async/await also directs the programmer towards inefficient code by default by encouraging sequential async operations (I see people writing code like that often).
They’re invoked immediately so you can’t build up a pipeline are pass them around easily and this causes a lot of devs to thunk their promises
Catching errors was never required so errors are often swallowed or are rethrown in a way that it’s hard to debug
Cancelation had to be added way later than it should have been (and many folk had warned during the proposal phase) and as a result we have this bad API for AbortControllers
all vs allSettled should have been there from the get-go instead added of years later
Folks realized it’d be nice to have a do-like notation so async & await were rushed out without considering the ergonomics for the parallel APIs
What JavaScript wanted was an asynchronous Task and could have been copied from established languages, but what we got was Promise. We’d be better off normalizing picking for our projects one of the Fluture library, fp-ts’s Task, Aff from PureScript, or whatever the API is called in effect-ts (they are all close to the same thing).
That’s precisely the problem. Is there any value in a tiny bit of syntactic sugar that also encourages inefficient code? In my view, the value is negative.
A lot of the code where this would be used is going to have branching logic and overall not be terribly long anyways, so the emphasis on inefficiency doesn’t really ring true to me.
I will admit to not knowing the intricacies of javascript optimization, but I fail to see how using a syntactic sugar would impact it at all.
This whole discussion sounds like like arguing between the do syntax and the bind operator in Haskell. I for one prefer my monads easier to read. As code should be for reading first and compilers second.
The only thing I will concede is that I have seen developers try to break out of the asynchronous context by assigning variables in the synchronous context. This might be worse in rxjs though. The use of Promise directly does force one to read it as asynchronous compared to missing the async keyword.
They are both silly and limited. They both rely on. Funny looking code. They both introduce disturbance the code execution thredline rather then logically allow the programmer to control when an arbitrary code block is executed.
We have to really on somewhat funny syntax.
Both of them are limited to “execute this on the side and when you are ready execute that. But there are no means of controling concurrency. If you want to do thousands of instances of something, both APIs become essentially fork bombs.
Dijkstra wrote down a blueprint for intuitive concurrency (P() and V()) which has been used in many languages for decades. I don’t understand why we have those funny looking things instead of what is tried and true.
Even python went down the path of async wait. The result is a gigantic divider on any python codebase that uses. Any and every little IO operation becomes subject to this great divide. Feels like each time a line if code with IO on it comes, there’s a gun pointed to the head asking: sync or async?
Sure, I agree that both mechanisms are bad, it’s just that async/await is worse. I much prefer the approach to concurrency taken by Elixir/Erlang. I don’t think, however, that semaphores by themselves are the only mechanism we need.
Dijkstra wrote down a blueprint for intuitive concurrency (P() and V()) which has been used in many languages for decades. I don’t understand why we have those funny looking things instead of what is tried and true.
P/V models a specific concurrency primitive usually known as a semaphore, right? As far as I understand them, semaphores are a useful tool, but don’t represent a solution to concurrent programming in general — am I mistaken?
It has been very long since I have red the paper. I don’t remember if it explicitly mentioned that some means of parelelize execution is needed at some point or that was assumed. Fork() spawn(), thread.new(). Whatever it looks like. The problem with old school multi process or multi threading was not the API, but rather the overhead. There is no reason why such an API could not be used with say, green threads. Eventlet does just that.
Yeah this whole article reads like the author wanted to say “I find async/await new and unsettling” without saying those words. And the parallel example feels like a strawman: why would async/await make you forget that you want to wrap parallel work in Promise.all?
I think it’s fine to say “I prefer the old ways” without needing some objective justification.
I think it’s fine to say “I prefer the old ways” without needing some objective justification.
In a professional setting, you need objective decisions to convince people. It’s very difficult to use your own preferences to change the style of other authors.
I feel like it’s my obligatory “use Vivaldi” comment. The core functionality of Chromium is really great from a technical perspective. What you don’t want is all the “google phone home” nonsense. So just don’t use it. Vivaldi comes with ads/trackers blockers built-in.
Chrome and Firefox are open-source on paper only. You have no say in how they’re developed unless you work for a trillion dollar advertising company, can’t contribute code unless it’s your full time job, and can’t ever hope to audit even a tiny fraction of the tens of millions of lines of code even if it’s your full time job.
Can’t comment on Chrome, but for Firefox I can personally tell you that is not true. I scratched my own itch in the developer tools when I was in high school. Was it easy? No. Was it impossibly difficult? Also no.
(In fairness though this was easier with the developer tools than with, say, Gecko core.)
I’m coming from a place of dismissing closed-source browsers. I don’t think that’s unwarranted. We have really good open-source browsers.
When the concern is that Chrome is phoning home and invading your privacy, it seems absolutely bonkers to me to suggest that switching to another closed-source browser is the solution.
Serious question: aren’t cryptocurrencies subjectively bad? Some waste energy, some things don’t work, a lot of things are scams., the main use is for illegal trades. Is there something amazing somewhere that I am missing?
We’re going far off-topic from the OP so I don’t think there’s value in starting that discussion here. If you’d like to discuss the topic, I’m always open to DMs discussing stuff, though I get busy and may take time to respond.
Anyone have invites? This is intriguing to me, I’m hopeful about the broader move away from VC funding, at least for things that aren’t really capital intensive.
Sure, I have 10. I’ll DM one to you. If anyone else wants one, please DM me here.
Update: I’ve given them all away.
I also have invites if pushcx runs out
I apparently have an account with invites too. DM me for one.
I also have invites if someone is interested
I also have invites.
…also, anyone we invite has invites.
I’m interested if anyone still has any left, thanks!
If you got one could you send one to me?
hey caleb, you may have already gotten this or moved on but in case you haven’t :) https://tildes.net/register?code=SQPWL-NO367-SAY33
thanks I will use it!
I’d be interested if anyone still has, thanks!
Can I have one?
Can you send me an invite if you got yours?
If you (or anyone else) have one remaining, I would be interested
Update, I have now distributed 10 invites to users here. Have fun!
There’s a limited-invite thing on their subreddit about every week or so, and you can also email invites@tildes.net (don’t know the success rate with that one).
I can attest that I have received an invite after a couple of days.
I had an email invite like 10 minutes after posting this, thanks ya’ll!
I’ve got 5 if anyone wants one
I’m baffled by how many people continue to use emacs/vim for editing code. I’ve tried them both (and neovim) but I have no interest in spending my days configuring or figuring out why it’s not working as expected anymore when there are so many “out of the box” things that just work. Feel free to flame me below for not being trve kvlt on programming.
Anywho:
For my part, the ‘out of the box’ editors don’t just work. I can’t run a shell in one, or manage my passwords in another, or work with git repos in that one over there, or connect a running REPL to my window manager in yet another.
Emacs is a Lisp operating system. It is how I use my computer. It is my computer.
I have TikTok installed on a tablet that I don’t have anything else really installed on (a couple games like solitaire). I see a LOT of people talking about how TikTok changes how people think or interferes in election stuff, but my feed is a bunch of horses, dogs, and people cleaning cow hooves. I’ve never even seen a political video on it before so I’m not sure how it gets to that point.
I agree with him that people should be free to choose to watch what they want, but I also agree with the gov that government devices should not allow TikTok on it. That seems pretty obvious.
I’ve watched a few of those because it was interesting. But also disgusting. Then YT kept putting more on my home screen, so I had to “don’t recommend channel” a few times to stop seeing them.
It’s so bizarre to me how Adobe botched Flash/ActionScript so badly. If you were around in UI at that time, you’ll know just how huge it was. The funny thing for me career-wise was that I was a JS expert when no one wanted it. I had jobs tell me to ditch JS and go all in on AS2 (and AS3 later). Then when Apple said no more Flash, it totally flipped and they were asking me to teach people how to use JS.
Looking at what JS has become is nuts in comparison. I did like AS (and still do) and really wish it were viable. Maybe projects like this and Ruffle will give it new life. But man I wish Adobe would do right by it and modernize/open source it.
I thought AS was JS, at least a slightly modified dialect?
They’re both forms of ECMAscript (now) but were more siblings or cousins than slightly modified. AS had packages, classes, typing, etc that made it look much more similar to Java in many cases.
It was a lot more static, possibly to make compilation easier? For example, it had classes way before they were added to JS.
Edit: It was backwards-compatible with Ecmascript, AFAIK - not arguing against that.
It wasn’t compiled but interpreted at runtime.
I find it odd that there’s even a “debate” between static vs dynamic typing. They both have cool uses.
I mean, have you met programmers? Over-identifying with their tools and making a big deal about in-group/out-group dynamics is kind of a whole thing.
Sorry but my experience is different from yours so you’re wrong /s
Curious how many of you are using perl and what you think of it after all these years. I used it for some Advent of Code a few years back but found it a bit clunky (the last time I had used it was probably 2001 prior to that)
Almost all of what I write that isn’t precompiled is Perl.
I’m using Perl (with Moose) full-time in an insurance company.
I use it basically for all my personal hacking, and I whipped it out the other day at work to munge some CSV files.
This seems incredibly hard for some people to understand, but I actually like JavaScript and do understand types. In fact, I use strongly typed backend languages all the time! I also see TS as unnecessary overhead for what basically amounts to “I feel better because a class of bugs that almost never happens won’t happen.”
I always see the runtime error excuse yet I’ve never seen anyone actually have issues with “I passed the wrong type into a function and broke the site.”
The only one that has merit is the IDE support, but unless you’re making a library (which is the time I do find TS worth using), you’re not going to notice this part much if at all.
I’ve been coding in JS since the late 90s. I’ve seen a lot of really bad code. I’ve also seen some really awesome code. I’ve also had to use TS everywhere for work and saw Enterprise Java infect it. You can make some terrible code with TS.
If you like TS, go for it. But don’t assume I don’t understand it because I don’t prefer it.
And for what it’s worth, optional typing is very likely coming to vanilla JS in the near future. When it’s built in, I’ll be happier to see it. I don’t want a whole ecosystem of dependencies for it.
I am so jealous. Either you work alone or you only work with competent programmers. That must be nice.
I’ve worked on projects with brilliant programmers, and this still was a problem. Once the codebase is larger than what a single person can fit in their head, and old enough that it needs refactorings, types save a lot of pain.
I’ve worked with absolute beginners and really experienced people over the years. If you have people breaking production because they passed e.g. a string instead of a number, your tests aren’t good enough.
And to be clear, you don’t test for type. You test behavior and functionality.
A type checker is equivalent to an automatic and concise test for behavior at every call site that involves a string or number that you can’t forget to write.
Not only have I seen this happen with Javascript, but with Ruby and Python as well. However, I don’t believe strong typing is in service to preventing such things. Rather less directly it’s about enabling the powerful type-aware tooling that prevents such things regularly during development and subsequently improving developer efficiency.
I think this is a valid point that strong typing advocates should hear.
Maybe another way to consider it is accident-proofing. I tend to find that by shifting some of the load to the computer, it frees me up to focus more in the logic I’m trying to implement, or change.
You might not need that support, but other folks in your team might, and might even be uncomfortable admitting that.
I can see an argument for TypeScript simply because of how many things you have to more or less memorize to understand what JavaScript will do in a given situation. Introducing a layer of abstraction which doesn’t require that memorization, which lets you write simpler code without worrying about it, and which then compiles to JS that will do what you intended, has utility for me. Though a lot of modern JavaScript has cleaned up the worst bits anyway, so it’s not always a necessity.
As to other benefits of TypeScript… well, I’m not sure I see them, and to be honest I’m not sure I see them in Python (my main day-to-day language), either.
Some of this is just that dynamically-typed languages are different. I think that’s the single biggest hurdle – people who are used to static typing have a certain mindset about how they write code, and often have difficulty adjusting it. I’ve seen people write the equivalent of:
And then they write unit tests where they call the function passing in a bunch of random things just to assert that it raises the expected
TypeError.Which is not how I write code. And not how people who are actually used to dynamic typing write code. There’s a level of what I can only call trust: that if you do by some chance pass, say, a
strto something that expected anint, it will be caught by the test suite. Not because the test suite contains exhaustive checks for all possible types being passed to every function, but because the test suite will exercise the codebase as a whole and the bad path will execute somewhere in there and blow up.And for the most part people don’t go around doing things like passing completely wrong types into functions. After all, dynamically-typed languages have documentation! Including easily-accessible documentation that your editor or IDE can display inline for you! This is actually the only real use case I currently have for type annotations in Python – they’re much less cumbersome than the alternatives, and most tooling now picks them up automatically, so they streamline the documentation process. Which means that instead of writing Sphinx
paramdeclarations to get that part of my docs, I just put in type annotations for most things. I don’t actually run mypy or any other checker, though (for a variety of reasons).But I do think most of it comes down to that lack of trust. I’ve worked on lots of codebases in dyamicallv-typed languages. Including huge codebases with large teams and even teams of teams involved. And I’ve never seen dynamic typing fail to “scale up” the way people always insist it will. Which isn’t to say I’ve never seen failures, just that I’ve never seen failures that were attributable solely to choosing a dynamically-typed language. Scaling up a team/codebase is difficult, and often fails even in projects that use statically-typed languages. People just like to selectively blame languages/type-systems/etc. for issues that were not technical in nature.
I have once or twice seen people who came in with a chip on their shoulder about type systems and tried their best to “prove”, through committing deliberate mischief, that dynamically-typed code can never be trusted. But that’s a people problem, not a programming-language problem. And I’ve seen people who never really were able to let go of their fear give up and just went back to static typing. Where, amusingly, they rarely actually need the type system to yell at them because they do exactly the same things that would have worked in the dynamically-typed languages (like referring to documentation before calling into unfamiliar functions/methods).
Plus, everybody who’s ever tried to rigorously prove that static typing produces better code has failed. Dan Luu’s literature review on this is old, but still very relevant for pointing out the common flaws in such attempts.
What size JavaScript codebase did you work on and with how many other developers?
Pretty much all sizes you can imagine. This goes back pre-jQuery to my current role, from little startups to giant corporate behemoths. Some of the worst code I’ve seen is Java devs trying to write TypeScript at Capital One.
Some companies I’ve worked at that you may have heard of: Capital One, USA Today, ESPN, Nickelodeon
In my experience, removing certain classes of bugs is only half of it. A typed language is also an excellent form of documentation that can’t be matched by manual approaches such as JSDoc.
Approaching a large code add without any types is scary and difficult, especially if the functions use JS tricks such as
argumentsand dynamic function signature overloading.For small systems that one person can keep in their head, then sometimes a typed language can slow you down or feel like it gets in your way. When you have a legs system worked on by 100+ engineers, you are going to pay a heavy price for not using a typed front end language.
Are you referring to this?:
https://tc39.es/proposal-type-annotations/
Yeah. Imagine instead of adding in a bunch of transpiling libraries you would just have the ability to add a plugin to your IDE to give you the same info. That’s the big benefit there.
FWIW:
A few years ago I, like you I think, dismissed TypeScript as another CoffeeScript. It would, at best, influence JavaScript. Eventually the languages would diverge and TypeScript codebases would be marooned with an antiquated version of JavaScript as its compile target—hip today, embarrassing tomorrow.
Instead, a couple of things happened that surprised me. First, TypeScript has maintained (with one exception) a commitment to being a superset of JavaScript and had thus far done a good job of staying up to date with its parent language. Second, it has become immensely popular, the result of which is that the parent language is deferring to its child in this proposal, the intent of which appears to be that we will be able to run TypeScript from source in JS engines without any compilation. TypeScript would presumably then itself be run much as you envision: as a static analysis plugin for IDEs.
The elephant in the room is TypeScript’s
enum, which breaks the “fully erasable” in “fully erasable type system.” This proposal explicitly will not support it. I would like to see TypeScript kill it in its next major version.enum such a small feature that ECMAscript could just add it.
Perhaps a more important change is that the entire team became “full-stack” developers, instead of having a hard front-end/back-end split. That’s huge, in my opinion
agree entirely, splitting on features rather than “which side of the wire” is a huge boost in productivity
One challenge I’ve found in that front is that if you want good frontend developers it’s very hard to find those that are also willing to deal with backend development, or having much of any skill there. There are many good backend developers that are alright at dealing with frontend, but above a certain quality bar it’s basically impossible.
I do think it’s great to be able to have people who can really handle the entire stack, but there are issues with mandating fullstack-ness, so you gotta be a bit careful there. This is “solvable” by pairing people up but then you get into another can of worms based on who you have on the team.
Is that split really front-end vs back-end or infrastructure vs UI? I’ve not done serious web development, but my guess would be that it’s hard to find good interaction specialists but much easier to find people who can write code that runs on either end of a network connection. Are there teams where ‘UI designer’ is a separate role but the engineers work on the whole of the application stack?
So I’ve worked on a team that ended up almost there. There was one “pure” UI designer, and another who was UI design but liked coding. There were a lot of growing pains because he couldn’t properly prototype stuff due to our backend being hard to run for people not used to the terminal.
They both could get work done provided the right tools! But the tooling we had was made (essentially) for backend engineers, so it was a huge amount of friction. That and there was just a different kind of workflow.
But yeah, the overall lesson was that there were people able to do the work we really were missing from the team (remember, the other engineers could write code in both domains! Just the frontend code wasn’t great), but those people could not really work on the team without us adjusting expectations about infra-related demands
How does HTMX make full stack dev any easier? You still need to know about the browser, HTML, forms, etc.
Yes, but we have strong evidence from the old days, pre-SPA frameworks, that server-rendered templates are manageable for developers who also do back end work.
It was only when SPAs and their attendant complexity came along that the split between front-end and back-end became pronounced.
I haven’t observed that at all. Real frontend specialty, like advanced CSS and UX stuff, has always been taken care of by frontend specialists. Everything in between, pretty much anyone can do.
What evidence is that? As amw-zero already said, we’ve always had UI experts for that stuff.
The evidence being that full stack development was a relatively common thing pre-SPA era.
Not saying that there won’t always be designers involved, especially once you start talking about externally facing applications. But htmx puts full stack back on the table as a potential option in a way that SPA libraries and their attendant complexity do not.
I don’t think I would put much stock into it as a hiring manager simply because everyone editorializes their job history and duties. I also don’t care what you made at various places.. why should I? We have a range set and will offer what we think you should be paid (50th percentile of national average for that position, generally). If you agree to it, awesome! Your past pay doesn’t come into the equation.
I have an M1 air because I hate the touchbar, but I think those are gone now on pros. To be perfectly frank, any of them since they fixed the keyboard issues are going to be great in terms of build quality. It really comes down to what you want to spend.
You just convinced me to get an air as next device.
It’s interesting what’s being included under the umbrella of “Typescript” in this post. As someone who’s been writing JS for the better part of 20 years, it’s generally been clear to me what’s JS, what’s Node vs browser, and how Typescript is a layer over JS. But if I was coming in today and trying to learn Typescript I would totally conflate all these things, too.
Some concrete examples:
I would bet that the vast majority of the packages on npm are pure JS with no Typescript support. Factor in popularity and you’ll see a lot more TS, but npm is a Javascript package repo, it predates Typescript by several years. It’s where you get Typescript-supporting packages from, but it’s not of Typescript.
Javascript is also very async-friendly …
100% agree, and this is a place where adding in Typescript does makes things more confusing. It is massively frustrating when you run into module issues, and the sooner the ecosystem can get on the same page, the better. Though I suspect this pain will stick around for years. But the module issue also isn’t really of Typescript.
I accept that these are probably all pointless distinctions to someone who’s trying to write some Typescript and deploy their code!
Aside, since the author is here: I’m not sure if the bit about checking for a successful request is just an example for the blog post, but in case it’s not: Rather than checking the status code, from
fetchyou probably have a Response object, so you likely want the Response.ok propertyI’ve noticed this as well, similarly having used JS for 20+ years. It’s actually somewhat frustrating to me to hear people argue for TS using JS features because it shows a fundamental misunderstanding or lack of knowledge of the ecosystem and language itself.
Not that this blog is arguing these points, but seeing TypeScript thrown around where it’s really just JavaScript is still difficult for me to see. JS is demonized while people sing the praises of TS, but quite frankly, if you could only use JS, you wouldn’t really notice that much of a difference.
Yeah. I am actually aware of some of those distinctions. But you captured my point correctly! As a newcomer, as much as I am aware of those distinctions now, the post documents my journey learning through all of that, so I included some things even though today I know better (And I wish I had taken more notes!)
All in all I am pretty happy: having started my career in the kernel, and now writing Javascript/Typescript… maybe I am finally full-stack?
Thanks a lot for the
Responsetip! I’m learning stuff every day.Personally I found it hilarious, the bit with the response code. Here comes a hard-core systems-language, low-level guy, complains about types and stuff, then assumes that 2.03 equals 2. Like, I thought you guys are precise!
Anyway, nice post for people trying to deal with TypeScript.
Yes, but I’m going to pick on you a bit even though you “admit” this.
The way you describe your examples as “That’s JavaScript, not TypeScript” or by distinguishing between JS, a browser engine, and Node.js is very similar to a scenario in which someone said “I’m switching from Rust to Java” and I chimed in and said “Actually, you’re writing Java on the Oracle JVM.”
“Switching from Rust to TypeScript” could only possibly mean that the code they are authoring is written in TypeScript and that it’s running in whatever runtime matches the use-case that the Rust code would’ve been used for (so, likely Node.js).
Is there anyone who doesn’t know that TypeScript is just a broken type system on top of JavaScript?
One thing that helps in this regard is that libraries are starting to ship ESM-only, meaning if you’re still on the old CommonJS system or you’re using an older version of Node (pre-12), you can’t use that library anymore. This is going to incentivize a lot of people to upgrade, or rethink how they’re approaching JavaScript.
that’s what one would logically assume would happen. But then look at python2 vs python3, which did a similar thing… Took at least 10 years to resolve.
I definitely get that, and as someone who dealt with that whole transition in my own software, I distinctly remember the pain being caused by accidental upgrades to Python 3 or downgrades to Python 2.
But I think the JavaScript package ecosystem is a bit different for a couple reasons:
left-padwould have never existed in Python (you know, assuming Python didn’t have a proper standard library), because it just goes against the culture of packaging in that language. Instead, you might find a library that does all of the string manipulation functions. This is great for a language like Python where you are typically running it on a server, but not so great when you are thinking about pulling dependencies from all sorts of places on the web, essentially trusting the network with your package management.node_modules/is denser than a black hole or whatever, but the truth to that is due to all of the tiny packages in the JS ecosystem, just a single one updating to be ESM-only can cause some real peril in your dependency tree. This is why most libraries are doing CJS/ESM these days, but there are a few that are only distributing as ESM in order to help speed this transition along.I’m not saying that “oh this time it’s different trust me bro”, but I am saying that while there are similarities here, I think the incentive here for not only application developers but also library developers to upgrade is much greater than it was in the Python world when they switched to v3. It also feels a lot easier to me, as someone who had to go from Python 2->3 and has also seen JavaScript go from a language without basic shit like conditionals into the juggernaut that it is today, than Python was because there are tools to compile your code for different environments, like you couldn’t e.g. write a Python 3 program, compile it down to Python 2, and then distribute both versions in the same package. (or can you? if so that’s pretty cool but I had no idea it existed back then)
that’s very helpful context, thank you!
Having this being simpler would definitely be of benefit to everybody, so I am rooting for this
In response to the title line “No-code isn’t scalable” – No-shit :P It’s not supposed to be.
I think this would be better if it saved to SVG by default or had the option to do so. I looked through the docs very briefly and didn’t see any mention of image format, but maybe it’s there somewhere. PNG is ok, but in the world of handheld through giant devices, SVG is better.
The filename extension defines the output format. I changed the following and got an SVG instead. Still looks incredible as well.
I switched from Firefox to Vivaldi when they released the last UI update a few years ago and also broke the setup for everyone I had tried to convert. Every browser has problems, choose which one you can deal with. I’ve learned to love horizontal tabs with tab groups. The UI can be a little slow sometimes, but I’m also a pretty heavy user with 5 windows open and hundreds of tabs. As far as tracking I remember Firefox doing all kinds of phoning home. Most privacy addons exist for Chrome and there are multiple privacy focused variants. I do backups, so I can restore if something fails. Overall I dislike how the article frames it as only two browsers existing in the world.
Privacy addons work better on Firefox, the Chrome APIs are much more limited (especially anything to do with modifying or blocking requests)
I’m also a Vivaldi user and I recommend it every time I can. The UX is great, privacy is a real concern, and they really seem to care about the community.
+1
I’ve been waiting for Vivaldi since opera presto died :)
Out-of-the-box command palette is golden.
If you’re into Object Pascal, Lazarus is all about UI programming like old VB6. Your just have to be into Object Pascal…
I have a wordpress blog I manage - maybe I’ll give this a go to see if it is as easy to use. I prefer static site (and right now have my WP outputting static files), but the whole wordpress environment is a hot mess to get into if you want to mess with templates and internals.
From almost-personal experience (my non-techie wife has Publii), I can say I like it more then something like wordpress. But like wordpress, if you want a lot of flexibility (besides from just a static blog generator), it’s going to come in your way sooner or later.
For regular blogging, however, I like it just fine.
I had issues with it importing my wordpress site. It totally broke the client, made no posts show up, but if I previewed it, it did build correctly. Very strange, but also a deal breaker as I can’t edit old posts or even see new ones.
Company: Mission Lane
Company Site: missionlane.com
Position(s): Many open roles, but I have 2 openings on my team specifically for backend software engineers
Location: Remote (we have offices in Richmond VA and San Francisco if you’re interested in them though)
Description: Because there are so many open roles, it’s hard to pinpoint one description here. I can tell you that we have multiple products, including credit cards, debit cards, and a gigs app to help people find/track their gig income and make informed decisions about how they earn money. (Mission Lane, Mission Money, and Earn by Mission Lane in the app stores)
Regardless which team you work on, you will own your team’s domains and services from start to finish. You’ll build your app, deploy it, and monitor/maintain it. We work closely with our product owners (who are part of the team, not separate and distinct) to put out the most impactful features we can. You will be responsible for writing code, reading code, reviewing PRs, mentoring others, and rotating on-call for your own apps (you won’t be on-call for things you don’t own). While we’re at work, we work! But we take time off and encourage you to maintain your personal life. You will not be expected to work overtime or weird hours. Your time is your own outside of work. There is unlimited PTO, but we truly do encourage people to take it off and not burn out.
Tech Stack:
Compensation: Depends on the pay band, but we pay based on national rates, not local (no matter where you are). Unlimited PTO (that we actually encourage you to take), 401k - 100% on the first 3%, 50% on the next 3% up to 6% for a total company match of 4.5%
Contact: https://boards.greenhouse.io/missionlane – or if you really want you can message me and ask questions. I’ve worked here for about 3 years as both a tech lead and (now) an engineering manager. Happy to give you straight facts on the company / how it is working here.
I use native/vanilla JS for all of my personal projects. There is definitely a learning curve to it, but you can do some really interesting things with no dependencies at all, especially if you only cater to modern browsers. There’s no compilation, transpilation, or even an npm file if you don’t want one.
The problem is that people don’t keep up with the native/vanilla APIs (or in some cases haven’t even seen them), so they make uninformed decisions based on antiquated arguments (e.g. cross browser issues) that no longer apply.
Custom Elements are really quite easy to get a handle on and interesting to use. I’d recommend anyone working in JS on the UI side take a look at them and see if they do provide what you need. Personally, I use a whole lot of
addEventListenerto use pubsub with native APIs. Completely decouples your code and it’s really easy to use.This post can be summed up by “I prefer promise syntax.” The argument that try / catch sucks but somehow Promise.then().then().then().catch() is better or easier to understand is subjective at best. I’ve never met someone who has written a lot of JS who prefers promise syntax to async/await, but I guess there’s a lid for every pot.
I prefer promises to async/await. Async/await is a bad, leaky abstraction. For anything non-trivial you have to fall back to promises (eg
Promise.all). If I’m going to have promises anyway, I might as well just use them everywhere. The other thing is that async/await doesn’t compose at all while promises do.async/await also directs the programmer towards inefficient code by default by encouraging sequential async operations (I see people writing code like that often).
Promises themselves are a bad abstraction though.
allvsallSettledshould have been there from the get-go instead added of years laterdo-like notation soasync&awaitwere rushed out without considering the ergonomics for the parallel APIsWhat JavaScript wanted was an asynchronous
Taskand could have been copied from established languages, but what we got wasPromise. We’d be better off normalizing picking for our projects one of the Fluture library,fp-ts’sTask,Afffrom PureScript, or whatever the API is called ineffect-ts(they are all close to the same thing).Totally agree! It’s just that async/await is even worse, and all I have to fall back on is promises.
Async/await are promises. It doesn’t have to be an either/or choice.
That’s precisely the problem. Is there any value in a tiny bit of syntactic sugar that also encourages inefficient code? In my view, the value is negative.
A lot of the code where this would be used is going to have branching logic and overall not be terribly long anyways, so the emphasis on inefficiency doesn’t really ring true to me.
I will admit to not knowing the intricacies of javascript optimization, but I fail to see how using a syntactic sugar would impact it at all.
This whole discussion sounds like like arguing between the do syntax and the bind operator in Haskell. I for one prefer my monads easier to read. As code should be for reading first and compilers second.
The only thing I will concede is that I have seen developers try to break out of the asynchronous context by assigning variables in the synchronous context. This might be worse in rxjs though. The use of Promise directly does force one to read it as asynchronous compared to missing the async keyword.
They are both silly and limited. They both rely on. Funny looking code. They both introduce disturbance the code execution thredline rather then logically allow the programmer to control when an arbitrary code block is executed. We have to really on somewhat funny syntax.
Both of them are limited to “execute this on the side and when you are ready execute that. But there are no means of controling concurrency. If you want to do thousands of instances of something, both APIs become essentially fork bombs.
Dijkstra wrote down a blueprint for intuitive concurrency (P() and V()) which has been used in many languages for decades. I don’t understand why we have those funny looking things instead of what is tried and true.
Even python went down the path of async wait. The result is a gigantic divider on any python codebase that uses. Any and every little IO operation becomes subject to this great divide. Feels like each time a line if code with IO on it comes, there’s a gun pointed to the head asking: sync or async?
Sure, I agree that both mechanisms are bad, it’s just that async/await is worse. I much prefer the approach to concurrency taken by Elixir/Erlang. I don’t think, however, that semaphores by themselves are the only mechanism we need.
What do you need more than a semaphore and a method to fork execution in two? You could trivialy implement a pool with it.
P/V models a specific concurrency primitive usually known as a semaphore, right? As far as I understand them, semaphores are a useful tool, but don’t represent a solution to concurrent programming in general — am I mistaken?
You can model any concurrency problem using semaphores. That doesn’t mean you want to.
It has been very long since I have red the paper. I don’t remember if it explicitly mentioned that some means of parelelize execution is needed at some point or that was assumed. Fork() spawn(), thread.new(). Whatever it looks like. The problem with old school multi process or multi threading was not the API, but rather the overhead. There is no reason why such an API could not be used with say, green threads. Eventlet does just that.
Yeah this whole article reads like the author wanted to say “I find async/await new and unsettling” without saying those words. And the parallel example feels like a strawman: why would async/await make you forget that you want to wrap parallel work in
Promise.all?I think it’s fine to say “I prefer the old ways” without needing some objective justification.
In a professional setting, you need objective decisions to convince people. It’s very difficult to use your own preferences to change the style of other authors.
Totally. This article is not that, tho.
The post cannot be summed up that way.
I feel like it’s my obligatory “use Vivaldi” comment. The core functionality of Chromium is really great from a technical perspective. What you don’t want is all the “google phone home” nonsense. So just don’t use it. Vivaldi comes with ads/trackers blockers built-in.
Ungoogled Chromium is a much better choice for addressing the concerns expressed in the webcomic.
I don’t really think a cryptocurrency scam is the answer here tbh.
I don’t use Vivaldi, but I think you may be thinking of Brave?
Ah sorry, I usually see people shilling for Brave in these kinds of discussions, so I mixed them up.
I really don’t think a
cryptocurrency scamclosed-source proprietary browser is the answer here tbh.Chrome and Firefox are open-source on paper only. You have no say in how they’re developed unless you work for a trillion dollar advertising company, can’t contribute code unless it’s your full time job, and can’t ever hope to audit even a tiny fraction of the tens of millions of lines of code even if it’s your full time job.
Can’t comment on Chrome, but for Firefox I can personally tell you that is not true. I scratched my own itch in the developer tools when I was in high school. Was it easy? No. Was it impossibly difficult? Also no.
(In fairness though this was easier with the developer tools than with, say, Gecko core.)
Their explanation of why their UI is not open source. To be perfectly honest, though, you’re clearly not coming from a place of honest exploration or debate.
I’m coming from a place of dismissing closed-source browsers. I don’t think that’s unwarranted. We have really good open-source browsers.
When the concern is that Chrome is phoning home and invading your privacy, it seems absolutely bonkers to me to suggest that switching to another closed-source browser is the solution.
At this point you seem to have an axe to grind. We get it. FOSS is good and crypto is bad here on Lobsters.
Serious question: aren’t cryptocurrencies subjectively bad? Some waste energy, some things don’t work, a lot of things are scams., the main use is for illegal trades. Is there something amazing somewhere that I am missing?
We’re going far off-topic from the OP so I don’t think there’s value in starting that discussion here. If you’d like to discuss the topic, I’m always open to DMs discussing stuff, though I get busy and may take time to respond.
There is nothing crypto-related with Vivaldi. It’s just a browser.