They do more than that. If you ask for ui with a button that button won't be upside down even if you didn't specify its orientation. Lots of the detail can be inferred from general human preferences, which are present in the LLMs' training data. This extends way beyond CS stuff like details of algorithm implementations.

Isn't "not being upsidedown" just one of the default properties of a button in whatever GUI toolkit you are using? I'd be worried if an LLM _did_ start setting all the possible button properties.

Putting LLMs on a pedestal is very much in vogue these days.

If you ask for increase and decrease buttons they will put the right icons on it (not words) and lay them out right.

I cannot confirm that to work reliably and properly from experience of asking various LLMs about reducing button size in tkinter to a minimum for a button's label.

That’s exactly what they said. Details “elsewhere in its training set”.

> Since encoding/json marshals a nil slice or map as a JSON null

How did that make it into the v1 design?

I had a back and forth with someone who really didn't want to change that behavior and their reasoning was that since you can create and provide an empty map or slice.. having the marshaler do that for you, and then also needing a way to disable that behavior, was unnecessary complexity.

Why shouldn't it be? The nil is null and empty array is an empty array, they are completely different objects.

Not in Go. Empty slices and empty maps are nil, so it's ambiguous.

To be precise.. empty slices and maps sometimes behave like nil (len, range etc) and sometimes not (inserting into a nil map). The former is a neat convenience, and I think extending that to JSON marshaling makes sense.

No, empty slices and empty maps in Go are not nil.

This is the idiomatic way of declaring empty slices in Go, and it prints true:

    var slice []string
    fmt.Println(slice == nil)

Whether to judge the line below idiomatic, or not, is a question I leave to the authorities -- but it is highly convenient, and prints "false".

  slice := []string{}
  fmt.Println(slice == nil)

This is indeed a nil slice, and it does have len() == 0, but Go also has a concept of empty slices separate from nil slices

The language just has a bad habit of confusing them some of the time, but not consistently, so you can still occasionally get bit by the difference

As someone who uses Go a lot, it's just one of those things...

Yes because it's nil. You declared it but not created. Same for map. Same for var something *string

how is a nil map not null? It certainly isn’t a zero-valued map, that would be {}.

The zero value of a map is indeed nil in Go: This prints true (https://go.dev/play/p/8dXgo8y2KTh):

    var m map[string]int
    println(m == nil)

Ok, true!

It should be marshaled into {} by default, with a opt-out for special use cases.

There’s a simple reason: most JavaScript parsers reject null. At least in the slice case.

Not sure what you mean here by "most JavaScript parser rejects null" - did you mean "JSON parsers"? And why would they reject null, which is a valid JSON value?

It's more that when building an API that adheres to a specification, whether formal or informal, if the field is supposed to be a JSON array then it should be a JSON array. Not _sometimes_ a JSON array and _sometimes_ null, but always an array. That way clients consuming the JSON output can write code consuming that array without needing to be overly defensive

Well those are different things, aren't they? Empty slice/map is different from nil. So it makes a lot of sense that nil = null and []string{} = [], and you have an option to use both. That being said, it starts to make less sense if you work with go where the API mostly treats it as equivalent (append, len, []). So that would be my guess how it ended up the way it did.

Also, now that nil map is an empty object, shouldn't that extend to every nil struct that doesn't have a custom marshaller? It would be an object if it wasn't nil after all...

It is different from nil, but then again a nil map in Go behaves like an empty map when reading from it. If you consider serialization to be "reading", therefore, it makes sense to interpret it accordingly.

That is not true, though. Reading from a nil map panics, and reading from an empty map does not.

It doesn't. E.g. this prints 0:

var m map[string]int = nil fmt.Println(m["foo"])

The language spec is also pretty clear on this; https://go.dev/ref/spec#Map_types:

> A nil map is equivalent to an empty map except that no elements may be added.

We used to use Maestro but then they unfortunately decided to go all in on AI and hiked the price to match, making it no longer worthwhile for us.

We loved Maestro but we didn’t like the pricing and the team wanted something more predictable. We are using Moropo and it’s been great. Very affordable, good DX, and it’s all basically just Maestro with extras.

The advantages of using open source! It would be great if it became industry standard and more companies would offer it as a service.

Moropo sounds great, but unable to find open source repo / self-host docs. Would you be able to share the GitHub link for self-hosting Moropo? Thanks

Tom, co-founder of Moropo here, thanks for the mention :-)

Is the open-source version not usable/allowed for CI/CD environment?

Yep free and open-source to use. Plenty of folks run Maestro on directly on GitHub Actions, Bitrise, etc. Teams often run on our hosted cloud infra for parallelism and reliability when scaling up their testing, but that's totally up to you!

At SoFi we are using it with gitlab and AWS Linux/Mac runners. We can do parallel runs, data driven, get test logs, screen recordings etc

Hey tibbe - co-founder of Mobile.dev here. First off, totally get where you're coming from. We do offer a startup discount, but would love to dig in more to see if there's something we can work out. My co-founder and I would love to chat if you're open to it! Just shoot me a note if interested! leland@mobile.dev

Wait? You have to pay? Or you mean the cloud?

Any more details on the setup? How does it kick of based a push? Could you kick it off on a successful GitHub run?

They support Github, Gitlab and Bitbucket. Here are the Github instructions: https://developer.apple.com/documentation/xcode/connecting-x...

Why not user-fuse?

This missed the point. The point of not that you can forget to check the null case. The point is that you can express that sometimes there's no null case.

The "no null" case in traditional languages is just "int" instead of "*int". All values inside an "int" are valid integers.

Certainly it's problematic to use the same language primitive to mean "a pointer" and "this might be empty", but it's what people use them for in every language that has pointers (that I've used anyway).

That conflates pass by value/by reference distinction with being optional.

This means you need magic values for "maybe int" with no help from the type system. And you can't express "there's definitely an int at that address".

The Data Parallel Haskell work on flattening ran into problems with space blow-up due to replicating arrays to perform flattening. Does Futhank avoid those problems?

Yes. Since Futhark does not perform full flattening, replication is limited to how much parallelism is exploited, not how much parallelism is available.

(That said, memory explosion is still a common symptom when the compiler misjudges how much parallelism should be exploited.)

Aside: does that mean that Falcon 9 could carry ~20,000 CubeSats at the cost of 62M/20k = USD 3,100 per satelite? That would be awesome. Now if I could just find another 19,999 people who want to ride-share with me.

I wonder if this is a good thing. On one hand, the common availability of cubesats would be so much fun from a hacker point of view, but on the other I worry that such a low cost per satellite will start to pollute space. If every bay area hobbiest has one floating in the sky, we're inevitably going to have ones that go unmanaged, rogue, etc with no plans for cleanup/repair if things go wrong.

Many of the cheapest, hackeriest cubesats are deployed into low orbits that decay within weeks or months. Space isn't completely empty, only mostly empty, and even minute air resistance is enough that things like the ISS need to thrust regularly to stay in orbit [1]. I believe it's a common mission profile for cubesats that're built as aerospace engineering senior projects, for example.

[1]: http://www.heavens-above.com/IssHeight.aspx

If a cloud of 20000 cubesats were released by a single rocket, at least they would all be in approximately the same orbit, which is better than having 20000 cubesats spread out over 20000 orbits. Not to mention, they don't stay up indefinitely- launched into a low orbit, drag eventually pulls them back down.

I'd definitely buy a cubesat launch slot for 3k. Perhaps someone should set up a kickstarter or something.

You can't get a launch license unless you fit within the deorbit standard that was internationally agreed upon. "No plans"?

Perhaps SpaceX could offer (a slightly more expensive) CubeSat module that has built in deorbiting thrusters that will bring it down after X years.

Air resistance will already take care of that, depending on the orbit. (And for 3k, you aren't getting an ultra-high orbit)

Yet another use case for solar sail laser arrays: deorbiting clouds of debris and tiny satellites.

Oh, they'd be able to deorbit big satellites, too, which is a bit of a problem.

Unless your Australian... in which case the government says you have to have a stupidly huge insurance policy and other red tape that would make it easily 10x that cost.

If you use the 10 flights of a f9 is that more like $310 per satellite?

Doesn't seem relevant given the number of places in Europe that are more progressive and failed to replicate silicon valley.

That doesn't seem relevant given the many other differences between European countries and the US, that don't apply to California vs Kansas.

Type inference should solve that if Go ever gets that.

This has already been requested quite often, the Go team refused pretending it wasn't "readable". "readability" is their number one excuse to get away with not discussing a feature at first place.