This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-05-02
Channels
- # announcements (1)
- # babashka (4)
- # beginners (39)
- # calva (36)
- # cherry (11)
- # cider (23)
- # clj-on-windows (3)
- # clojure (105)
- # clojure-brasil (1)
- # clojure-chicago (3)
- # clojure-conj (8)
- # clojure-denver (4)
- # clojure-europe (18)
- # clojure-germany (5)
- # clojure-hungary (13)
- # clojure-nl (1)
- # clojure-norway (31)
- # clojure-sweden (9)
- # clojure-uk (2)
- # clojurescript (22)
- # core-async (4)
- # cursive (8)
- # data-science (25)
- # datomic (14)
- # devops (1)
- # emacs (9)
- # events (5)
- # holy-lambda (32)
- # hyperfiddle (26)
- # introduce-yourself (2)
- # kaocha (1)
- # leiningen (11)
- # lsp (17)
- # malli (8)
- # off-topic (84)
- # pedestal (4)
- # polylith (2)
- # re-frame (17)
- # reitit (1)
- # releases (1)
- # remote-jobs (1)
- # shadow-cljs (8)
- # sql (4)
- # tools-deps (8)
- # transit (5)
- # vim (1)
- # vscode (1)
- # xtdb (45)
Something for May the Fourth (be with you) https://youtu.be/d-8DT5Q8kzI


Slack is going to block me for using the latest extended-support Firefox version, what the hell
Yeah, I've been getting a bunch of emails from Slack HQ (I own three workspaces) about the various clients they're going to stop supporting... I suspect quite a few people will be affected but there's nothing we can do. I'm a bit surprised at just how aggressive they're being about actually blocking people instead of just saying "Your browser is unsupported, proceed at your own risk" kinda thing...
Iām not sure what specific features Slack depends on, but most websites will feature test and default to some error page if a feature test fails, telling the user their browser is unsupported. There may be something introduced in Firefox 104+ that Slack now relies on, but nobody can know for sure, unless they can take a look at the Slack codebase
for a concrete example of this, disable wasm and go to http://regex101.com, itāll falsely claim your web browser is too old for the site and to use the latest Chrome/Firefox/etc.
been blocked for using Brave, its definitely annoying, you'd hope that such a big-boy-corporate chat-tool used everywhere would respect compatibility a little more
Look, I'm not going to show slack any respect here, but Firefox's market share is minuscule and shrinking
That statistic likely includes mobile browsers, which will make Chrome and Safari numbers larger than they are for desktop
I highly doubt there are more Safari users than Edge users on desktop, since Edge is bundled in Windows itself
If we want to believe statcounter: Firefox on desktop has 5.65% marketshare worldwide, and depending on the country you look at, the marketshare can be as high as 17.6% (Germany)
feels like the classic 'too big to care' like most other entrenched platforms nowadays
Firefox is sadly fading into irrelevancy in the stewardship of Mozilla who's out to lunch
re: Slack firefox policies: Good question. IME most web devs only test and target Chrome anyway. If youāre unlucky, you may have to care about IE11ā¦
But IME Firefox is just not something web devs will typically target because most websites will be mobile first, and globally Android is the dominant mobile OS, where Chrome dominates the web browser share. As for desktop, I assume most people are fine enough targetting about 63.5% of the world
Itās actually a bit sad because there are some CSS features I want to use at work, but I canāt because only Firefox and Safari support them (ahem, CSS subgrid and modern color features)
"Modern" versions of Firefox (and other browsers) continue to be supported so it's not like they're singling out Firefox...
The OP is using 102 and 91 and older are already blocked.
Also, Firefox ESR is kind of unique in that no other browser really offers a ālong-term supportā version, at least not a freely available one. I know Chrome Enterprise exists, but Iām not sure which exact version of Chrome the enterprise edition currently branches off from, and even then it is not for use by the āgeneral populationā and I have never seen it show up in a browserslistrc
and now they slashed the dev team for thunderbird; I doubt their commitment to making good influential technological product
ā¦wasnāt the thunderbird event nearly 10 years ago? unless something new happened that Iām not aware of
for context: this is what I assume youāre referring to, but it is old news (2012): https://www.phoronix.com/news/MTEzNDc
Well, if you can find a source, Iād greatly appreciate; something to add to my pile of āmozilla doing strange thingsā š
I tried several times to make a switch from chrome to FF but it never stuck. For various reasons. Nothing major I just always missed chrome and went back. Then recently I shifted to Brave and it has stuck. Granted that's not really a fair comparison because Brave uses chromium, but it's pretty clear from using brave for a bit that their idea is to put the user's experience first in all ways they can, especially when it comes to the huge pile of annoyances and anti-features that the web has become. Built in ad block, max privacy configuration options, built in news paywall blocker thing. first class vpn/tor. Pretty nice email/phone/identity cloaking thing in beta. In retrospect that was a very low hanging fruit mission statement for FF to adopt for a decade but instead they just kinda hung around as a "not chrome" option and did weird branding things. I think if they had that notion of user-first/anti annoyance in their dna it wouldn't have struggled to have compelling things to offer compared to chrome
As this thread already is on-topic for #C03RZGPG3 and by going off-topic, I add my personal browser journey: Netscape -> IE -> Firefox -> Chrome -> Firefox -> Arc And Arc is by far the most innovative browser in years I especially like the left sidebar, split views, and capturing CTRL/CMD+T for the command prompt. Oh and the little Arc for opening links instead of a big browser window. In case you don't know it: https://arc.net/
Slack is pretty unequivocal on this: https://twitter.com/SlackHQ/status/958645632620748800
ironically, many websites do not follow WebRTC standards and instead hard code features against Chrome quirks; this is why Teams cant support Firefox in video calls. I wonder if this is why Slack in 2018 couldnt support Firefox either. I sure love being back in the IE6 days
I thought this comment from someone in my local dev slack was both entertaining and insightful (personally I lean toward Datomic moderately often, but when I don't, it's 99% Postgres):
you can go even ādeeperā š https://www.levels.fyi/blog/scaling-to-millions-with-google-sheets.html
"just use boring tech" is pretty interesting to see in a niche language community
I'm a fan of the idea that you can use non-boring tech in a few places & should usually make the rest pretty boring š (unless eg it doesn't need to be highly reliable)
This is why I generally reach for MySQL: it's simple and reliable and boring...
there's this pattern in progressive movements that maybe applies here. the pattern goes like this... so, there are two groups within a movement. one group pushes hard for more significant, immediate change. the other group pushes for slower, more incremental change. the former is generally seen as less conservative and the latter is seen as more conservative. the more conservative group sees the other group as irresponsible and unrealistic. the less conservative group sees the other as stuck in old ways an unable to imagine and try for a better future today. the thing is, the more conservative group always has the easier argument, after all incremental change is the norm and smaller increments seem more achievable. the trouble is that if the less conservative group vanishes, and they often do just leave, the resulting group would eventually have another split with a similar issue. the remaining group would have a more conservative half and a less conservative half with the same problem. and it just inches ever more conservative as groups splinter off over time. eventually you stagnate. anyways, the reason I mention this is that tech seems to work at least a little bit like this, too. "just choose boring tech" can drive off the people who would choose new things and drive change, leaving groups more and more conservative and stagnating. often the people who don't choose boring go off and make their own little world and become the boring tech eventually but that's another story. I don't think that's necessary, though. I think communities and organizations need both folks, and there's a place for taking risks for new things and place for choosing boring stuff. using new stuff doesn't have to be irresponsible, and using boring stuff isn't always the right choice
Corollary. Teams that can accommodate a diversity of attitudes (at least in this respect but maybe others) might stick together longer.
My Clojure/West talk way back (2012) was called "Doing Boring Stuff with an Exciting Language" š
(because I was using Clojure for "dull" stuff like talking to MySQL and sending emails etc)
> I think communities and organizations need both folks, and thereās a place for taking risks for new things and place for choosing boring stuff. using new stuff doesnāt have to be irresponsible, and using boring stuff isnāt always the right choice Agreed! And I mean, personally I lean temperamentally toward exciting tech ā but at the same time Iāve seen projects collapse because people chose lots of exciting tech, and the interactions between all the shiny new things were too hard to predict in advance. So I like to have a really predictable foundation and use it as a base for a couple of exciting decisions that can play a big role in accelerating / improving the core purpose of the project.
i think there can be exciting things happening in SQL, too! I donāt know what makes it seem boring - I also think of the original post is getting at something i hold pretty dear, which is to do the simplest thing that could possibly work, if i donāt already know what needs to be done
i think that that can generally be done with āboringā tech just as well as āexcitingā tech
even the simplest thing that could work can be short-sighted when a small investment can prevent mountains of very likely pain
I think my point in general is that the "sneering conservative" argument is by far the easier one to make and it's not the right one in the long run, and that mantras shut down our strongest advantages, which are to observe and learn and adapt and grow
Clojure data is not typed checked and you are often dealing with highly nested data, but SQL is (usually) strongly typed and (usually) encourages normalisation to deal with nested data. The SQL language can be pretty verbose even for simple things (e.g. "get 3rd to 9th most frequent element from table " can be difficult in several SQL dialects). SQL doesn't work badly with Clojure, but it's also feels far from ideal. I find document oriented DBs (e.g. Mongo) seem to work quite well with Clojure (no data type checking and support for deep objects). Obviously they can have their own separate issues.
> I think my point in general is that the āsneering conservativeā argument is by far the easier one to make and itās not the right one in the long run, Ah, interesting, I didnāt read this as a āsneering conservativeā argument at all ā but I know the person who wrote it, so Iāve got a sense of their personality that other folks donāt. It may have come across differently in isolation. FWIW the context was someone asking about using a SQL DB vs MongoDB, and between those two choices Iād go with Postgres too š Certainly I think that many devs turn to hyped tech, including hyped DBs, too quickly. If you have the time and energy to carefully consider the tradeoffs on different DBs, it might very well make sense to adopt something less common. But for people who arenāt in a good position to really research options and consider the tradeoffs, eg for relatively junior devs or people under too much time pressure, I do think PostgresQL is probably the leading candidate for ājust choose this and youāre pretty unlikely to be up at night freaking out about your database.ā I feel like itās relatively low on footguns compared to a lot of other choices.
> Clojure data is not typed checked and you are often dealing with highly nested data, but SQL is (usually) strongly typed and (usually) encourages normalisation to deal with nested data. The SQL language can be pretty verbose even for simple things (e.g. āget 3rd to 9th most frequent element from table ā can be difficult in several SQL dialects). SQL doesnāt work badly with Clojure, but itās also feels far from ideal. Valid point! & itās one of the reasons I lean toward Datomic (or equivalent) a fair amount of the time. In my own experience itās often useful to have types or something typish in certain places in a system, and the DB layer is often a good place for that. In a couple of projects Iāve leveraged the DB schema as the basis for specs to be used for validation at the opposite edges of the system, ie incoming data, and thatās been nice (although the first time I did it taught me kind of painfully that there has to be a way to override those generated-from-db-schema specs, because there are certain cases where the DBās conception of types and specās conception of types and your internal model of domain objects clash).
Another part of the original context is that it wasnāt directed at Clojure programmers, so itās definitely not taking into account the specific tradeoffs that work well for Clojure ā it was intended as much more general. (& in retrospect, it may or may not have been useful for me to recontextualize it into a Clojure slack š)
> I didnāt read this as a āsneering conservativeā argument at all I was translating the political movement context from my wall of text, where the "sneering conservative" side as it's often seen is just a much easier argument to make, I didn't mean that about your friend. apologies for not making that clear! I can see how it was... uhhh poorly stated š¬
Oh, gotcha, my mistake! Although it definitely seems plausible to me that āsneering conservativeā could translate at least sometimes to āsneeringly conservative technologistā. eg I remember encountering it in my long-ago Java days, Java programmers who were like āwhy would anyone use these totally immature languages, especially <grimace> scripting languagesā š
It turns out that no matter what technology you pick, there's a good chance for misuse. Even with "boring" technologies like mysql and postgres I see every now and then blog posts about companies getting incredible performance and scale out of them where others would sweat at 1% of that problem. It's not the technology. It's the people
And specifically on the issue of taking risks, harking back to "no one ever got fired for buying IBM", it has merit. We need to trade off risks and rewards, and everyone falls on a different place on that curve, but one important thing to remember, if this isn't my business, I'm being trusted to not take a risk that will negatively impact the business just to satisfy my intellectual curiosity
the "just to" is important there
Heck, never mind that, even if it's the right call it doesn't mean management or even colleagues are on board. Change scares people. They'll do the first thing they were taught forever
selling people on change is hard, that's for sure
And change for the sake of change isn't a selling point, in that, they're correct I must demonstrate it's preferable + cost of change
in my experience part of being responsible about advancing new technology in the organization is making small bets where you can limit the fallout if things go poorly. send up trial balloons, if you can, and share results. take acceptable risks
> It turns out that no matter what technology you pick, there's a good chance for misuse. True! At the same time though, I do think there's a meaningful & important axis running from tools that make it hard not to shoot yourself in the foot, to tools that usually won't injure you even if you mostly just go with the defaults.
The tools that make it hard to blow your foot off make the immediate and initial very easy, but breaking out of this box is extremely difficult. The risky tools, like power tools, enable you to do things you couldn't otherwise. I doubt there are "safe" high powered tools
I disagree. I would say one of the advantages of simple tools (in the RH sense) is to minimize footguns even at the cost of a learning curve. eg ubiquitous mutable state is the classic easy-but-not-simple technique, and it's a massive footgun. SQL also happens to be easy in the sense that it's probably the most familiar DB for most devs, but that doesn't make it not simple. I'd argue that it's quite simple in many ways (obviously it's a very large tool and there's inherent complexity there, but it has pretty clean separation of concerns, is backed by a rigorous algebra, etc). It's not always the simplest tool for the job, eg if the job at hand requires only simple key/value storage, but it's often a really good tool to choose. Agreed that some simpler tools are also riskier (eg Linux is framed that way in Neal Stephenson's classic "In the Beginning was the Command Line" essay), but I don't think there's complete correlation there. Possibly we just have different connotations for 'footgun', though? I'm thinking less 'things that people are likely to trip over the first time they use a tool' and more 'problems that are hard for even competent practitioners to avoid.'
Back to @U02N27RK69K's point about small bets and limiting fallout: that's a really interesting observation but what can we do to mitigate the risk in selecting large, cross-cutting tools like databases? When I got very enamored of MongoDB, I initially arranged for us to double-publish - writing data to both MySQL and MongoDB - so we could look at the same data both ways, then added migrate-on-demand where a read of MongoDB data would copy it from MySQL if it wasn't already in MongoDB, and then started to consider MongoDB as the source of truth for new data we recorded. Ultimately, we abandoned MongoDB and had to migrate a lot of data back to MySQL (some of which was migrate-on-demand the other way, some was done by batch jobs backfilling "holes"). So, choosing MongoDB was a mistake - could we have figured it out sooner, or mitigated the work/risk?
Sounds like you did (largely) mitigate the risk, by double-publishing and building automatic migration tools. Or am I missing something?
if I didn't have experience using the db at the scale needed, and operating it at that scale, I wouldn't switch to it on a large app without a very strong reason for it. I'd deploy it as part of a smaller application first to get experience using and operating it. it's like learning to ride a bike, start at slow speeds on flat ground, maybe put on some pads in case you fall.
use strategic risks to push forward adoption of new technologies that give your group significant gains without also betting the whole farm on it
> Sounds like you did (largely) mitigate the risk, by double-publishing and building automatic migration tools. Or am I missing something? Yeah, I'm not sure we could have done more. I'd spent a lot of time talking to MongoDB users before we started to try it out, and we added the double-publishing incrementally... But it's hard to abstract away persistence when you have SQL/relations on one hand and document-based storage on the other. I'm always curious to hear from other folks who've migrated from one DB stack to another -- even if it's just part of their overall stored information. I'd be very interested to get XTDB in at work, for the bitemporal stuff specifically, but after our experience moving to/from MongoDB I'm more hesitant now... š
almost 13 years ago(?) now I got a startup to adopt riak as a secondary key value store. it mostly worked out and we used it for maybe 8 years but basho had gone under and operating it had become a pain. luckily because it was just a huge key value store it was easy to move to something else (we just moved to a second postgres db, the HA story of whatever managed postgres provider we were using at the time was good enough at that point and our uptime needs had decreased enough that postgres was now good enough)
Oh, wow... I remember Basho and Riak... I still have one of their T-shirts...
I have one of their pint glasses and a couple of hoodies from their conferences š
Coming to this conversation, I remember when we had a page that was really slow, and my task was to add a redis cache to make it faster. I basically removed ALL caching that we were doing and made an optimized SQL query.
Original page was taking 2 minutes to load, went down to 130ms. The thing is, most people don't know how to use SQL and decide that "it's not good" because of it.
a common thing I see is people being forced into suboptimal queries because of inflexible ORMs
ORM. There's your problem, right away! The Vietnam of Software Engineering... š
they make simple things a dream and complex things a nightmare