It’s almost 100% compatible with node but faster. A lot faster. So no need to learn anything but few cli commands. For example bun run dev instead of npm run dev.
I’m trying to get my work to switch to bun but we have packages in a private AWS codeartifact repo. Does it support this? I tried to use it with our npmrc file but it couldn’t install those packages.
IMO, deno’s approach was bad as it was reinventing the wheel, so one had to relearn. And then they brought package.json which they said they wouldn’t. This again got people to unlearn and relearn things.
Bun, on the other hand, acts like what Typescript is to Javascript. It’s just feels like superset of Node, instead of completely different tool.
Makes sense. Deno was created by the same person that created node. They’re both going to be terrible, especially when they ignore everything ever discovered in software engineering about writing good code, good frameworks, good languages, etc.
gotcha. I don’t think bun is created by the same person that created node. deno is, and has just as bad a design as node as a result. it honestly baffling that people trust someone to write a language who failed so badly to write a language that they set back the entire world for decades to come.
After many years (10+), I finally find a company that actually, really, implements CI/CD. Then I look at the tests and it’s actually the most inane shit imaginable, tacked on top of ancient existing code, not maintained. I spent more time fixing the stupid tests than actually fixing the bugs I was tasked fixing. Amazing.
I can’t really imagine working on any code base that has to actually be maintained and doesn’t have tests. The amount of times that tests have safed my ass at my job are uncountable
And it’s number 1 priority for management to employ as few developers as possible and stretch their team as thinly as possible. Hence still no unit tests in any of the companies I’ve worked at recently, despite everyone knowing they’re worth it, including lip service from management. They just won’t invest in testing, no matter what. One company even fired all the testers then complained to the developers that the product was getting less reliable.
We test the shit out of our Apis. We do more API level/integration testing though.
I.e. a test will be something like “if the db is in this state, and we hit this endpoint with these params, does it return what we expect and update the db correctly”.
Our app is primarily about users maintaining stuff on big datasets with complicated aggregation and approval logic. So setting up a scenario and checking the app does what the business logic says it will do is what we want to know.
It makes refactoring wayyyyy less painful to just know that the app will always behave itself. Rather than testing whether a function can add 1 + 2 correctly, we can test each endpoint does what it’s supposed to do.
It gives us loads of confidence that the backend is doing what it’s supposed to. If you do a huge refactor you don’t need to worry about whether you broke the test or if the test is failing correctly. If the tests all pass everything is working as it should.
Downside is longer test execution times (because a temporary db needs set up) when running the full suite. Worth the trade off for us though.
They never tried to push the language and make it mainstream, but this is somewhat changing since the Haskell Foundation started a couple years ago.
Also, if you only know C or Java, then it looks a bit alien.
I’ve been using it exclusively at work for about 4 years and it makes writing correct code and maintaining it much easier than anything else I’ve tried so far.
haskell is one of the mathematically founded functional languages, which is a whole family of loosely related languages that have seen lower uptake over the years. Other examples include ML and variants, and F#.
There are a few reasons why adoption has been slow:
poor outreach by language founders
less focus on commercial use
novel syntax
core abstractions that differ from mainstream
Many of these are seeing some change. Haskell is getting better at outreach and comercial focus, and Rescript (ml for the web) has a lot of syntactical similarity to ja|ascript.
Yeah, I wish F# was used more often. I actually learned it for fun, and it would be great to work with it. Unfortunately I haven’t heard of any F# job in my country yet.
(I wonder if the F# people have tried doing outreach via F# memes, should work IMO, good names that also fit slang abbreviations are a very contested and already expended word space)
Functional programming requires quite a shift in how you think about designing and debugging code. If you’ve spent your whole programming life thinking procedurally and approaching debugging by stepping through, it’s not an easy mental reset to make. And many languages these days can give you a taste of the functional style without taking away so much that is familiar, giving you some of the advantages of functional programming, such as clean code that’s thread safe and free of side effects. People under time pressure are likely to stop there.
It’s a cool language. Main problem is that it’s difficult to recruit for. Not many developers know Haskell well enough.
Haskell also makes many huge sacrifices for purity. Accessing the file system is quite wonky. Basic stuff like maps aren’t easy to implement either. In the end, it’s a language great for toy examples, but turns into a massive hassle once you want to do real practical stuff.
I think everybody should at least learn it. You’ll learn some cool stuff that will be of use in other languages.
Basic stuff like maps aren’t easy to implement either.
This is mostly due to a preference for immutable data structures. That said, the standard library has a balanced tree-based map that’s not too complex.
If you want a good immutable data structure with O(1) find and update, you’re unfortunately looking at something like a hash array mapped trie, but that’s the same in e.g. clojure or Scala.
The problem Haskell was trying to solve was that in the late 80s, there was a bunch of interest in lazy functional programming but all the research groups had to write their own lazy language before writing a paper on whatever new feature they were interested in. So they banded together to create Haskell as a common research program that they could collectively use.
It’s been remarkably successful for a research language, and has become more practical over the years in many ways. But it’s always had the motto “avoid (success at all costs)”.
What’s possible for web apps today is insane considering where it started. I remember when AJAX was a brand new technology, and now you can do videoconferences with screenshare right in a web browser.
I think the push toward apps is because of influence from mobile. Everyone wants their own app, just like everyone wanted a dot com in the 90s. Hopefully we’ll stabilize around browsers and open standards.
Hopefully we’ll stabilize around browsers and open standards.
I would love this, but I think it will require major privacy reform. The push toward apps comes overwhelmingly from a single source: surveillance capitalism.
The push towards apps is due to a collection of corporate interests that are of dubious value to the end user.
Apple, Google, and Microsoft prefer apps over websites because they can exert much more control over their functionality and operation (as well as collect that sweet sweet 30% royalty on all digital purchases). This is why they intentionally make Home Screen bookmarks so unintuitive and inconvenient compared to downloading an app (at least on iOS and Windows; not sure about Android). They’re also more difficult to make cross-platform, although this is becoming less and less of an issue as cross-platform libraries evolve).
App developers push for apps because they’re much stickier (especially due to the aforementioned bookmark situation; it’s all very intentional). Their app is right at the user’s fingertips until they explicitly decide to delete it. For streaming services and the like, app SDKs also tend to offer more robust DRM than their browser counterparts. That’s why, e.g., Hulu cripples their streaming bandwidth on browsers like Edge while their Windows app is not, even though their Windows app is very obviously just an Edge WebView 2 window. It’s pathetic, but it’s something they can point to in a meeting with their investors and say, “See? We’re doing something about piracy!” as if one trip to a piracy website doesn’t refute all their hard work.
It took a wrong turn in the 90s. There's been no real feasible way to fix it without breaking the web for many decades now. Some things are just forever despite their problems, like QWERTY.
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.