Bah, 2 whole days? I learned React in 1 day!.. then another, and another, and then I got a book, and a few years later… I learned how to fix whatever ChatGPT spits out in React in 2 days!
This person also lectured me on using AI to write code. Saying it was better than a human (in 2023), and that it made him senior level. They practically mocked me when I told them ChatGPT was pretty bad at coding.
Hey, I used to be a “Full Stack Developer”… then I took an arro… went part blind, had a couple heart attacks, got burned out… and still learned how to fix the ChatGPT stuff in 2 days! 😄
I’d say something about them being the type of person to think that just because the car’s running it means the engineering is top-tier, but then again I’d be surprised if he actually bothered really testing the code before saying that shit.
Either way, they sound like a genius and like one day they’re going to become the CTO of a hot new startup that will eventually replace Amazon on the Big Tech leaderboard.
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)”.
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.