That feels a little bit reductive, at least given that non-English news is precisely what big part of population is going to consume. There isn't even an unified market for news content given the language boundaries.
Not to say there aren't many shallow, clickbait sources, but there're good ones as well.
The better educated somebody is, the more likely they are to have reasonably fluency in English. There are some great non-English sources out there, but English is the most read language by well educated people.
Not saying there are not great news content in other languages. However English should be expected to dominate over the whole world.
This is a bizarre take. Newspapers, even really good ones, generally don't target international readers. They target their home country's readers. How many Englishmen are interested in the machinations of unions in Paris? How many Frenchmen?
Obviously the best coverage will be in the country's majority language.
The best coverage for a country will be in that countries language.
However for world events coverage English is the more likely language. For niches that might interest you English might be the only option since odds are someone in every country speaks English and reports on that niche. (odds, but no guarantee)
> However for world events coverage English is the more likely language
Can you explain how you arrived at this conclusion?
Certainly when I lived in Japan and picked up a copy of the Yomiuri Shimbun, the world events coverage was in Japanese. And when I've traveled in France, Le Monde was entirely in French. The international section didn't become English.
> For niches that might interest you
I'm not sure you're talking about newspapers at this point.
I've just tried it in one of the supported languages, and it seems to respond far better than any model under 24B that I've tried before. With its licensing, it sounds much more exciting to me than the OP.
Another fun one in case someone's interested: the post shows an example of a type that may sometimes lack the inner value of a given type (`Maybe a`), but what about type that never contains such inner value? Would it be useful? And could you define some interface in style of `Functor` class that would prove this property?
Very nice release, Gleam looks like a good contender for "high-level Rust".
Small nitpick:
> One drawback of this sound type system is that converting untyped input from the outside world into data of known types requires some additional code which would not be required in unsound systems.
It isn't really consequence of its sound type system, but its runtime representation - assuming it requires type information to be safely constructed and manipulated, you really need to generate code to do so, but the compiler could instead choose to use more dynamic representation, e.g. compiling to ordinary Erlang maps / JS objects.
How would this representation be converted back to known types without similar decoders? Right now Gleam compiles custom types to Erlang records (tuples) and JS classes.
The representation would be _the_ runtime representation of those types - in the same way as TypeScript objects are just JavaScript objects with static analysis. The choice of representation is a matter of performance and statically-typed languages usually choose to compile every type to custom representation simply because it makes things more efficient, not because they have to. Unless you implement some baked-in reflection mechanism, there isn't really anything that ties runtime representation to its type, which is a compile-time concept.
The other problem is ensuring that such casting is safe, but that requires runtime checking even in dynamically typed languages.
Since it requires runtime checking anyway, that code has to live somewhere. The decoders are that code. I don't understand how changing the runtime representation would allow to not have those decoders. Unless you mean they should be implicitly generated by the compiler. Or maybe I'm just missing what you're saying.
My point was about the sentence from the original post - its not the consequence of sound type system, its the consequence of choice of runtime representation. If runtime checking matters (which it does in practice), then we don't get any advantage in terms of simplicity by using "unsound" system, because we need to write that code anyway.
You seem to have a very specific use case in mind and I am not really sure whether Prolog is going to be a good fit, but there was recently a discussion about the language: https://news.ycombinator.com/item?id=40994552
Specifically, this online book (mentioned in that discussion) may be a good resource, I've used author's content as a reference several times: https://www.metalevel.at/prolog
In a sense, doesn't speaking naturally in front of a camera require you to be more fake?
It's not the easiest thing to do, trying to address audience without any feedback, looking at a black object sitting in a room, in multiple attempts and with random interruptions needed to fix technical issues or change shot, while pretending that it is all part of normal, continuous discussion.
People watch him because he is genuinely good at what he does, not because of his presentation or editing skills.
Hi Andy! Deno basically restored my hope in being able to understand (T|J)S tooling, thanks for working on this amazing project.
2 questions:
Support for TS in notebooks in VSCode(ium) is currently broken; are there plans for resolving issues with definitions used across different cells?
Future plans for bundler sound interesting - is it something potentially able to replace e.g. esbuild for bundling frontend applications? I'm specifically curious because that would imply (static) Deno's import resolution for browser-run apps - one can use @luca's esbuild plugin, which is nice, but interacts poorly with other, custom plugins and has some rough edges.
reply