i’m seeing this at my corporate software job now. that service that you used to have security and product approval for to even read their Swagger doc has an MCP server you can install with 2 clicks.
the idea of one language to rule them all is very compelling. it’s been promised a lot, and now everyone hates Java.
but the truth is that Rust is not meant for everything. UI is an abstraction layer that is very human and dynamic. and i can come and say, “well, we can hide that dynamism with clever graph composition tricks” à la Elm, React, Compose, etc, but the machinery that you have to build for even the simplest button widget in almost every Rust UI toolkit is a mess of punctuation, with things like lifetimes and weird state management systems. you end up building a runtime when what you want is just the UI. that’s what higher level languages were made for. of course data science could be done in Rust as well, but is the lifetime of the file handle you’re trying to open really what you’re worried about when doing data analysis?
i think Rust has a future in the UI/graphics engine space, but you have to be pretty stubborn to use it for your front end.
There are real advantages to choosing a jack of all trades language for everything; for example it makes it easier for an engineer on one part of your project to help out on a different part of your project.
But it sounds like the OP didn't get any of the benefits of "jack of all trades", nor did he choose a field where Rust is "master of some".
There are lots of places where Lisp is unsuitable. I wouldn't use it for real-time control, for instance. Works great for orchestrating real-time controls though.
Lisp lost because none the the Lisperati came down from on high and deigned to explain how to use it for tasks running on the 1980s microcomputers.
Lisp also lost because the 1980s Lisperati spent all their time explaining lists and recursion over and over instead of explaining hash tables, vectors, and iteration.
Somehow, Lisp lost out to pathetically slow BASIC interpreters and C compilers that you had to swap floppies continuously for hours. That is a stunning level of fail.
Given that most modern languages are an half implementation of Lisp, with exception of C derived languages, in GC, JIT, JIT caches, REPL, dynamic code loading, IDE tooling, and how this AI wave is driven by the language that Peter Norvig coined as being an acceptable Lisp in 2010, I would say it still suceeded.
> also it is amazing to me that shells still exist in more-or-less the same form. dear god can I just get a terminal that runs something like Python directly?
i’ve been maining `nushell` for about 1.5 years now, and it’s basically this. a real programming language that is designed as a command runner and output parser. i have a ton of scripts that parse output from common commands like `git` and facilitate a ton of shell-based workflows: https://github.com/covercash2/dotfiles/tree/main/nuenv
nushell does this by default, sort of. it will show you autocompletes that are relevant to the current directory and will fallback to history more generally.
i’m a huge nushell fan. if you can stand a non POSIX shell, it’s great for working with any kind of structured data and has a sane mostly FP scripting language
When I first switched to nushell as my daily driver, I spent a lot of time integrating fzf in various creative ways, which was a fine learning exercise I guess.
But once I realized that the auto complete was sensitive to my cwd, I've since been using my fzf bindings less and less.
I'm very happy I made the switch, for this and many other reasons.
I bet yash is great, sorry for distracting from the topic, but since you asked...
It's not one killer feature, but it's a lot of small things that add up to this feeling that POSIX shells are stuck in a rut and that a better world is possible.
I'm going to use docker output as an example. I know that you can ask docker for json and then use jq, but let's pretend that what you're working with isn't so friendly as docker. Here's the output of "docker ps", a string:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS
786fc8348b7a postgres:12.6 "docker-entrypoint.s…" 9 hours ago Up 9 hours 127.0.0.1:5432->5432/tcp
I'm not proud of it, but I used to write bash scripts which looked like this:
Powershell feels to me like it's made by people who want all data to be structured, and who expect the app to do the work of structuring it for them. nushell feels like it's made by people who understand that text is king, and who are willing to attempt taming that beast as-is.
Plus there are a lot of batteries-included things that just feel nicer. Like if you want to make an http post request, the command is "http post". Of course you can still use curl, but I feel like this is so much more readable:
The built in help is excellent (try "help http post"), and the error messages are very pleasant:
$ 5 + "5"
Error: nu::parser::unsupported_operation
× addition is not supported between int and string.
╭─[entry #208:1:1]
1 │ 5 + "5"
· ┬ ┬ ─┬─
· │ │ ╰── string
· │ ╰── doesn't support these values
· ╰── int
╰────
I dunno, it's just nice. I'd be much happier teaching a bunch of scientists to use nushell than I am when teaching them to use bash. When I try to do the latter I feel like I just stepped out of a time warp from the 60's and they think I'm here to punish them.
That "detect columns" piping stuff looks very nice, though it looks like this is something that could be implemented extrashellularly (as discrete "detect" and "where" binaries)?
Eh, yes and no. There's nothing stopping a cohort of programs from adopting some standard and using it among themselves such that the binary values that are traveling across the pipes are interpreted by the recipient as having some type, and then if the reader of your pipe is a tty then you draw a pretty picture for the user, which gets you much of the way there in principle.
But as far as I know there's no portable way to write a program which can uncover enough of the pipeline to print an error message that spans multiple stages. So you get output from potentially many of them and you have to figure out who is complaining.
I'm not intimate with the implementation but it feels like nushell commands are compiled, so there's much less deduction necessary to just tell the user what is wrong in a way that considers the whole command instead of just one stage of the pipeline.
I haven't spent much time with the plugin interface yet, but the idea is that programs can register their input and output types with the shell if they want nushell to treat them like it does it's builtins. Its an extra step up front, but it seems like less of a mess than trying to coordinate types been programs without having a common touch point for them.
well, it’s a few things. a lot of it comes down to reading structured data and scripting. i will often stream logs from k8s or when running a service locally that outputs JSON, and nushell can parse the logs for readability or to find a particular field. i mean, that’s nothing jq couldn’t do. but having an integrated experience based more on readability makes things nice.
also when i say scripting i mean actual real functions. you can define a command complete with parsed documented arguments as if you’re using argparse or clap, and it also supports completions. so when i go to sign into the company VPN i have a lil function that grabs my credentials and takes an argument that is one of several providers my company uses, which i can autocomplete with tab because i’ve written a simple completion helper (literally a function that returns a list). it’s documentation as code, and i push all these helpers up to my company git repo so when someone asks me how to do something i have workable readable examples.
if you’ve ever wanted a real programming language (like Python) as your shell, i think this is worth a shot.
hard disagree. i had an experience just this morning looking for some pictures from an event i participated in, and the infinite scrolling was absolutely infuriating. they didn't have an index to filter on, and when i clicked on a picture to download it and navigated back, it took me to the top of the page. i had to scroll through about a dozen loading indicators to get back to where i was. sure, this was a bad implementation, but adding it to every single list of results on the web is asinine trend chasing and bad UX.
there's no way they were turning a profit. they definitely missed stuff all the time even with a ton of sensors. and sensors aren't the only cost. annotation is by far the most costly operational expense. new product? needs several annotated photos and recalibrated weight sensors. merchant decides to put Christmas branding on the same UPC? now all your vision models are poisoned for that product. it needs to be re-annotated for the month and a half it exists and the models need to be swapped out once inventory changes over again. as long as merchants are redesigning products (always) your datasets will be in a constant state of decay. even if your vision sensors are stationary and know the modular design up front, you still need to be able to somewhat generalize in case things get misplaced (big problem for weight sensors) or the camera gets bumped.
between dataset management, technology costs, research costs, rote operational costs, etc this is a very expensive problem to solve. and large models with a ton of parameters are little help; they may lower annotation costs a bit but will increase the cost of compute.
once i really dug into this problem i saw Amazon Go's Just Walk Out for what it really was: a marketing stunt
the biggest cost is not annotators at the scale you're imagining. it is labor costs.
Amazon bet that the federal govt would raise labor costs to $20/hr and all their competitors (besides themselves with this tech) would get wiped out. They even publicly campaigned and lobbied. That didn't come to fruition as the election promises turned to fluff, and the populists simply chose to empower unions instead.
i mean, labor cost (as in in-store labor) is the target for this cost optimization. unfortunately for the time being labor cost is not as significant as the other costs associated with annotation and dataset curation. technology costs are not really significant if this can be pulled off at scale.
in-store employees know where things are supposed to be and why, if at all, items are "misplaced" according to the modular design
I think this failing, and tesla failing to actually ship "self driving" is clear : machine learning definitely has complexity limits, that we are a long way off from perfecting or even getting beyond some reasonable threshold.
> The company’s senior vice president of grocery stores says they’re moving away from Just Walk Out, which relied on cameras and sensors to track what people were leaving the store with. [emphasis mine]
> Though it seemed completely automated, Just Walk Out relied on more than 1,000 people in India watching and labeling videos to ensure accurate checkouts.
> According to The Information, 700 out of 1,000 Just Walk Out sales required human reviewers as of 2022. This widely missed Amazon’s internal goals of reaching less than 50 reviews per 1,000 sales. Amazon called this characterization inaccurate, and disputes how many purchases require reviews.
> “The primary role of our Machine Learning data associates is to annotate video images, which is necessary for continuously improving the underlying machine learning model powering,” said an Amazon spokesperson to Gizmodo. However, the spokesperson acknowledged these associates validate “a small minority” of shopping visits when AI can’t determine a purchase.
The article is kind of all over the place, but it sounds like there were lots of sensors and also lots of human intervention.
How well does simulated data work in this space? My first stab at doing this scalably would be as follows: given a new product, physically obtain a single instance of the product (or ideally a 3d model, but seems like a big ask from manufacturers at this stage), capture images of it from every conceivable angle and a variety of lighting conditions (seems like you could automate this data capture pretty well with a robotic arm to rotate the object and some kind of lighting rig), get an instance mask for each image (using either human annotator or a 3d reconstruction method or a FG-BG segmentation model), paste those instances on random background images (e.g. from any large image dataset), add distractor objects and other augmentations, and finally train a model on the resulting dataset. Helps that many grocery items are relatively rigid (boxes, bottles, etc). I guess this would only work for e.g. boxes and bottles, which always look the same, you'd need a lot more variety for things like fruit and veg that are non rigid and have a lot of variety in their appearance, and we'd need to take into account changing packaging as well.
as mentioned in another comment, "scale" is not just horizontal, it's vertical as well. with millions of products (UPCs) across different visual tolerances it's hard to generalize. your annotation method is indeed more efficient than a multistep "go take a bunch of pictures and upload them to our severs for annotators" but is still costly in terms of stakeholder buy-in, R&D, hardware costs, and indeed labor. if you can scope your verticals such that you only have, say, 1000 products the problem become feasible, but once you start to scale to an actual grocery store or bodega with ever-shifting visual data requirements the problem doesn't scale well. add in the detail that every store moves merchandise at different rates or has localized merchandise then the problem becomes even more complex.
the simulated data also becomes an issue of cost. we have to produce a realistic (at least according to the model) digital twin that doesn't interfere too much with real data, and measuring that difference is important when you're measuring the difference between Lay's and Lay's Low Sodium.
i'm not saying it's unsolvable. it's just a difficult problem
I want to know why these places don't simply dramatically drop the accuracy requirement.
Rather than giving itemized receipts, give just a total dollar value. Then just make sure that most customers are charged within 10% of the correct amount.
Only if the customer requests and itemized receipt, then go watch the video and generate them one. But after a while most customers won't request it, and that means you can just guess at a dollar amount and as long as you're close-ish (which should be easy based on weight and past purchase history), that's fine.
The problem is taxes. Different items can be taxed differently. Itemized receipts are a must from the get-go unless you want to explain to the government that you underpaid them because you charge within a 10% error-margin.
Come on, it isn’t anything to do with being a “marketing stunt.” Often products like this are expected to lose money at first, but they hope with enough R&D and scale that they can make it successful eventually.
For example, you are pointing out that annotating is costly, but that’s an expense that scales independently of the number of stores. So with enough scale it wouldn’t be as big a deal. Or if they figured out some R&D that could improve it too.
right, that's how it starts. but the improvements in methodology simply aren't there as the ML sector has been laser focused on generality in modeling (GenAI as it's affectionately known). "at scale" doesn't just mean more stores; it means more products and thus more annotation. how many UPCs do you figure there are in a given Target or Whole Foods? i assure you it's in the millions.
one advantages of the Amazon Go initiative is a smaller scope of products.
a big problem in the space is that products that look very similar will be clustered in the same section. large models are very good at generalizing, so they may be more attuned to "this is a Christmas thing", but they won't know that it should be classified as the same UPC as the thing that was in that spot yesterday without you specifically telling it to. how would it know it's not a misplaced product or a random piece of trash? (you won't believe the things you find on store shelves once you start looking) you can definitely speed up your annotation time with something like SAM[1], but it will never know without training or context that it's the same product but Christmas (ie it resolves to the same UPC).
