That's an assumption, as they could easily develop a search engine and incorporate the same advertising model used by Microsoft Bing.
I've noticed an interesting pattern: before releasing LLaMA 3, OpenAI provided access to ChatGPT 3.5 without requiring registration.
Meta might also follow this path with its own search engine. Did you know that you can now ask questions directly on Instagram and receive answers from Meta AI using LLaMA 3?
Why go elsewhere for information when you can easily find it in the app you use every day?
Couldn't the zero value be nil? I get that some types like int are not nil-able, but the language allows you to assign both nil and int to a value of type any (interface{}), so I wonder why it couldn't work the same for sum types. i.e. they would be a subset of the `any` type.
Enums and sum types seem to be related. In the code you wrote, you could alternatively express the Hot and Cold types as enum values. I would say that enums are a subset of sum types but I don't know if that's quite right. I guess maybe if you view each enum value as having its own distinct type (maybe a subtype of the enum type), then you could say the enum is the sum type of the enum value types?
They can certainly help solve some of the same problems. Does that make them related? I don't know.
By definition, an enumeration is something that counts one-by-one. In other words, as is used in programming languages, a construct that numbers a set of named constants. Indeed you can solve the problem using that:
type Temperature int
const (
Hot Temperature = iota
Cold
)
func SetThermostat(temperature Temperature) {
switch temperature {
case Hot:
fmt.Println("Hot")
case Cold:
fmt.Println("Cold")
}
}
But, while a handy convenience (especially if the set is large!), you don't even need enums. You can number the constants by hand to the exact same effect:
type Temperature int
const (
Hot Temperature = 0
Cold Temperature = 1
)
func SetThermostat(temperature Temperature) {
switch temperature {
case Hot:
fmt.Println("Hot")
case Cold:
fmt.Println("Cold")
}
}
I'm not sure that exhibits any sum type properties. I guess you could see the value as being a tag, but there is no union.
const (
Hot Temperature = 0
Cold Temperature = 1
)
Isn't really a good workaround when lacking an enumeration type. The compiler can't complain when you use a value that isn't in the list of enumerations. The compiler can't warn you when your switch statement doesn't handle one of the cases.
Refactoring is harder - when you add a new value to the enum, you can't easily find all those places that may require logic changes to handle the new value.
Enums are a big thing I miss when writing Go, compared to when writing C.
> Isn't really a good workaround when lacking an enumeration type.
Enumeration isn't a type, it's a numbering construct. Literally, by dictionary definition. Granted, if you use the Rust definition of enum then it is a type, but that's because it refers to what we in this thread call sum types. Rust doesn't support "true" enums at all.
> The compiler can't complain when you use a value that isn't in the list of enumerations.
Well, of course. But that's not a property of enums. That's a property of value constraints. If Go supported value constraints, then it could. Consider:
type Temperature 0..1
const (
Hot Temperature = 0
Cold Temperature = 1
)
Then the compiler would complain. Go lacks this in general. You also cannot define, say, an Email type:
type Email "{string}@{string}"
Which, indeed, is a nice feature in other languages, but outside of what enums are for. These are separate concepts, even if they can be utilized together.
> Enums are a big thing I miss when writing Go, compared to when writing C.
Go has enums. They are demonstrated in the earlier comment. The compiler doesn't attempt to perform any static analysis on the use of the use of the enumerated values because, due to not having value constraints, "improper" use is not a fatal state[1] and Go doesn't subscribe to warnings, but all the information you need to perform such analysis is there. You are probably already using other static analysis tools to assist your development. Go has a great set of tools in that space. Why not add an enum checker to your toolbox?
[1] Just like it isn't in C. You will notice this compiles just fine:
> but all the information you need to perform such analysis is there.
No, it isn't, unlike C, in which it is. The C compiler can actually differentiate between an enum with one name and an enum with a different name.
There's no real reason the compiler vendor can't add in warnings when you pass in `myenum_one_t` instead of `myenum_two_t`. They may not be detecting it now, but it's possible to do so because nothing in the C standard says that any enum must be swappable for a different enum.
IOW, the compiler can distinguish between `myenum_one_t` and `myenum_two_t` because there is a type name for those.
Go is different: an integer is an integer, no matter what symbol it is assigned to. The compiler, now and in the future, can not distinguish between the value `10` and `MyConstValue`.
> Just like it isn't in C. You will notice this compiles just fine:
That's about as far as you can get from "compiling just fine" without getting to "doesn't compile at all".
And the reason it is able to warn you is because the compiler can detect that you're mixing one `0` value with a different `0` value. And it can detect that, while both are `0`, they're not what the programmer intended, because an enum in C carries with it type information. It's not simply an integer.
It warns you when you pass incorrect enums, even if the two enums you are mixing have identical values. See https://www.godbolt.org/z/eT861ThhE ?
type E int
const (
A E = iota
B
C
)
enum E {
A,
B,
C
}
What is missing in the first case that wouldn't allow you to perform such static analysis? It has a keyword to identify initialization of an enumerated set (iota), it has an associated type (E) to identify what the enum values are applied to, and it has rules for defining the remaining items in the enumerated set (each subsequent constant inherits the next enum element).
That's all C gives you. It provides nothing more. They are exactly the same (syntax aside).
> It warns you
Warnings are not fatal. It compiles just fine. The Go compiler doesn't give warnings of any sort, so naturally it won't do such analysis. But, again, you can use static analysis tools to the same effect. You are probably already using other static analysis tools as there are many other things that are even more useful to be warned about, so why not here as well?
> enum in C carries with it type information.
Just as they do in Go. That's not a property of enums in and of themselves, but there is, indeed, an associated type in both cases. Of course there is. There has to be.
> What is missing in the first case that wouldn't allow you to perform such static analysis?
Type information. The only type info the compiler has is "integer".
> It has a keyword to identify initialization of an enumerated set (iota),
That's not a type.
> it has an associated type (E)
It still only has the one piece of type information, namely "integer".
> and it has rules for defining the remaining items in the enumerated set
That's not type information
> That's all C gives you.
No. C enums have additional information, namely, which other integers that type is compatible with. The compiler can tell the difference between `enum daysOfWeek` and `enum monthsOfYear`.
Go doesn't store this difference - `Monday` is no different in type than `January`.
> Warnings are not fatal.
Maybe, but the warning tells you that they types are not compatible. The fact that the compiler tells you that the types are not compatible means that the compiler knows that the types are not compatible, which means that the compiler regards each of those types as separate types.
Of course you can redirect the warning to /dev/null with a flag, but that doesn't make the fact that the compiler considers them to be different types go away.
Whether you like it or not, C compilers can tell the difference between `Monday` and `January` enums. Go can't tell the difference between `Monday` and `January` constants. How can it?
Nobody said it was. Reaching already? As before, enums are not a type, they are a numbering mechanism. Literally. There is an associated type in which to hold the numbers, but that's not the enum itself. This is true in both C and Go, along with every other language with enums under the sun.
> The compiler can tell the difference between `enum daysOfWeek` and `enum monthsOfYear`.
Sure, just as in Go:
type Day int
const (
Monday Day = iota
Tuesday
// ...
)
type Month int
const (
January Month = iota
February
// ...
)
func month(m Month) {}
func main() {
month(January) // OK
month(Monday) // Compiler error
}
> Go doesn't store this difference - `Monday` is no different in type than `January`.
Are you, perhaps, mixing up Go with Javascript?
> How can it?
By, uh, using its type system...? A novel concept, I know.
Regardless of the rest of this thread, I appreciate this comment. It helped crystalize 'enum' in the context of 'sum' for me in a way that had previously been lacking. Thanks.
Traditionally, enums have been a single number type with many values (initialized in a counted one-by-one fashion).
Rust enums are as you describe, as they accidentally renamed what was historically known as sum types to enums. To be fair, Swift did the same thing, but later acknowledged the mistake. The Rust community doubled down on the mistake for some reason, now gaslighting anyone who tries to use enum in the traditional sense.
At the end of the day it is all just 1s and 0s. If you squint hard enough, all programming features end up looking the same. They are similar in that respect, but that's about where the similarities end.
I think you missed the point - this is what they mean by "defined so loosely as to be uninformative." By saying "in some sense" you are allowing arbitrarily abstract definitions of the term "computer" thereby making the term itself no longer useful.
It really seems like there are a lot of issues with rendering images in the cli. I know kitty has a python version too but kitty doesn't play nice with tmux and the dev isn't a fan of tmux[0]. To be fair, I'd love to move away from tmux but I use remote machines all day and I haven't found a good alternative. I don't care about tiling (I can do that in vim, even the terminal), though it is useful (mostly switching sessions for managing workflow context). I'd also love to see someone pick back up mosh (ssh).
A critical problem is that if you work on remote machines a lot you probably gotta be able to build some things from source and build into your local bin because you don't have sudo access on the machine. Preferably installs without network access.
It's not really that strange that tmux doesn't support sixels. It's quite a bit more complicated and resource-intensive than ANSI Escape Codes or ncurses.
It might be fine for local[1] multiplexing but over the network it is not as fast as even something like VNC or RDP.
On macOS iterm2 has really nice integration with tmux[1] via tmux's "Control Mode". It allows you to use tmux almost transparently including image printing, mapping windows/split panes into tabs/native splits.
Your comment seems to presume that AI will not get any better than it is now. Imagine an AI that understands how to create deep, impactful music better than humans do, because it understands how music works at a biochemical level. Imagine it can even predict the dynamics you're describing, about employing "unwanted artifacts" in the music as a way to evolve new genres. It would no longer need to create such obviously derivative works at that point, and it could generate music that sounds completely unique to us. It may take a long time to reach that point, but when it does, the kinds of music that it generates won't be able to be dismissed so easily.
Your comment seems to presume that the line between what a human is and what an AI is will stay clear. I'm predicting that this line will be increasingly blurry. Some people see smartphones as cybernetic extensions. When I call someone across the globe, did I do that or my phone? Is that a capability I posses or my phone? Does it make sense to separate the two?
Even if AI gets way better, the one thing that I don't foresee changing is what makes things valuable and or desirable. Sparsity. If everyone has it or can create it, it's not special. I think the GP was referring to this sparsity.
You're talking about agency there I think. No your phone didn't do that, you did.
However, if later down the line we create autonomous agents that can initiate the creation of said music themselves then I'd call that enough agency to say that the machine is "making music". Could probably almost do it now; tailored LLMs, image diffusion, music diffusion and you could have an ML agent that acts as a musical artist; posts to instagram etc with images of their persona "working on something new", releasing new tracks, bantering, etc. There are already AI OF stars apparently.
We could say "yeah but a human still set it up and told it to make music" but I would discount that; pretty sure no human has total agency, we are all impacted by our environment, peers, culture and all sorts of other external influences.
And I don't think sparsity changes things (maybe in the material world) but culture certainly does. Things are popular because they appeal to us in bulk, rarity/sparsity always result in higher effort for the payoff and so decreases popularity.
Alright, what if someone has a neural implant and that thing is running and or connected to an AI? Are you still sure the line is clear and sharp in that scenario?
Yeah, I'm very confused by this. Why is the example also showing a hard-coded 2023 in the component usage? Shouldn't the component be responsible for rendering that?
I believe it's because the `${this.textContent} - ${year}` will render it as `2023 - 2024`. The hardcoded 2023 can be whatever you want as to indicate the start of the copyright.
TLDR to get better performance, use bulk inserts instead of inserting one row per query. And (unrelated to DB perf) don't use the spread operator in JS for passing function args (the author says not to use the spread operator at all but you don't need to go that far)
PG has “copy” which would blow away bulk inserts. Other DB vendors have similar stuff for high-performance inserts. You would be much better off using those than using bulk inserts.
Have you seen protobuf.js? I've dug quite deep into its generated code and have not seen any runtime magic. It's just directly working with the protobuf wire format and transferring the data to/from fields with very explicit code.
I can't speak for Google's official implementation though.
A lot of stores have a "bulk food" section where you can get nuts or granola this way. It takes less space than the same amount of product in individual packages.
