News for hackers. Stuff that matters.

posix_monad

Re:Types as Interfaces on Tuesday July 23, 2024 @09:56AM (#41046077)
With mergeMaps, you don't have to write out all of the properties.
Re:Types as Interfaces on Tuesday July 23, 2024 @06:06AM (#41044408)
MLs require a lot of ceremony modelling simple record types.

What we want to express here is an object with a map of properties (name to type):

    string Type map
For the OOP minded:

    Map<string, Type>
And also compose those:

    type Foo = { "_foo", int }

    type Bar = { "_bar", string }

    type FooBar = mergeMaps Foo Bar
But at compile-time, of course.

Have any languages achieved this? I know TypeScript can do some of these things, but it's clunky.

Re:Little Languages (1986) [pdf] on Thursday July 18, 2024 @11:22AM (#40996427)
Building a language is too hard.

You need to create:

- Grammar, parser, compiler, interpreter (delete as appropriate)

- Editor plugins for nice syntax highlighting

- Language server

- Packages for common things

- Nice website (or no one will use it)

- etc...

So the pressure is always to shoe-horn a big existing language into you problem. Maybe you can build a nice library if your language has decent syntax (or little to no syntax). If you have an AST representation, you probably dump it to JSON etc.

I am curious if any projects are trying to make this easier.

Does MongoDB have serious market share compared to DynamoDB (and similar clones from Azure, GCP) at this point?
Yes, this is a reasonable approach, but how are certificates deployed and managed?

How do we deploy a list of certificates that a service should accept?

How do we do certificate rotation and revocation?

Ask HN: How do you approach service-to-service authentication?

Services often need to talk to each-other, but how should they control access?In an ideal world, callers can prove who they are to services and services only grant access to a minimal set of consumers. There should be low boiler-plate for maintaining service identities and things like token revocation, secret rotation, etc. should be "easy". Bonus points for avoiding vendor lock-in.What...

( Read More... | 4 comments | on HN )
Re:Our Underground Future (2012) on Friday June 28, 2024 @02:11PM (#40823327)
Re:The unusual economics of the Birkin handbag on Monday June 24, 2024 @04:36AM (#40773695)
Vast majority do not have the disposable income to invest in stocks.
Re:OpenAI Acquires Rockset on Friday June 21, 2024 @12:28PM (#40751164)
Nah, that was Postgres vector extensions
There is a value in living in a society that is culturally rich, not just GDP rich.

The last era where we had this kind of society, was probably the 70s and we are still recycling the cultural artefacts of that time.

That solution doesn't work for Meta. Who on earth would choose to opt-in?
Re:Home-Cooked Software and Barefoot Developers on Wednesday June 12, 2024 @06:33AM (#40656527)
Copilot (and so on) are simultaneously incredible and not nearly enough.

You cannot ask it to build a complex system and then use the output as-is. It's not enough to replace developer knowledge, but it also inhibits acquiring developer knowledge.

Not sure what you mean here - Microsoft are actively working on F# and the .NET Spark and Torch bindings.
I don't think the ML community has an appetite for learning a different language.

There are Microsoft-backed F# bindings for Spark and Torch, but no one seems interested. And this is despite a pretty compelling proposition of lightweight syntax, strong typing, script-ability and great performance.

The answer will probably be JavaScript.

Everyone already knows the language - all that's missing is operator overloading and a few key bindings.

Python's dominance is holding us back. We need a stack with a more principled approach to environments and native dependencies.
Rough news for the LSE, which was already trying to make that play.
Re:Are commercial "third places" a dying breed? on Wednesday May 22, 2024 @08:51AM (#40440318)
Blank Street is eating their lunch
> build a extremely minimal kernel (i.e. ditch Linux entirely) and link your application against necessary bits of code

It would be nice, but this is really hard to do when modern software has so many layers of crud. Good luck getting say, a PyTorch app, to work doing this without some serious time investment.

Re:Are We Modules Yet? on Wednesday May 01, 2024 @02:02PM (#40226896)
You can publish across platforms with modern .NET
Re:Are We Modules Yet? on Wednesday May 01, 2024 @01:33PM (#40226481)
Cross compilation story in C# is very good actually.
Re:Pyinfra: Automate Infrastructure Using Python on Wednesday May 01, 2024 @05:05AM (#40221020)
> Tools like this do the deployment, they aren't generally deployed themselves.

It will have to be executed on many different developer machines (or even your own machine several years in the future) so a simple, reproducible build process, including fetching pip dependencies, is critical.

Re:Pyinfra: Automate Infrastructure Using Python on Tuesday April 30, 2024 @01:40PM (#40213688)
Python seems like a really poor choice for infrastructure.

- Python is not easy to build into portable binaries

- The package ecosystem is very hard to use in a reproducible way

- The language is not truly typed - types add massive value for infrastructure and scripts because they are less likely to be unit-tested

- The lack of a "let" or "var" keyword makes simple programming errors more likely (again, this code is less likely to be unit-tested)

Maybe I'm missing something? I don't know why I would want to introduce Python in this domain.

Older »