Search by Typesense

We found 292 results.

Changelog & Friends Changelog & Friends #28

Gradually gradually typing Elixir

Play
Featuring José Valim Featuring Jerod Santo Featuring Adam Stacoviak
2024-01-27 #elixir 🎧 19,194

Our old friend José Valim & his team have been hard at work adding gradual typing to Elixir. They’re only 1-3% of the way there, but a lot of progress has been made. So, we invited him back on the show for a deep-dive on why, how & when Elixir will be gradually typed.

Matched from the episode's transcript 👇

José Valim: So before that tweet, let’s say, Elixir was a dynamically-typed language. And one of the ways that you can think of a dynamically-typed language is that it’s a “statically-typed” language where all the functions, all the inputs are dynamic, and then it returns dynamic. So everything that you receive is dynamic, everything returns dynamic, and dynamic means “I don’t know what is the type at compile time. I know at runtime.” So if I try to add a number to a list, which is not possible in most programming languages, you are supposed to – in Elixir you’re going to get an error at runtime. But if you had a static typed system, you could potentially catch that error at compilation time.

So Elixir was a dynamically-typed language. And being a gradually-typed language means that you have the dynamic, but at the same time you have the dynamic, you can also have precise type information. So what the tweet was saying is that “Well, instead of Elixir analyzing all the variables, all of your inputs as dynamic, now we are doing inference on your patterns and guards, which are very common in Elixir code.” So in your pattern, you can say “Oh, I’m going to match on a list. You can use a guard to say “Oh, this thing is a number, or an integer.” We are getting that information to say “Oh, so now I know that this variable is no longer dynamic, and it’s actually an integer, and it’s a list.”

And now that we are mixing this dynamic world with this little bit of type information, now it’s officially gradually-typed. And that’s correct, but it’s more it’s officially gradually-type, but we are at 1% of the journey. And that’s what the following tweets meant to say.

So if you think about everything you can do in a pattern and in a guard in Elixir - you can check if it’s an integer, if it’s a function, you can pattern-match on maps, on tuples, on lists - we only understand one construct right now, which is the binary matching and the binary construction. So of all the things in the language, we understand one of them. But getting to this one is super, super-hard. It’s literally two years of research have passed… So getting to this one was super, super-hard. Now getting to the next ten is not going to be as hard… But yeah, we are officially gradually-typed, but it’s we are 1% gradually-typed, if that makes sense.

JS Party JS Party #103

You're probably using streams

Play
Featuring Matteo Collina Featuring Nick Nisi Featuring Kevin Ball
2019-11-22 #node +2
🎧 9,728

This week we chat with Matteo Collina, Technical Director at NearForm and member of the Node.js Technical Steering Committee, about his upcoming Node+JS Interactive talk on Node Streams. We talk about their creation before any standards and how they are one of the bedrock APIs used throughout the Node ecosystem. We also talk about WHATWG streams and some of their key differences, and how streams have gotten easier to work with thanks to the addition of async iterators and generators to the language.

Matched from the episode's transcript 👇

Matteo Collina: It’s a little bit more complicated, but essentially yes. It’s a very basic level of – you know, On emits multiple events at the same time, but a promise only gets you one. And this is the core difference between promises and EventEmitter. Essentially, the fact that they’re based on very different building blocks means – this percolates in a huge amount of fashion. The protocol is very different… It’s the same concept and the same logic most of the time, it’s just very different, because one is based on EventEmitters, and the other one is built upon promises. So in one sense we could emit an event to get some data processed, while on the other side it would probably call a method that returns a promise. So the flow is completely different.

In one case, in order to get a function called, I register a function called in the other side, I pass an object and that gets called. It’s completely different. It’s a different approach to the same topic. Essentially, mixing the promises and EventEmitter, you end up with some really bad things in there.

post Icon changelog.com/posts

inception - The movie, explained through C code

logged by logbot 2011-02-23

I’ll be honest: this is one of the cooler things I’ve seen recently:

/*
 * Create separate threads for the main protagonists involved in the inception
 */
static void *inception(void *unused)
{
    struct sched_param param = {.sched_priority = 99 };
    int policy = SCHED_OTHER;
    if(!getuid() 
       ||
       !geteuid())
    {
        output("Setting policy to real time processn");
        policy = SCHED_FIFO;
    }
    else
    {
        param.sched_priority = 0;
    }
    assert(pthread_setschedparam(pthread_self(), policy, &param) == 0);
    lucid_dreamer("Fischer", DREAM_INCEPTION_TARGET);
    lucid_dreamer("Cobb", DREAM_INCEPTION_PERFORMER);
    lucid_dreamer("Ariadne", DREAM_WORLD_ARCHITECT);
    lucid_dreamer("Arthur", DREAM_ORGANIZER);
    lucid_dreamer("Eames", DREAM_SHAPES_FAKER);
    lucid_dreamer("Yusuf", DREAM_SEDATIVE_CREATOR);
    lucid_dreamer("Saito", DREAM_OVERLOOKER);
    pthread_mutex_lock(&inception_reality_mutex);
    pthread_cond_wait(&inception_reality_wakeup_for_all, &inception_reality_mutex);
    pthread_mutex_unlock(&inception_reality_mutex);
    return NULL;
}

That’s right: karthick18’s ‘inception’ repository contains a 1900 line C program that simulates the plot of the movie Inception. How, you ask?

We need to go deeper.

Have you heard of the Dining Philosopher’s problem? Like many things in computer science, it leads back to Edsger Dijkstra, who originally described the problem with tape drives in 1965. Here’s a summary:

Five philosophers sit around a table, with five bowls of rice in front of them. In between each bowl of rice is a chopstick. A philosopher can do two things: think and eat. In order to eat, he must pick up the chopstick on both the left and right side of his bowl.
dining philosophers

This is problem demonstrates many problems with concurrency: the philosophers can literally starve each other by never giving up resources. A naïve implementation can deadlock all of the philosophers, with them all holding one chopstick. Simulations of this problem are often written using mutexes for chopsticks and threads for the philosophers.

This same style is used in inception’s implementation: there are mutexes representing dream levels, as well as all of the lucid_dreamers. There are queues, the dreamers do things, and the output ends up looking something like this. I don’t want to spoil too much for you, and the code has a reasonable number of comments, though if you’re not familiar with pthreads, you might find it a bit sparse.

Totally cool.

The code on GitHub.

Go Time Go Time #122

The Zen of Go

Play
Featuring Dave Cheney Featuring Mat Ryer Featuring Johnny Boursiquot Featuring Carmen Andoh
2020-03-19 #go +1
🎧 16,757

Dave Cheney talks to us about the Zen of Go (ten engineering values for writing simple, readable, maintainable Go code). What makes code good in Go? What guiding principles should we bear in mind when writing Go?

Matched from the episode's transcript 👇

Dave Cheney: I’ll give you another example of where something could be overused. In my first talk at dotGo I wanted to talk about Rob Pike’s functional option pattern, and how I applied it in the design of some code that I was working on. Two years later a number of people had said to me “Look, I really like that talk, but I’m not sure that to other people I can propose these ideas. It’s too weird. Like, this idea of anonymous functions that return anonymous functions - it’s too weird.” That was kind of the impetus for another talk about “Hey, free functions are a thing. We should use them.”

But it’s a realization that that is probably – like, if everything in your codebase is functions that return functions that call functions, that’s a really big innovation in tech. You’re mixing that with heavy channel use and heavy goroutine use - that’s a pretty pro level move. That would be one of those cases where you seem to have used all the features of the language. Isn’t that gonna be a little bit hard to follow?

Changelog Interviews Changelog Interviews #631

Antirez returns to Redis!

Play
Featuring Salvatore Sanfilippo Featuring Adam Stacoviak Featuring Jerod Santo
2025-03-07 #redis +2
🎧 18,960

Antirez has returned to Redis! Yes, Salvatore Sanfilippo (aka Antirez), the creator of Redis has returned to Redis and he joined us to share the backstory on Redis, what’s going on with the tech and the company, the possible (likely) move back to open source via the AGPL license, the new possibilities of AI and vector embeddings in Redis, and some good ’ol LLM inference discussions.

JavaScript changelog.com/posts

Quickly reduce the amount of data your node API returns

logged by logbot 2014-03-05 #javascript +1

When designing an API, it’s easy to forget that not everyone has a cable modem. What if a client could easily request exactly the data it needed. That is what JSON Mask aims to do.

This is a tiny language and an engine for selecting specific parts of a JS object, hiding/masking the rest.

A code example helps to demonstrate how this works.

var mask = require('json-mask')
mask({p: {a: 1, b: 2}, z: 1}, 'p/a,z')  // {p: {a: 1}, z: 1}

JSON Mask seems like an interesting way to reduce the amount of data we send down the pipes.

Databases brandur.org

Soft deletion probably isn't worth it

logged by jerodsanto 2022-07-20 #databases +1

This article confirms my biases because I’ve always despised every soft delete implementation I’ve come up with. Most of them have looked something like what the author describes:

the technique has some major downsides. The first is that soft deletion logic bleeds out into all parts of your code. All our selects look something like this:

SELECT *
FROM customer
WHERE id = @id
    AND deleted_at IS NULL;

And forgetting that extra predicate on deleted_at can have dangerous consequences as it accidentally returns data that’s no longer meant to be seen.

ORMs help with this, but not enough. You set it as a default scope and then there’s that one time where you also want the deleted records so you come up with a custom query or dig into your ORM and try to find how to bypass the rule. Yuck!

He goes on to describe other problems as well. Maybe it’s all a big case of YAGNI?

Once again, soft deletion is theoretically a hedge against accidental data loss. As a last argument against it, I’d ask you to consider, realistically, whether undeletion is something that’s ever actually done.

When I worked at Heroku, we used soft deletion.

When I worked at Stripe, we used soft deletion.

At my job right now, we use soft deletion.

As far as I’m aware, never once, in ten plus years, did anyone at any of these places ever actually use soft deletion to undelete something.

Python github.com

An open source, online reverse dictionary

logged by jerodsanto 2021-11-09 #nlp +2

This is the first time I’ve heard of a reverse dictionary, but now that I have… so cool!

Opposite to a regular (forward) dictionary that provides definitions for query words, a reverse dictionary returns words semantically matching the query descriptions.

Ever had a word on the tip of your tongue and you Just. Can’t. Think of it?! Reverse dictionary!

An open source, online reverse dictionary

PostgreSQL blog.crunchydata.com

Generating JSON directly from Postgres

logged by jerodsanto 2021-07-21 #postgresql +1

Too often, web tiers are full of boilerplate that does nothing except convert a result set into JSON. A middle tier could be as simple as a function call that returns JSON. All we need is an easy way to convert result sets into JSON in the database.

PostgreSQL has built-in JSON generators that can be used to create structured JSON output right in the database, upping performance and radically simplifying web tiers. Fortunately, PostgreSQL has such functions, that run right next to the data, for better performance and lower bandwidth usage.

I certainly wouldn’t advise this in many (most?) scenarios, but I can see a time and a place where “cutting out the middle man” would be quite advantageous, indeed. Keep it simple. Keep it lean.

Testing sobolevn.me

Make tests a part of your app

logged by sobolevn 2021-03-17 #testing +1

Here’s a pretty useful idea for library authors and their users: there are better ways to test your code!

I give three examples of how user projects can be self-tested without actually writing any real test cases by the end-user. One is hypothetical about django and two examples are real and working: featuring deal and dry-python/returns. A brief example with deal:

import deal

@deal.pre(lambda a, b: a >= 0 and b >= 0)
@deal.raises(ZeroDivisionError)  # this function can raise if `b=0`, it is ok
def div(a: int, b: int) -> float:
    if a > 50:  # Custom, in real life this would be a bug in our logic:
        raise Exception('Oh no! Bug happened!')
    return a / b

This bug can be automatically found by writing a single line of test code: test_div = deal.cases(div). As easy as it gets! From this article you will learn:

  • How to use property-based testing on the next level
  • How a simple decorator @deal.pre(lambda a, b: a >= 0 and b >= 0) can help you to generate hundreds of test cases with almost no effort
  • What “Monad laws as values” is all about and how dry-python/returns helps its users to build their own monads

I really like this idea! And I would appreciate your feedback on it.

Go Time Go Time #148

The one with Brad Fitzpatrick

Play
Featuring Brad Fitzpatrick Featuring Johnny Boursiquot Featuring Mat Ryer
2020-09-24 #go 🎧 15,339

Brad Fitzpatrick returns to the show (last heard on episode 44) to field a mixed bag of questions from Johnny, Mat, and the live listeners. How’d he get in to programming? What languages did he use before Go? What’s he up to now that he’s not working on the Go language? And of course… does he have any unpopular opinions he’d like to share? 😏

Player art
  0:00 / 0:00