Unrelated to the project itself, but is the practice of putting each character of the page in its own span a technique for foiling AIs trying to crawl that content?
Spamhaus.org lists the .work domain as one of the worst TLDs (more than half of the websites with this domain are malware). I am not removing that exception in my DNS server, sorry. Do you have an alternate domain?
FWIW, I’ve tried to calculate 30 mpg to L/100km in both numbat and Rink, and neither can do it immediately.
They both suggest inversion (numbat suggests inverting the right side, which is “wrong” if the unit on the right side is what you want), and then rink produces the correct value, while numbat ignores the 100 part:
Rink:
30 mpg to L/100km
Conformance error: approx. 12754311.2 / meter^2 (fuel_efficiency) != 10000 micrometer^2 (area)
Reciprocal conversion, invert one side
(1 / 30 mpg) to L/100km
7.840486[1]... liter / 100 kilometer (area)
numbat:
>>> 30 mpg to L/100km
error: while type checking
┌─ <input:2>:1:1
│
1 │ 30 mpg to L/100km
│ ^^^^^^ -- ^^^^^^^ Area
│ │ │
│ │ incompatible dimensions in unit conversion
│ Length⁻²
│
= left hand side: Length⁻²
right hand side: Length² [= Area]
Suggested fix: invert the expression on the right hand side
>>> (1 / 30mpg) to L/100km
1 / 30 mpg ➞ litre / 100 kilometre
= 0.0784049 l/km [Area]
P.S. I didn’t find how to specify UK gallons instead of US gallons in neither.
Oh, I hope they change that. The Rink unit conversion is pretty well specified, where x -> y computes x / y and then displays the result with y (unmodified) as the units. I think it’s surprising and less useful that numbat ignores the constants in y, but I could be missing something.
Oh, cool! I’ve been doing these sorts of calculations as part of worldbuilding for an sf story set on a one-mile-diameter planetoid with a tiny black hole inside for gravity; this would’ve made them a lot quicker.
I only realized that a few weeks ago while actively looking for its implementation for some reason I’ve now forgotten. I might have been looking for this very units file and gotten into that periodic feeling of, “Well, I wonder if I could rewrite this in X.”
I played with Glamorous Toolkit (https://gtoolkit.com/) earlier I really liked the infinite horizontal scroll feature (aka “Miller column”) that is central to its workflow (it might be inherited from Pharo, not 100% sure). Since then I thought that a WM built upon that would be quite nice, so I’m really glad this exists! Unfortunately I use a Mac now, but this is a compelling reason to get back to desktop Linux…
Yes, I use PaperWM on my work Linux machine and Niri on my personal one. They are very similar indeed.
If there is anything like it for MacOS, I’d like to try that on my work mac.
Unfortunately I use a Mac now, but this is a compelling reason to get back to desktop Linux…
Same here. I’m a pretty dedicated user of yabai, but a lot of things have made me sour on it more recently (e.g. Ghostty’s use of native tabs interacts poorly with yabai, and there are many times I find it obstructs me more than helps). I cannot live without spatial window management, however. Before Yabai my workflow was a bunch of full screen windows that I would use macOS spaces to swipe between. Niri/PaperWM sound like what I’ve always been looking for, I might have to make my PC dual boot and kick the tires to try it out.
Gleam, specifically with Lustre makes me excited about frontend in a way that I haven’t been before. I missed out on Elm when it was at its peak, and Gleam’s focus on good tooling is really encouraging for its future :)
Also, it seems like you’ve a word in this paragraph:
If you place your cursor on the type header and select the code action in your, then it’ll be updated to this:
but then they would need to be feeding those snippets in almost real time into a system which forwards them onto advertising partners who then feed that information into targeting networks such that next time you view an ad on your phone the information is available to help select the relevant ad.
Go has a more … monastic? … approach to system library dependencies, and for Linux targets it is trivially easy to build Go binaries without libc dependencies by setting CGO_ENABLED=0.
The advantage of the Go approach is that it makes cross-compilation work from anything to anything. I’ve only played with Crystal a little bit so this might be a problem more experienced users don’t hit, but if I try to cross-compile even a basic “Hello world” on my macOS laptop to a Linux target then the output is a huuuge error message:
% crystal build hello.cr --target x86_64-linux-musl
sh: pkg-config: command not found
ld: multiple errors: unknown file type in '/Users/john/.cache/crystal/Users-john-temp-crystal-hello-hello.cr/P-ointer40U-I-nt841.o0.o'; unknown
[...]
unknown file type in '/Users/john/.cache/crystal/Users-john-temp-crystal-hello-hello.cr/F-loat32.o0.o'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Error: execution of command failed with exit status 1: cc "${@}" -o /Users/john/temp/crystal-hello/hello -rdynamic -L/Users/john/.opt/crystal-1.13.3-1/embedded/lib -lpcre2-8 -lgc -levent
And what’s wrong with it? It allows you to specify that a portion of the (or the whole) document is in a different language. It’s very useful information. I don’t see any downsides to it, and the information it encodes is meaningful.
It’s important for documents that contain multiple languages, because without lang= there’s no way to determine which font and/or text-to-speech voice to use.
Fonts are important for eastern Asian contexts (e.g. Chinese and Japanese use different fonts for the same Unicode code points), and text-to-speech for pretty much anything (ever hear a French TTS try to pronounce English? It’s hilarious, but also incomprehensible).
Why do we have to figure out text-to-speech voice? There’s two options here:
The user speaks the language. In that case, the text to speech voice can easily determine which of the ~4 languages that the person speaks the language is in. Because it’s trivial to determine what language text is in, or, alternatively, it isn’t in a language (it’s just a person’s name, or is ambiguous, in which case a sighted reader also can’t determine the language, and it also likely doesn’t matter)
The person doesn’t speak the language. In that case, it doesn’t matter what voice reads it, because it is meaningless text, just as it is for a sighted reader.
It’s difficult to imagine someone being so stubbornly obtuse by accident, so I’m starting to agree with other commenters that you’re not participating in good faith.
Because it’s trivial to determine what language text is in,
Does your hypothetical language detection consider 「北京」and 「東京」 to be the same language? If so, which?
alternatively, it isn’t in a language (it’s just a person’s name, or is ambiguous, in which case a sighted reader also can’t determine the language, and it also likely doesn’t matter)
You may be surprised at how many people care about having their name pronounced correctly.
The person doesn’t speak the language. In that case, it doesn’t matter what voice reads it, because it is meaningless text,
I can’t read (or speak) Polish, so when I visited Warsaw recently it was useful to have my phone be able to pronounce Polish words embedded in an English-language webpage (e.g. Wikipedia).
The questions you’re asking can be avoided with a quick google search about the lang attribute. Because your opinions are so forcefully asserted yet so easily disputed, I think your comments come across as rude and ignorant (not of technology but of other languages and cultures as well), and IMO reflect badly on this community.
Right, but so what? I don’t know what language that is in. Why does my screen reader have to? Why does a screen-reader user need more information than a non screen-reader user? If the rest of the page is in Afrikaans, the screen reader can use the Afrikaans voice to read that line. If the rest of the page is in English, it can use the english voice. If the page contains no other text, then the text is in BOTH languages, and it can use whichever the user prefers, because the text means the same thing in either, and the user likely prefers one language over the other. There’s no need to disambiguate here, as evidenced by the fact that in a book, this is not disambiguated, and sighted readers have never, ever had a problem reading it.
It’s important for screen-readers which are often used by people with vision deficiencies. (Braille terminals are expensive, and some people are not visually impaired enough to have learned Braille)
The screen reader can use the lang= attribute to determine which pronunciation and which accent to use when transforming the text into sounds. “Schadenfreude” has a totally different pronunciation in German and in English where it was borrowed. And most likely, native speaker of both languages would be unable to understand the other pronunciation. So you cannot imagine how difficult it would be for a German person to understand if the text-to-speech software started to read German text as if it was English.
In addition to coding, I also use chatGPT as a first-level PR reviewer, and found it so good. It points out scopes for optimization, and also test cases that most devs usually overlook.
This is the prompt I use:
Please take a deep breath and return an optimized, performant, and refactored version of the following Python code.
Make sure it also follows Python style guide standards, including linting standards of black and flake8.
Check and fix any prospective bugs or edge cases that might be overlooked.
Please also remove any unused imports and unused variables, and make sure the code is clean.
Sounds like you could use a linter to fix small things like unused imports and variables, e.g. ruff with the “ALL” rule enabled will identify hundreds of areas of improvement in any Python codebase, the problem then is selecting a few rules to turn off.
Yeah. We already use a pre-commit config with the appropriate linters. This is one of the prompt instructions I wrote quite some time ago, but didn’t update.
Thanks for the recommendation. Will check out ruff. We use uv from the creators of ruff in our builds, and its awesome.
This highlights the main strength of Roc, which is also its main weakness. For those who don’t know, in short, Roc does not support side effects, only purely functional code. Meaning that if you want to do any kind of IO, you need to define the data flows in and out of your application in a thing called platform, which can be written in other languages, typically Rust.
I think the idea is rock solid (pun intended) but heavily relies on a dependable set of platforms to exist. You only write the part of your application that is specific to you. Say a web application that writes to the database, as an example. You would not write the server lifecycle,
the concurrency model or the database connection, these would be provided by the platform, you would only write what is specific to your case.
PHP (always going back to this legendary stack) did this tonan extent. It presented the user with a language to massage the request and build the answer.bthr rest wasn’t the programmer’s concern. They even included MySQL clients in the core library, kind of resembling what Roc is doing with platforms. Albeit ghetto style instead of formalized.
It is going to be interesting to see if the idea takes off. IMO, Roc needs at least one of two things:
Batteries included. A solid and extensive set of platforms that would solve most people’s problems.
A killer feature. Think Ruby on Rails, q platform so useful and direct which popularity is capable of driving the language adoption.
To me the platform approach is probably the best feature of Roc (and the most novel one), as it makes the language a powerful shell that you can wrap around a domain-specific high-performance core. These core parts are typically relatively small (if you model properly) and because Roc is pure, isolate the parts that can go wrong. I also agree on Roc needing a batteries-included stdlib, although I’m not sure how that would play with the platform approach. Maybe taking inspiration from Deno or Go there?
Roc’s stdlib purposefully only contains a few data structures like List, Set and Dict (see the docs for a full list), and is specifically avoiding a batteries-included stdlib. The hope is that platforms will provide the relevant batteries-included functionality for their domain.
Yes, but I don’t think it’s enough. For instance, crypto primitives, numerical processing (fixnum), and to some extent, text processing would likely be needed by all/most platforms, if not part of the stdlib. In this case unless there is a way to compose platforms, this will lead to a very fragmented ecosystem (see Scheme).
Relatively small? Sorry, but they are the critical part. The platform approach pretty much imposes that as a Roc developer, you are limited to classes of problems that have already been though of.
It’s now so much stdlib, that is arguably easy. It’s the set of available platforms. Think about it, the language doesn’t have IO it not for platforms. Whatever your application interacts with, need needs to be already supported by a platform.
I agree the core is the critical part, but in my experience once you got that core locked in, most of the code in the application becomes logic (conditions and events) and glue (protocols and data transforms). Defining a compact set of core primitives and operations makes the platform more manageable, and following Alan Kay’s simplicity principle, lead to better programs.
you are limited to classes of problems that have already been though of.
How does being restricted to the I/O primitives offered by a platform restrict you to “problems that have already been thought of” any more than being restricted to the set of syscalls your OS can do, or the set of instructions your CPU can do?
For one, those are more arbitrary.
But the difference is that you are not limited to a set? Programming languages give you access to IO and hardware. They don’t limit it.
I enjoyed this episode, as always, but did find it funny that most of the episode seems to be Richard Feldman talking about the Roc package repository when it’s is supposed to be about Gleam 1.0!
I think that for returning guests especially, the format is much less an interview and more listening in on a conversation. If people are interested in more Gleam chat then the first episode with Louis [1] is also good.
I wish there was a web UI to show summaries of what happened on HEAD branches of watched GitHub repositories but scoped at different levels: commit, PR, release. For instance, if I work on Kubernetes related project I wish it was easy for me to track PRs merged to kubernetes/kubernetes/master. But in a repository of a vim plugin I’m interested in singular commits. An RSS feed would be nice to have. It could be interesting to have some sort of AI generated summary of what happened.
People around here who are less familiar with Coq may not appreciate that this is a software system that has been around for decades (it started in the eighties), is very well-known within a relatively large academic subcommunity, has tons of material around that mention it by name, dozens of command-line tools starting with coq*, etc. This is a massive change that will require a massive amount of work, and I find it very impressive that they were able to decide to change the name at all.
The second aspect of this (that it is a large change) is that it took a ton of discussion within the community, it required overwhelming consensus to do this, dozens of alternate names were proposed/suggested, there was a long debate, etc. Most of the reactions in the discussions here have already been heard and discussed, the reasons for why renaming is better than not were exposed very clearly, etc. (The conflict with the Roc programming language is also already known, and the Coq people got in touch with the Roc people to check that they were okay with the change.)
huh. the roc conflict is definitely what I first thought of. even if richard doesn’t care, it still kind of bugs me. this will have long term repercussions on the searchability of both of them, and could make people who don’t care to learn the difference think they have some relation.
I don’t know the details, I saw a presentation at the last Coq workshop where Mathieu Sozeau mentioned that they got in touch with the people working on Roc, and checked that they were okay with the name change. The two projects are in very different parts of the language space, so they thought it would be okay.
Roc isn’t even at a numbered version yet (i.e. it’s pre v0.0.1), so it’s still in the experimentation phase. The biggest area of interest at the moment seems to be backend web development, but there’s also discussion around gamedev and scientific computing uses.
EDIT: I know you want to push your own editor for ROC, but are there any plans to provide a TreeSitter grammar and an LSP, so we can use Helix/Nvim/Emacs/… ?
Short answer is that the editor project has been deprioritized a lot (e.g. I don’t expect any work to be done on it in 2024) because we realized there’s a way to build the editor plugin ecosystem we want to build in a way that works across multiple editors!
An initial tree-sitter grammar was created a few days ago, and there is a slightly flakey language server that integrates with one of the VSCode extensions. I think plans for the Roc editor have changed, but I haven’t kept up with what the new plan is.
Elm 0.19 nuked any good thoughts I had towards the language. Limiting native modules to a small group of people was a bad design decision, and the lack of leadership has imo doomed the language. elm-janitor is a project that exists to cleanup the mess, and they link a useful but sad spreadsheet of all the fixes that have yet to be merged.
If I were to stick to a functional language today, I would bet on Roc succeeding where Elm couldn’t.
I think ReScript has pretty much taken that niche already. It did what Elm didn’t–provide a pragmatic, interoperable integration with the rest of the JS ecosystem while also providing type safety and fast compiles.
mm this does look like a proper replacement, whereas my Roc evangelism is probably premature. my first question would be how it differs from reason ml which also fills the functional-web niche
ReScript is a continuation of the ReasonML functional-web effort. It split off from the ‘ReasonML’ branding to create a more integrated, turnkey experience for typed functional web dev.
This may sound nit-picky or unreasonable, but the immediate blocker for me adopting ReScript is its take on Option/undefined/null.
I actually do use undefined and null to mean semantically different things in my JavaScipt/TypeScript code. For example, if I’m sending a POST request to my backend API, it will treat a missing field (undefined) as unset and needing the default value (if it is intended to be optional), and it will treat a present null to mean that the client is explicitly denoting “emptiness” for the value and it will NOT be overwritten with a default value.
Likewise, in languages with a generic Option type (Swift, Rust, Kotlin-when-I-write-it), I do sometimes represent the above semantics similarly by having an Option<Option<T>> (or Option<T?> in Kotlin) for an “optional nullable” value.
I realize that ReScript has escape hatches for these things, but I feel like “escape hatches” are for uncommon situations; I don’t want to have these “escape hatches” all over my code and have to fight against the grain of the language.
As much as I loathe TypeScript, I feel like I’m stuck with it.
Right, I know. It’s just that the standard library functions all use option<'a>, so I worry about needing to do a bunch of fiddling between three kinds of “maybe present” types instead of the usual two. Maybe in practice it isn’t bad, but I’ve dug myself into plenty of holes before while trying to go against the grain of the language I was using.
I don’t see any big problems, you just define your form fields with strong types like myField: option<string> and convert the weaker-typed values received over the network into strongly-typed internal values with checks and converter functions. It’s conceptually very similar to TypeScript except it doesn’t suffer from the ‘wrapping’ problem because the option type has special compiler support.
Unrelated to the project itself, but is the practice of putting each character of the page in its own span a technique for foiling AIs trying to crawl that content?
Oh so that’s why reader mode doesn’t work even when I force-enable it…
I guess it’s to help keep all the letters in a regular grid to get that terminal look.
It confuses my screen reader.
Oh, I was wondering why there were spaces right of the text on all lines, this is even worse
Spamhaus.org lists the
.workdomain as one of the worst TLDs (more than half of the websites with this domain are malware). I am not removing that exception in my DNS server, sorry. Do you have an alternate domain?I was unaware, yikes! It’s been posted below but here’s a direct link to the app store listing: https://apps.apple.com/us/app/crustacean-for-lobsters/id6742195107, in addition I’ve also added it to the repo’s readme file on GitHub.
Thank you kindly!
Here’s a link to the Apple app store: https://apps.apple.com/us/app/crustacean-for-lobsters/id6742195107
Would be interested to see a comparison of this, Frink and Rink. If one doesn’t exist I’ll try them all and write it up somewhere.
FWIW, I’ve tried to calculate
30 mpg to L/100kmin both numbat and Rink, and neither can do it immediately.They both suggest inversion (numbat suggests inverting the right side, which is “wrong” if the unit on the right side is what you want), and then rink produces the correct value, while numbat ignores the
100part:Rink:
numbat:
P.S. I didn’t find how to specify UK gallons instead of US gallons in neither.
Wolfram Alpha does even worse:
https://www.wolframalpha.com/input?i=30+mpg+to+L%2F100km
Oh, I hope they change that. The Rink unit conversion is pretty well specified, where
x -> ycomputesx / yand then displays the result withy(unmodified) as the units. I think it’s surprising and less useful that numbat ignores the constants iny, but I could be missing something.Yes, we plan to change that. See https://github.com/sharkdp/numbat/issues/305
Nice, thanks for the link! I think numbat will fully replace rink for me.
We have a comparison with other tools in our documentation (https://numbat.dev/doc/comparison.html), but it does not include “Rink” at the moment.
I would love to see that - I’ve used Rink regularly for years and my first question was how numbat differs from Rink.
Frink’s units file is great; it’s a pity the language is closed source.
There’s an open source project inspired by Frink called Rink.
Oh, cool! I’ve been doing these sorts of calculations as part of worldbuilding for an sf story set on a one-mile-diameter planetoid with a tiny black hole inside for gravity; this would’ve made them a lot quicker.
I only realized that a few weeks ago while actively looking for its implementation for some reason I’ve now forgotten. I might have been looking for this very units file and gotten into that periodic feeling of, “Well, I wonder if I could rewrite this in X.”
I played with Glamorous Toolkit (https://gtoolkit.com/) earlier I really liked the infinite horizontal scroll feature (aka “Miller column”) that is central to its workflow (it might be inherited from Pharo, not 100% sure). Since then I thought that a WM built upon that would be quite nice, so I’m really glad this exists! Unfortunately I use a Mac now, but this is a compelling reason to get back to desktop Linux…
PaperWM, a GNOME Shell plugin, behaves similarly to that I believe.
Yes, I use PaperWM on my work Linux machine and Niri on my personal one. They are very similar indeed. If there is anything like it for MacOS, I’d like to try that on my work mac.
The niri readme mentions PaperWM.spoon as a MacOS implementation of a scrolling window manager, although I haven’t tried it
Same here. I’m a pretty dedicated user of yabai, but a lot of things have made me sour on it more recently (e.g. Ghostty’s use of native tabs interacts poorly with yabai, and there are many times I find it obstructs me more than helps). I cannot live without spatial window management, however. Before Yabai my workflow was a bunch of full screen windows that I would use macOS spaces to swipe between. Niri/PaperWM sound like what I’ve always been looking for, I might have to make my PC dual boot and kick the tires to try it out.
Gleam, specifically with Lustre makes me excited about frontend in a way that I haven’t been before. I missed out on Elm when it was at its peak, and Gleam’s focus on good tooling is really encouraging for its future :)
Also, it seems like you’ve a word in this paragraph:
sound exactly like what this company is doing? https://news.itsfoss.com/ad-company-listening-to-microphone/
As harlanhaskins said in another thread, that company just proposed the idea in a pitch deck, they didn’t actually do anything.
As a Rubyist, Crystal is very delightful. I wish it generated binaries like Go. Amazing project, nonetheless.
What are the differences between Crystal and Go’s binaries?
Crystal links with the system libraries, including libc, so building a self-contained static binary requires a specially-configured environment: https://crystal-lang.org/reference/1.13/guides/static_linking.html
Go has a more … monastic? … approach to system library dependencies, and for Linux targets it is trivially easy to build Go binaries without libc dependencies by setting
CGO_ENABLED=0.The advantage of the Go approach is that it makes cross-compilation work from anything to anything. I’ve only played with Crystal a little bit so this might be a problem more experienced users don’t hit, but if I try to cross-compile even a basic “Hello world” on my macOS laptop to a Linux target then the output is a huuuge error message:
FWIW lots of ecosystems have been using
zig ccto ease cross-compilation woes. I would assume it would work for crystal as well.The lang tag is the most uselessly dumb thing in all of HTML.
There isn’t a tag
<lang>but it is a global attribute for all HTML elements. Is that what you meant?And what’s wrong with it? It allows you to specify that a portion of the (or the whole) document is in a different language. It’s very useful information. I don’t see any downsides to it, and the information it encodes is meaningful.
It’s also actually used such as the user agent loading breakpoints for hyphens, etc.
To whom is that information meaningful? It’s trivial to determine computationally, and no humans care.
It’s not only not trivial, but sometimes not possible to determine computationally.
It’s important for documents that contain multiple languages, because without
lang=there’s no way to determine which font and/or text-to-speech voice to use.Fonts are important for eastern Asian contexts (e.g. Chinese and Japanese use different fonts for the same Unicode code points), and text-to-speech for pretty much anything (ever hear a French TTS try to pronounce English? It’s hilarious, but also incomprehensible).
Why do we have to figure out text-to-speech voice? There’s two options here:
The user speaks the language. In that case, the text to speech voice can easily determine which of the ~4 languages that the person speaks the language is in. Because it’s trivial to determine what language text is in, or, alternatively, it isn’t in a language (it’s just a person’s name, or is ambiguous, in which case a sighted reader also can’t determine the language, and it also likely doesn’t matter)
The person doesn’t speak the language. In that case, it doesn’t matter what voice reads it, because it is meaningless text, just as it is for a sighted reader.
It’s difficult to imagine someone being so stubbornly obtuse by accident, so I’m starting to agree with other commenters that you’re not participating in good faith.
Does your hypothetical language detection consider 「北京」and 「東京」 to be the same language? If so, which?
You may be surprised at how many people care about having their name pronounced correctly.
I can’t read (or speak) Polish, so when I visited Warsaw recently it was useful to have my phone be able to pronounce Polish words embedded in an English-language webpage (e.g. Wikipedia).
The questions you’re asking can be avoided with a quick google search about the
langattribute. Because your opinions are so forcefully asserted yet so easily disputed, I think your comments come across as rude and ignorant (not of technology but of other languages and cultures as well), and IMO reflect badly on this community.Which language are these sentences in? “My hand is in warm water. My pen is in my hand.” If you said English then you’re wrong, they’re in Afrikaans.
Right, but so what? I don’t know what language that is in. Why does my screen reader have to? Why does a screen-reader user need more information than a non screen-reader user? If the rest of the page is in Afrikaans, the screen reader can use the Afrikaans voice to read that line. If the rest of the page is in English, it can use the english voice. If the page contains no other text, then the text is in BOTH languages, and it can use whichever the user prefers, because the text means the same thing in either, and the user likely prefers one language over the other. There’s no need to disambiguate here, as evidenced by the fact that in a book, this is not disambiguated, and sighted readers have never, ever had a problem reading it.
It’s important for screen-readers which are often used by people with vision deficiencies. (Braille terminals are expensive, and some people are not visually impaired enough to have learned Braille)
The screen reader can use the
lang=attribute to determine which pronunciation and which accent to use when transforming the text into sounds. “Schadenfreude” has a totally different pronunciation in German and in English where it was borrowed. And most likely, native speaker of both languages would be unable to understand the other pronunciation. So you cannot imagine how difficult it would be for a German person to understand if the text-to-speech software started to read German text as if it was English.In addition to coding, I also use chatGPT as a first-level PR reviewer, and found it so good. It points out scopes for optimization, and also test cases that most devs usually overlook.
This is the prompt I use:
Not super advanced, but does the job for me.
Sounds like you could use a linter to fix small things like unused imports and variables, e.g. ruff with the “ALL” rule enabled will identify hundreds of areas of improvement in any Python codebase, the problem then is selecting a few rules to turn off.
Yeah. We already use a pre-commit config with the appropriate linters. This is one of the prompt instructions I wrote quite some time ago, but didn’t update.
Thanks for the recommendation. Will check out ruff. We use
uvfrom the creators of ruff in our builds, and its awesome.This highlights the main strength of Roc, which is also its main weakness. For those who don’t know, in short, Roc does not support side effects, only purely functional code. Meaning that if you want to do any kind of IO, you need to define the data flows in and out of your application in a thing called platform, which can be written in other languages, typically Rust.
I think the idea is rock solid (pun intended) but heavily relies on a dependable set of platforms to exist. You only write the part of your application that is specific to you. Say a web application that writes to the database, as an example. You would not write the server lifecycle, the concurrency model or the database connection, these would be provided by the platform, you would only write what is specific to your case. PHP (always going back to this legendary stack) did this tonan extent. It presented the user with a language to massage the request and build the answer.bthr rest wasn’t the programmer’s concern. They even included MySQL clients in the core library, kind of resembling what Roc is doing with platforms. Albeit ghetto style instead of formalized.
It is going to be interesting to see if the idea takes off. IMO, Roc needs at least one of two things:
To me the platform approach is probably the best feature of Roc (and the most novel one), as it makes the language a powerful shell that you can wrap around a domain-specific high-performance core. These core parts are typically relatively small (if you model properly) and because Roc is pure, isolate the parts that can go wrong. I also agree on Roc needing a batteries-included stdlib, although I’m not sure how that would play with the platform approach. Maybe taking inspiration from Deno or Go there?
Roc’s stdlib purposefully only contains a few data structures like
List,SetandDict(see the docs for a full list), and is specifically avoiding a batteries-included stdlib. The hope is that platforms will provide the relevant batteries-included functionality for their domain.Yes, but I don’t think it’s enough. For instance, crypto primitives, numerical processing (fixnum), and to some extent, text processing would likely be needed by all/most platforms, if not part of the stdlib. In this case unless there is a way to compose platforms, this will lead to a very fragmented ecosystem (see Scheme).
Relatively small? Sorry, but they are the critical part. The platform approach pretty much imposes that as a Roc developer, you are limited to classes of problems that have already been though of.
It’s now so much stdlib, that is arguably easy. It’s the set of available platforms. Think about it, the language doesn’t have IO it not for platforms. Whatever your application interacts with, need needs to be already supported by a platform.
I agree the core is the critical part, but in my experience once you got that core locked in, most of the code in the application becomes logic (conditions and events) and glue (protocols and data transforms). Defining a compact set of core primitives and operations makes the platform more manageable, and following Alan Kay’s simplicity principle, lead to better programs.
How does being restricted to the I/O primitives offered by a platform restrict you to “problems that have already been thought of” any more than being restricted to the set of syscalls your OS can do, or the set of instructions your CPU can do?
For one, those are more arbitrary. But the difference is that you are not limited to a set? Programming languages give you access to IO and hardware. They don’t limit it.
Roc looks interesting! Does it have any of my favorite feature from Elixir, pattern-matching with destructuring?
It does! There’s some examples of destructing in the Roc tutorial. :)
I enjoyed this episode, as always, but did find it funny that most of the episode seems to be Richard Feldman talking about the Roc package repository when it’s is supposed to be about Gleam 1.0!
I think that for returning guests especially, the format is much less an interview and more listening in on a conversation. If people are interested in more Gleam chat then the first episode with Louis [1] is also good.
[1] https://pod.link/1602572955/episode/46daa7d4cdeb3bb2900062f7c397bb59
I wish there was a web UI to show summaries of what happened on HEAD branches of watched GitHub repositories but scoped at different levels: commit, PR, release. For instance, if I work on Kubernetes related project I wish it was easy for me to track PRs merged to kubernetes/kubernetes/master. But in a repository of a vim plugin I’m interested in singular commits. An RSS feed would be nice to have. It could be interesting to have some sort of AI generated summary of what happened.
Something along these lines that I’m aware of is willow, but it’s only designed for tracking releases at the moment.
People around here who are less familiar with Coq may not appreciate that this is a software system that has been around for decades (it started in the eighties), is very well-known within a relatively large academic subcommunity, has tons of material around that mention it by name, dozens of command-line tools starting with
coq*, etc. This is a massive change that will require a massive amount of work, and I find it very impressive that they were able to decide to change the name at all.The second aspect of this (that it is a large change) is that it took a ton of discussion within the community, it required overwhelming consensus to do this, dozens of alternate names were proposed/suggested, there was a long debate, etc. Most of the reactions in the discussions here have already been heard and discussed, the reasons for why renaming is better than not were exposed very clearly, etc. (The conflict with the Roc programming language is also already known, and the Coq people got in touch with the Roc people to check that they were okay with the change.)
huh. the roc conflict is definitely what I first thought of. even if richard doesn’t care, it still kind of bugs me. this will have long term repercussions on the searchability of both of them, and could make people who don’t care to learn the difference think they have some relation.
The Roc people as in Richard Feldman?
Richard posted this in reply to the topic of Rocq on the Roc Zulip:
I don’t know the details, I saw a presentation at the last Coq workshop where Mathieu Sozeau mentioned that they got in touch with the people working on Roc, and checked that they were okay with the name change. The two projects are in very different parts of the language space, so they thought it would be okay.
I remember really liking Roc when I looked at it a couple of years ago. Is there a killer app or niche yet for the language?
Roc isn’t even at a numbered version yet (i.e. it’s pre v0.0.1), so it’s still in the experimentation phase. The biggest area of interest at the moment seems to be backend web development, but there’s also discussion around gamedev and scientific computing uses.
I’ve been waiting for this for so long. Thanks!
EDIT: I know you want to push your own editor for ROC, but are there any plans to provide a TreeSitter grammar and an LSP, so we can use Helix/Nvim/Emacs/… ?
Short answer is that the editor project has been deprioritized a lot (e.g. I don’t expect any work to be done on it in 2024) because we realized there’s a way to build the editor plugin ecosystem we want to build in a way that works across multiple editors!
There already is a preliminary language server, and there are instructions in the VS Code extension for how to get it set up: https://github.com/ivan-demchenko/roc-vscode-unofficial#configuring-language-server
An initial tree-sitter grammar was created a few days ago, and there is a slightly flakey language server that integrates with one of the VSCode extensions. I think plans for the Roc editor have changed, but I haven’t kept up with what the new plan is.
Elm 0.19 nuked any good thoughts I had towards the language. Limiting native modules to a small group of people was a bad design decision, and the lack of leadership has imo doomed the language. elm-janitor is a project that exists to cleanup the mess, and they link a useful but sad spreadsheet of all the fixes that have yet to be merged.
If I were to stick to a functional language today, I would bet on Roc succeeding where Elm couldn’t.
I think ReScript has pretty much taken that niche already. It did what Elm didn’t–provide a pragmatic, interoperable integration with the rest of the JS ecosystem while also providing type safety and fast compiles.
mm this does look like a proper replacement, whereas my Roc evangelism is probably premature. my first question would be how it differs from reason ml which also fills the functional-web niche
My understanding is that ReScript is essentially a rebranding of ReasonML which has mostly been abandoned.
ReScript is a continuation of the ReasonML functional-web effort. It split off from the ‘ReasonML’ branding to create a more integrated, turnkey experience for typed functional web dev.
This may sound nit-picky or unreasonable, but the immediate blocker for me adopting ReScript is its take on
Option/undefined/null.I actually do use
undefinedandnullto mean semantically different things in my JavaScipt/TypeScript code. For example, if I’m sending a POST request to my backend API, it will treat a missing field (undefined) as unset and needing the default value (if it is intended to be optional), and it will treat a presentnullto mean that the client is explicitly denoting “emptiness” for the value and it will NOT be overwritten with a default value.Likewise, in languages with a generic Option type (Swift, Rust, Kotlin-when-I-write-it), I do sometimes represent the above semantics similarly by having an
Option<Option<T>>(orOption<T?>in Kotlin) for an “optional nullable” value.I realize that ReScript has escape hatches for these things, but I feel like “escape hatches” are for uncommon situations; I don’t want to have these “escape hatches” all over my code and have to fight against the grain of the language.
As much as I loathe TypeScript, I feel like I’m stuck with it.
ReScript can deal with
nullandundefinedseparately using its provided APIs:Right, I know. It’s just that the standard library functions all use
option<'a>, so I worry about needing to do a bunch of fiddling between three kinds of “maybe present” types instead of the usual two. Maybe in practice it isn’t bad, but I’ve dug myself into plenty of holes before while trying to go against the grain of the language I was using.I don’t see any big problems, you just define your form fields with strong types like
myField: option<string>and convert the weaker-typed values received over the network into strongly-typed internal values with checks and converter functions. It’s conceptually very similar to TypeScript except it doesn’t suffer from the ‘wrapping’ problem because the option type has special compiler support.Wow that spreadsheet is really depressing.