Most of those feature bullet points also apply to git, or most other DVCSs. Of the ones that don’t: it doesn’t matter to me how easy it is to install, or how many binaries, because git is already installed. And I have a lovely Git GUI client (Fork).
I imagine there are concrete pluses to Fossil, but this article didn’t list any (that are relevant to me.)
Agreed. While I certainly don’t think git is the last word in version control, it’s so good that it’s probably only going to be surpassed by something that is completely surprising to most of us. I’m expecting it will be as different from git as git was from cvs (I’m not forgetting svn, I just think the difference will have to be that much bigger).
Vale always looks really interesting. I think you should write a book or something to make it easy to adopt. Last time I looked the documentation was terse.
Typst is very exciting - it seems like the first meaningful LaTeX competitor in a long time.
And it seems they’ve just implemented footnotes, which was the main blocker for me using it for schoolwork! I’ll probably give it another shot in September.
Have you considered sile? https://sile-typesetter.org/what-is-sile/
I really like SILE and I wish I could use it for papers, but there are some blockers:
SILE dev here. Some non-exhaustive notes to your three points:
True, the demand from conferences, universities, and journals to use X template exactly is a hard one. Note this also affects
typst just as much as
sile. That being said it is possible to write classes for SILE and for the most part shouldn’t even be too hard to replicate the layout and rules for many documents to come out the same as long as the product they want is a PDF and not the LaTeX or Word sources. I’m personally in the book business and not so much academia, but I’m happy to help package devs if anybody wants to tackle setting up a class to mimic some style guide.
It might be a while since you looked, SILE supports math and bibtex. The math support is less refined than in Typst or LaTeX, but it covers most of MathML. Typst came out with focus on math first, for SILE is was contributed later. On the flip side Typst has very rudimentary support for many other typesetting features like frames, footnotes, RTL and TTB writing directions, hyphenation and special features languages and scripts, etc., while SILE focused on those out of the gate. Your needs may vary and a different solution might be better for different projects.
True, there is a huge depth to the LaTeX ecosystem. There are only a few dozen core SILE packages and another handful of 3rd party ones. That being said almost all the things you mention are doable, and parsing other inputs (such as diagraming) and embedding the output is way easier in SILE than LaTeX. One major difference between SILE and Typst is that Typst strictly limits what 3rd party packages/templates/functions can do, while SILE provides a Lua interface with 100% access to extend or tinker with it’s own internals as well as reach out to the system and run other programs to generate output. SILE also has a package management solution for 3rd party packages that is a bit more robust than Typst’s current allowance of mostly copy/pasting code into your project.
That being said it is possible to write classes for SILE and for the most part shouldn’t even be too hard to replicate the layout and rules for many documents to come out the same as long as the product they want is a PDF and not the LaTeX or Word sources. I’m personally in the book business and not so much academia, but I’m happy to help package devs if anybody wants to tackle setting up a class to mimic some style guide.
I wonder if there’s a volunteer at the ACM who would be interested in at least making their templates work with SILE. Most conferences I care about use either an ACM or IEEE style.
It might be a while since you looked, SILE supports math and bibtex.
It is, I looked in quite a bit of detail after having breakfast with Simon at FOSDEM many years ago, but have only periodically checked for progress. I saw some progress recently on an issue that I filed a few years back about documenting the APIs. Great news. How does BibTeX support work? BibTeX can include arbitrary TeX, which makes it painful, but I tend not to do that because I also want my BibTeX to work with things like Jekyll Scholar, so more limited support is probably fine for me.
There are only a few dozen core SILE packages and another handful of 3rd party ones. That being said almost all the things you mention are doable, and parsing other inputs (such as diagraming) and embedding the output is way easier in SILE than LaTeX
Things like TikZ and pfgplots[data] are useful precisely because I don’t need an external tool. In particular, the main reason that I use TikZ is that the fonts in my diagrams match those in my document. Most of the TeX fonts are also available as OpenType, so you can do this, but then if you decide to reduce the text size by 1pt you have to go and make the matching change in all of the figures. To give another concrete example, I have made very heavy use of a LaTeX package that draws bit patterns in machine words for describing instruction encodings. All of this can be done in SILE (probably in considerably less than half the effort of doing it in TeX and with better performance), but someone else has done it in LaTeX. I really hope that the SILE ecosystem starts to grow this kind of thing.
If there is anybody that wants to give it a shot with me I’d be happy to spin up a class for ACM/IEEE/whatever popular style guide is out there and facilitate the process of getting everything implemented as close a match as possible. If this interests anybody pop open a new issue with a link to the style guide itself and a sample input/output document (in LaTeX/PDF presumably) and I’ll fire up the boilerplate for a new class package and get he ball rolling. Obviously the simpler/more flexible the style guide we start with the better, and the simpler the PoC input we want to start with the better.
Obviously RAW TeX in BibTeX doesn’t work great, although since “turn about is fair play” we can process RAW SIL input (or XML) in BibTeX content, although our ability to process it as RAW Markdown is probably more useful. On other words it can be reasonably adapted for any input format(s), just like SILE itself can take XML, SIL, Markdown, or other input formats.
And yes, your comments about “this is hard in LaTeX but somebody already did it” are pretty much true. I still use LaTeX some myself just because some projects are already all setup to work with it, so the momentum keeps the ball rolling. I hate having to tweak things because the internals are painful, but for the stuff that already works out of the box it’s hard to argue with nice output. I too hope over time the ease of implementing new things in SILE with access to a full fledged language ecosystem (several actually since you can easily write C, C++, Rust, and execute it as a Lua package as well as shim in/shell out Python and others with bindings too) will allow the 3rd party ecosystem for SILE to thrive too.
Is there a good AsciiDoc to SILE flow? I used LaTeX for my prior books but I’m looking at AsciiDoc for the next one, since it lets me embed semantic markup that can flow through to things that I can style with CSS for the ePub version (I wrote my own TeX -> HTML converter for my last couple of books because all of the LaTeX tooling I tried made a mess of it), but I’d love to be able to use SILE for PDF versions.
That isn’t a flow I’ve ever done in production end to end, but there are several paths you could take. AsciiDoc → DocBook via Pandoc would be one, then directly typset using SILE’s DocBook support (XML with a set of style rules for tags basically). Another path would be again using Pandoc to convert to Markdown, then use the
markdown.sile inputter. A third way might be to use CaSILE which bundles a Pandoc fork that includes a SILE writer. The extra versatility in this is it allows you to embed raw SIL commands in your input (works for Markdown, not sure how AsciiDoc would handle this but I think there is a way). Feel free to open a discussion on SILE for either of the former or a feature request issue for CaSILE if they interest you. Any of the above should take just a little bit of fiddling to work out the right commands. If you want both PDF and ePUB output from plain text sources in any format CaSILE is what I would reach for (that’s what I made it for).
I tried AsciiDoc -> DocBook -> SILE workflow recently. My conclusion is:
Realistically if you want to typeset DocBook you probably are going to want to style all the tags yourself. About have of them have default styling and the other are pass-throughs just to get the content to the page, but would need styling for use. The default styling though is almost certainly now what you want for any book project.
Thanks! Does this flow properly preserve custom elements in AsciiDoc through DocBook to places where SILE can pick them up? For example, in my last book I wanted to make sure that the code examples all worked and so each one was in a file that could be compiled and tested and referenced from the LaTeX and so I would want to add some handling in SILE to grab the right lines from the file (identified by delimiters in comments), pares the file with something external, and then feed that as text with particular styling into the SILE pipeline.
I don’t know, but I think this should work, yeah. I think what you are asking belongs to AsciiDoc -> DocBook step (I think it would be on the asciidoctor processor to do read the source code, extract specific lines, and emit DocBook with text already “pre-processed”), and, given that AsciiDoc is essentially a different syntax for DocBook, this step should work perfectly in practice.
In any case, on SILE side you use lua to do whatever (as an aside, after wondering “why typist is a whole programming language” and looking closer at SILE, I realize that this is because typesetting itself is essentially imperative. https://sile-typesetter.org/manual/sile-0.14.9.pdf#page123 Is a good example).
Fun context: historically, I advocated for the use of AsciiDoctor. Since then, I personally switched to Djot (which isn’t yet production ready), and I was looking for a great way to convert Djot to PDF. I looked at “Djot -> DocBook -> SILE” route, and, while I was ready to do the first step from-scratch myself, I don’t have enough domain knowledge to help polish the second step to “just works” stage. So I went “Djot -> HTML -> Chromium -> Print to PDF” route, with its horrible typesetting.
I believe markdown.sile also supports Djot directly as an inputter, that gives you Djot -> SILE. If it isn’t that package Djot support is in another package by the same author.
Thanks for the tip about
markdown.sile! Will try that out once SILE works again for me with nixos (
Package ‘lua5.4-lua-zlib-1.2-2’ is marked as broken, if usng lua5.4, and
Package ‘lua5.3-vstruct-2.1.1-1’ is marked as broken for 5.3 TT)
Even if recent builds of those Lua packages are broken in Nix, you should still be able to run
sile at the last package version of SILE because the dependencies by using locked dependency versions from the time of packaging. I can’t remember the incantation for that inside NixOS but I know there is one. You can also run the Flake version which has it’s own lockfile with dependencies at known working versions. For example
nix run github:sile-typesetter/sile runs the latest flake version, but you can also run any previous version since we introduced the Flake complete with whatever dependencies they had at the time.
Feel free to tag me in Lua package related issues in nixpkgs if they affect SILE.
I wonder if there’s a volunteer at the ACM who would be interested in at least making their templates work with SILE.
I think you would need more than that, since ACM is moving to a publication workflow that ingests article source, not author-submitted PDFs. Not every conference (yet?) requires it, but some big ones do. The end result is that LaTeX or Word are really the only two options. I have met a few people who draft articles primarily in Markdown, and then have a home-rolled converter to ACM-compliant LaTeX. But that only works because they use a small subset of Markdown features that can be one-to-one translated (like sections).
Yes. I caveated my suggestion/offer above noting it will only help at this point for submission systems that just need the final output product, not the source.
This is a culture problem, not just a tech one though. My hope is that eventually the tooling to build/convert is standardized just enough that folks can write in their choice of LaTeX/Typst/SILE and submit the source repository, and the other end could process any of those, say using a standardized CI workflow with options for different typesetters. The workflow and output formats could still be standardized while giving some tooling choices on how to get there.
Wondering if you’d mind answering some semi-tangential questions of mine regarding SILE/TeX/typesetting.
That depends a lot of what you think of as “core” TeX. I’m assuming you don’t understand the actual boundaries of TeX vs. the LaTeX/XeLaTeX/LuaTeX/ConTeXt ecosystems. I assume you are talking about basic typesetting algorithms such as line breaking or leading. This doesn’t match up cleanly at all with what core TeX actually is, but we’ll go with the basic algorithms. These took a lot of thought to get right, but they are quite easy to clone. They have been ported to dozen of languages. SILE itself has almost exact ports of a few factions (including step numbers in source comments from the original). The issue really isn’t implementing any one part, the issue is coming up with a system where they can all get along. Taking a string and wrapping it at a certain length with the line breaker isn’t too hard. In a naive box, that would be the end of things, and that’s where core TeX kind of leaves you to. LaTeX for all it’s huge ecosystem just doesn’t handle some page layouts though. SILE has taken a long time to work out how to make those core bits work as expected when you start chopping the box up into variable size frames that grow when you have sidebar insertions or mix and match with other layout adjustments. It also gets complicated when you start dealing with things outside of English and a few other Latin script based languages. Suddenly some of the core TeX stuff falls apart and you realize you need much more involved interactions between different parts of the chain to get things right. Transpiling TeX is possible, but it still leaves you with all the idiosyncrasies and limitations of TeX. There is a pure Python implementation called
yex for example, but it doesn’t get you much farther (or even as far) as TeX itself.
Ground-up rethinks like Typst (Rust/custom) or XTS (Go) or SILE (Lua/Rust) are important because there is lots more wrong with the fundamental workings of TeX that just the language the typesetter is implemented in. Sure that makes it extra hard to fix these days, but as far as typesetting engines go none of the modern alternatives are really winners because of the language the engine is written in, at the end of the day they mostly stand or fall based on what they can accomplish.
Thanks for the detailed response, that helps clarify my understanding of the state of things. And you’re right, I don’t know jack about the ecosystem. Looking at the Typst’s description of how XeLaTeX is compiled was mind boggling to me.
To explain my questions: I’ve long desired something that acts like TeX but doesn’t look like it. For example, Typst with TeX-style math and - importantly - access to most TeX packages. I don’t use TeX for anything complicated or (that) precise. Like 80% of the documents I write are either simple prose or (often reasonably simple) math. I really would love something that can hide the complexity of the “fiddly bits” of TeX, or at least wrap it in a DSL I can actually interact with. I can see now, though, how my opinion as a user of TeX is naive to someone who knows about how TeX works. I do think that if someone can make “Typst (i.e. markdown-like front end + a way to deal with the fiddly bits that doesn’t make me so, so sad) with backward compatability with the TeX ecosystem” that would be awesome, but I suppose I understand now that this is difficult if not impossible.
SILE might be exactly what you want. Simon started with the original TeX papers and implemented not just the algorithms that TeX uses but also the ones that TeX wanted to use but were infeasible. For example, TeX has a really nice dynamic processing algorithm for line breaking that takes a whole paragraph, assigns badness scores to each possible breaking position, and finds a solution that minimises badness. The paper describing this points out that the same approach could be used for laying out paragraphs in a document but that, for large documents, this would need a megabyte of memory and so is infeasible. SILE implements that version, because it’s now a trivial amount of memory (even with the overhead of using a Lua table rather than a C array) is trivial.
This means that there are some important things that you can express in SILE but not in TeX. For example, most publishers have a rule that a figure must not appear before the first reference to it. TeX can’t express that because it places the figure using a greedy algorithm. SILE can assign a maximum badness value to any possible placement of the figure before it’s first reference and then have it placed nicely.
At the same time, SILE is written in Lua, whereas TeX is a horrible Turing machine that is the reason that I don’t listen to anything Knuth has to say about software engineering (while having nothing but respect for him as an expert on algorithms). This means that humans have a chance of being able to extend SILE.
Have you looked at KeenWrite? it’s my free, open-source, cross-platform, desktop text editor that invokes ConTeXt for typesetting. The editor uses KeenType for its real-time mathematics preview.
See the video tutorials for details.
A few years ago, I realized you can easily solve NYT puzzles just by taking a photo of the blank grid, identifying the grid shape, and looking it up in a database.
For whatever reason, my employer (the world’s largest Brazilian themed bookstore) didn’t think that was a fun party trick to include in their garbage telephone. Oh well.
This seems like a pretty complex way of managing lifetimes and scopes. It’s not obvious to me that this is simpler or more powerful for the programmer than an ownership and lifetime model.
It seems like this was chosen because it was simpler for the compiler implementer.
What I do like is how explicit this all is.
Modes are a lot less powerful than explicit lifetimes, but substantially simpler. It’s a feature that covers common use cases, but cannot express a lot of things that you can express in Rust: modes give you no way to say that a value is “owned by” the data structure it resides in, for example — as a first approximation all you’re saying is that some values are allocated on the stack and some on the heap.
It’s important to remember that OCaml is a garbage collected language, and the garbage collector is still doing all of the heavy lifting for non-local allocations. This feature gives programmers a way to opt out of garbage collection (and the corresponding performance overhead) for values that can be statically proven to be short-lived — it’s not an alternative solution to memory management in OCaml.
This feature gives programmers a way to opt out of garbage collection (and the corresponding performance overhead) for values that can be statically proven to be short-lived
It does seem quite nice for that. Though that makes the Rust comparison feel like a red herring to me, since they are not that similar in overall design. At least from my read, this OCaml feature is a lot more similar in scope and intent to something like Common Lisp’s
dynamic-extent allocations. Though one important difference is that Common Lisp doesn’t require the implementation to verify these annotations statically (the implementation is allowed to assume that the programmer has correctly specified that the value does not escape).
I think the static guarantee is the interesting bit (and the reason that the comparison to Rust makes sense). It’s not just allocating values on the stack, but allocating values on the stack and guaranteeing that references to those values can’t outlive the stack frame. (Speaking loosely here, since the allocation regions aren’t literally the call stack, and exclaves mean you can allocate in other regions, but you get it.)
Yes, all crumbles to ash. Our role in civilization is not to contribute a brick to the great edifice. Culture is a chain reaction that continually renews itself from the old. The old has to be there for the new to come. New technologies can only be created within specific material circumstances, then they displace the circumstances that created them. And maybe a few people found what you made useful for a couple years. Doesn’t mean it was pointless; how many hundred-year-old artifacts do you make use of in everyday life?
Some people in software seems to think they should be building cathedrals, when in fact they’re building the medieval version of a storage shed. It solves an immediate need, it is useful, but is not expected to last for centuries.
Hundred year old furniture and housewares aren’t that expensive. Just have to avoid things that contain lead.
I’ve tagged this a rant, as it does not have any actionable advice, nor analysis of how we got to the “here” that the author decries.
use a hosted Postgres as a database, for fulltext search, html caching, publish/subscribe, and an event store with TimescaleDB.
a radical simple setup […] only uses a hosted Postgres (instead of PG, Redis and Elastic), Unpoly to render HTML on the server in a monolith and BigQuery for an analytical warehouse.
if you need REST/GraphQL for native mobile applications, use Hasura to automatically create REST/GraphQL from a Postgres database.
Fairly actionable advice, but I still think the rant tag is fitting.
Thanks for finding all the actionable advice. Needless to say there are perfectly good reasons not to do all of these things.
This seems kind of dumb. $88,000 is the annual salary of a junior software engineer in the US. If it will take more than 1/4 of the time of a senior engineer to make monitoring work as well as it does now without datadog, that’s probably a net loss. Certainly you’ll pay the opportunity cost of spending engineering resources on redoing all your monitoring.
I’m surprised by your stats of $88k for a junior developer. Do you have a source for that? I can believe that might be the case in California or New York, but it feels off for a national average. Our junior devs make less than half that. Heck, I’m only making a little over half that. My boss’s boss’s boss isn’t making $88k and I’m not entirely sure her boss is making that much.
Don’t get me wrong, I know we’re underpaid, but, out of the last three places I interviewed at, no one was offering more that $60k for senior devs. And one of those was in New York.
I made $65k my first year out of school working a government-ish job at a university research center 20 years ago. $45k for a dev in the US in 2023 is WILDLY underpaid.
Yes, junior devs here in Minnesota (low cost of living area) are routinely getting offers for $100k or so. There’s a ton of data on levels.fyi.
Company seems to pitch itself as cybersecurity. I think cybersecurity might be the next big vc bubble https://www.crunchbase.com/organization/converso-f6e8
There’s a lot of money for security things at the moment, but there’s also a huge amount of snake oil. Anyone selling AI for security is almost certainly snake oil (ML is pretty good at anomaly detection but only in the absence of an adaptive attacker. There have been a bunch of DARPA projects to try this and they’ve all failed red teaming exercises), unless they’re on the offensive side (ML is great for state-space exploration and a system that has a 99% failure rate but that can generate thousands of exploit candidates per second is a huge win).
They’re right in that the incentive structure to perform well.. is missing if you think about it.
The incentive structure to perform well is that you have a job. Enjoy layoffs I guess.
Edit: OP, are you the owner of this blog?
Layoffs are rarely strongly correlated with performance, largely because performance management is hard and layoffs need to hit a large amount of people without too much delay.
I think you missed the point of the article.
The incentive structure to perform well is that you have a job.
No, that is the incentive to be as it says “perfectly mediocre”, not to do better than your peers, to as much as possible not stick out. As anyone who has experienced mass layoffs, they’re pretty close to random in their targeting. It doesn’t matter how much or how little you work if your entire division is axed. It doesn’t matter how amazing or how average you work is if it’s not on something that gets trotted out for demos.
As it says, if you find an issue you can suddenly acquire the work of fixing that issue. You won’t get rewarded for finding the issue, just fixing it will be added to your list of tasks to do. So having reported the issue you now have more work that needs to be done, you aren’t getting paid any more to fix it, and you still have everything else you were already doing. So now when perf review comes around you can be dinged for not fixing the issue you reported.
Thus you have an incentive structure that creates a very rational reason for behaving like this.
I don’t behave like this, and most people don’t, but as the article states that it seems like we’re the irrational ones.
Note that this is the reason companies try so hard to claim “we’re a family” and similar bs.
I discovered this during my last job where I was on “golden handcuffs”. Because nothing I did could meaningfully increase my comp, and my comp had a huge cliff in easy sight, I was strongly incentivized to keep my head down and stay invisible, then leave after the cliff.
It doesn’t matter how amazing or how average you work is if it’s not on something that gets trotted out for demos.
Sometimes even being trotted out for demos won’t save you.
Typically every C*O or EVP level get a x% reduction target and that is what will be done. It does not matter that one org may be full of highly efficient people and the other is not. You as the EVP have to bring your x% by such and such date to make the investors happy.
I disagree. The people that are doing the kinds of things the author wants are the ones that will find it very easy to get a better-paid job elsewhere if they quit or are made redundant. The company is setting up incentives for the useless people to stay.
The author seems to have some cognitive issues that he blames on one bad LSD trip. He might be right, he might not, but it’s definitely not general-case advice. LSD is definitely not for everybody.
passkeys are resistant to online attacks like phishing, making them more secure than things like SMS one-time codes.
Hello this is the google passkey authority, there is a recall of your passkey. Please confirm your mailing address so we can send you a replacement and refund for your postage of your dangerous key to us.
I am. In fairness, I’m p sure that if the user can ever view the key material, a phishing attack can be mounted.
Maybe. But realistically, if they do try to export it there will be tons of warnings from the application letting them know that revealing it to a 3rd party will impact their security.
It’s not impossible by any means but it raises the bar. While an attacker can snarf a username/password with a convincing website and an email, they’re now going to have to impersonate Microsoft security and call people to guide them through the process.
It’s hard for me to believe that using GraphQL, which couples the frontend to the data, mentioned as a solution for decoupling.
No it doesn’t. It decouples the backend from the frontend. The “make me an endpoint for each feature” thing is very real.
What would be a frontend that isn’t coupled to the data it displays?
I should’ve misphrased, I meant the database schema. Of course frontend needs to display data, but it should not know anything about how the data is organized in the persistence layer. But what I know of GQL so far is that: frontend needs to assemble queries in exact awareness of the database schema.
In my opinion, it may decouple the frontend from the backend by skipping it, and couples directly to the schema instead, which I can’t see as an optimal architectural decision (maybe I’m oldschool :).
No the graphql schema is completely independent of the storage layout. This is largely the point of it. There are some people who are using magical make-an-api-from-my-database tools, and this coupling concern seems to be a common complaint. But it’s a problem with how you’re using the tool (you want a schema of views) and not with graphql.
Thanks for shining light to it! I had a suspicion that I saw the wrong examples (and, you may guessed, I haven’t used it in production yet). But you comment is clarifying, I’ll try to get my head around this new (to me) idea.
Isomorf was another similar thing.
Except that scrapscript is a scripting language for a decentralized social network, and has authentication and a payment system. (See link in my other post.)
When I read some of the Unison docs, I got the strong impression that names don’t matter, entities (types, values) are identified solely by their hash, and their name is not part of their identity.
In scrapscript, names do matter, it doesn’t have these Unison naming semantics. A scrap can have a name that is consistent across multiple versions of the scrap, which allows you to upgrade code to the latest version. I don’t know how this works in Unison.
The social network, authentication, and payment systems are the “killer apps” that I want to build with the language, but aren’t part of the core architecture :)
I’m not super familiar with unison either, but your description of scrapscript was spot on :) thanks!
IIUC, in Unison, names “matter” but are aliases to those content hashes.
Unless you were talking about structural / unique types. For structural types, the names don’t really matter, but they do for unique types.
Site: https://bluevoyant.applytojob.com/ and BlueVoyant.com
Positions: loads, in engineering we’re looking for senior front end web (“full stack”), back end, data engineering, analytics, cloud infrastructure engineer (all clouds, azure especially needed) and a test lead. We also have a bunch of sales and customer success positions.
Location: full remote, US, Canada, Israel, EU, UK are generally unproblematic. US persons in the US will have an advantage for some roles/may be a job requirement. Offices in NYC and College Park MD you could attend. Also offices in Tel Aviv, London, and Madrid.
Description: we get data about the Internet, and data about companies, then other large companies pay us to get in touch with those first companies and tell them what security vulnerabilities we can observe from the outside. We also have a Managed Detection and Response (mdr) business.
Tech stack: Lots of stuff, Postgres, bigquery, Python, elasticsearch, vue.js, kubernetes, google cloud, splunk for our mdr business.
Contact: dm me. If you apply directly, still dm me so I can flag you as a referral :)
Update: I’ve got perplexity backwards, Python is apparently the easiest to predict and php the hardest.
I’m pretty sure this is correlated with entropy: how likely is the window of text just examined/generated to precisely determine the next token?
What’s interesting is that most languages are very close, with C and PHP presumably having the fewest sequels on a given window of input, and Python then having the most.
I wonder to what extent this is an artifact of the problem domains in which code is deployed, or its inherent repetitiousness.
In any case, ease of generation is probably neither a good thing nor a bad thing. We’re going to get to the next level as llms can start to evaluate their own candidate output and refine it. Properties that make that easy will be important. I’m guessing that syntactic uniformity will either help or hinder a lot, and that compulsory type (and other) annotations to enforce consistency will help. Also structured representations of error messages that precisely identify the nature of the problem and inconsistency.
In many ways this seems like a number of established but not widespread ideas (capabilities, wrapper types that adapt the capability mode) wrapped in slightly obscure language.
I hope this works, and gets copied in other places. I like that this is all very explicit. I hope the final version is able to thread the needle of both explicit but not cumbersome.
I say all of this as someone who doesn’t write ocaml (or really any ML).
I remember when I looked at doing something similar 10 years ago or so, that with MsSQL, you needed to be careful about message volume due to hot pages used by table storage. If I recall correctly, you could end up with a lot of used space in the tempdb, or page fragmentation perhaps.
I wonder if this is a concern for postgres?
Almost certainly. At a certain scale you’re likely to need something that can shard over multiple machines (kafka or its more modern successors)
The tasks seem to be mostly numerically oriented, as opposed to text or io oriented.
That said, based on this Julia does appear to be the fastest garbage collected language, and significantly bear Python in the numerical domain.
Does anyone have experience using Julia for general purpose programming? Is it pleasant or not?
Edit: found this https://danluu.com/julialang/
I don’t get it. Dataclasses are already compact. This seems like new syntax for the sake of adding new syntax.
Dataclasses have a lot of issues, including requiring type annotations, too many features, poor performance, etc. People want to have basic data types that are easy to define and simple to use without all the overhead of OOP. Also, immutable types like this could enable better sharing between sub-interpreters for performance.
I couldn’t really see the difference with a NamedTuple subclasses, which behave pretty much like structs, the only caveat being reserved attribute names like ‘index’.
Namedtuple allows positional access, which is an error-prone interface that should be avoided. Namedtuples are really only there to help you migrate existing tuple code over to objects with attributes.
With the “I haven’t done Python in a while” caveat, I wonder — why not make a new namedtuple-like that doesn’t allow indexing? The Author’s reference implementation could easily be the template here, no?
Maybe the underlying question is “why can’t it just be a new collection class? why is built-in language support and a new
structkeyword needed?” I think it’s this part:
immutablein userspace today as far as I understand it. Some values like
tupleare actually immutable, and there are proposals for others, but not for objects. You can simulate immutability like dataclasses already do but it’s not truly frozen. SimpleNamespace is fully mutable. So that’s part of the gap to fill.
So the right thing to do is to make it possible to have immutable class fields, not create a literally new structure/syntax in the language… maybe?
All of the object and class machinery is very expensive, though. So the goal is to avoid that because of performance. Makes sense to me.
It seems like Mojo is sort of working in that same direction.
If the goal is performance, aren’t you in the wrong language? At some point either the dynamic features of the language are worth having, or they need to be shed (yes, pun). But what I see happening (from a far) is that the language keeps growing and growing in language surface area instead of fixing/creating better baseline abstractions. We’re just minutes away from Python being the next “kitchen sink” language… it seems. Far from the language I loved using in the 00s and early 10s.
I agree it no longer “fits in your head”.
This could be a package for structs, does not seem to be needed in the language definition itself. But its good to discuss it.
But why is it good to discuss it? What does this offer that dataclasses don’t? Honest question here, because I’m not seeing it, but I could be missing something.
One problem with
@dataclassbeing an annotation is that it will either create a new class or modify an existing class based on
slots=True, and creating a new class is an odd behavior as well. Syntax could unify this to a degree and simplify it too.
Additionally, people won’t choose
@dataclassas often. It’s one of those things that is less likely to be reached for because people prefer native features.
That’s about it though. Personally, I don’t really think a native version is a big win tbh