Hacker Newsnew | past | comments | ask | show | jobs | submit | asabil's commentslogin

Not Linux syscalls, they are a stable interface as far as the Linux kernel is concerned.


`gen_server` is an abstraction over the a client sending a `request` that a server services to produce a `response` to be sent to the client.

The `gen_server` implementation takes care of things like timeouts, servers terminating before a response is produced as well as maintaining the server state.

You can read more here at [1], [2] and [3].

[1]: https://learnyousomeerlang.com/clients-and-servers#callback-...

[2]: https://www.erlang.org/doc/system/gen_server_concepts

[3]: https://www.erlang.org/doc/apps/stdlib/gen_server.html


I'll add to this that the "abstraction" component of this description is key and the use-case for a gen_server is far more broad than what you might expect in say a networking or web context.

You would use them for instance when you need to group behavioral units with a defined interface, even if you don't require any explicit networking.

This is a bit reductive and wrong in some ways but think of gen_server modules and instances as "sort of" like classes/objects. You "send messages/requests" instead of "calling methods," but the spirit is essentially the same -- it's a way of modeling the world with code


"Computing should be viewed as an intrinsic capability of objects that can be uniformly invoked by sending messages." p 290

1981 "Design Principles Behind Smalltalk"

https://archive.org/details/byte-magazine-1981-08/page/n298/...


> You "send messages/requests" instead of "calling methods,"

Sounds like Smalltalk.


The most dangerous thing about Capitalism is imho its universal equivalence, its ability to make us covert everything into a monetary value.

In other words, it’s just like a programming language where everything can be implicitly converted to a given top type.

In the progress we certainly made over the last century or so, we certainly also lost other things whose value is not representable in our modern value system.


> other things whose value is not representable in our modern value system

What things? Are they more important than child mortality?


Why do things have to be comparable? Why did you cherry pick infant mortality? Yes reducing infants mortality is one of the things where we improved.


I’m not sure I’d ascribe that behavior to capitalism given it long predates capitalism.



Yes, but you don’t end up with different glyphs. Arabic script has letter shaping, that means a letter can have up to 4 shapes based on its position within the word. If you chop off the last letter, the previous one which used to have a “middle” position shape suddenly changes into “terminal” position shape.


I'm thinking even bog-standard European umlauts, cedillas, etc go multi-byte in Unicode? (Take a string of ÅÄÖåäöÜü and chop it off at various byte limits and see.)


This is just the general behavior of truncating strings by code point when they contain decomposed glyphs. This can also impact accents etc.


I don't remember the details, only that it was a bigger deal than with umlauts. I'll see if I can find the talk again.


The underlying problem is lack of isolation, and this is an area where the Erlang process model shines: processes are fully isolated and you can send a signal externally to terminate any process you want.


GC determinism is one of the things you get. Another one is non cooperative asynchronous termination.


Pretty much all efficient GC implementations are inherently non-deterministic, even if predictable.

How can this improve predictability of GC impact?


No global GC. Each erlang process does its own GC, and the GC only happens when the process runs out of space (ie. the heap and stack meet).

You can for example configure a process to have enough initial memory so as not to ever run into GC, this is especially useful if you have a process that does a specific task before terminating. Once terminated the entire process memory is reclaimed.


There is no free lunch in software - the tradeoff is binary serialization and/or data copying over simple function calls. The same goes for GC - for efficient GC, it has to come with quite involved state which has additional cost of spawning. At this point, might use bump allocator, or an arena. Either way, Gen0 (it's a generational GC) in .NET acts like one, STW pauses can be sub-millisecond and are pretty much non-issue, given that you don't even need to allocate that often compared to many other high-level languages.


Vala is very much used among other things by Frida.

I have been involved with Vala in it’s early day and some hardcore GObject/C users never quite liked the C code that Vala generated although it was perfectly valid and exposed a very clean C header to interface with it.

I think that Vala is a really great tool for building applications that make use of Glib/GObject. For example Gtk applications, but also GStreamer and DBus applications.


> I don’t have an example of fully non-cooperative cancellation available off the top of my head.

That would be Erlang.


The UUID spec update has not been finalized yet.

It would be quite unfortunate to end up with a UUID v7 in PostgreSQL that’s not quite the standardized one because the patch got merged too quickly.

EDIT: here is the IETF working group page https://datatracker.ietf.org/wg/uuidrev/about/

Their milestone seems to submit the final proposal by March.


> It would be quite unfortunate to end up with a UUID v7 in PostgreSQL that’s not quite the standardized one because the patch got merged too quickly.

The chances of that seem extremely low at this point. The contents of a version 7 UUID have not changed since work started on RFC 4122 bis in October 2022: https://author-tools.ietf.org/iddiff?url1=draft-ietf-uuidrev...


The chances may be low, but either it's a draft or a final version.

There's clearly little pressure to rush this, considering it's not difficult to add a custom function generating UUIDv7 ...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: