HN user
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.
Since encoding/json marshals a nil slice or map as a JSON null
How did that make it into the v1 design?
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.
Any more details on the setup? How does it kick of based a push? Could you kick it off on a successful GitHub run?
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 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?
Perhaps SpaceX could offer (a slightly more expensive) CubeSat module that has built in deorbiting thrusters that will bring it down after X years.
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.
Doesn't seem relevant given the number of places in Europe that are more progressive and failed to replicate silicon valley.
Type inference should solve that if Go ever gets that.
Did they know of specific instances of fraud or just more generally that it was going on?
How does it perform on short strings (e.g. <= 16 bytes)? We've seen several new hash functions lately with great throughput numbers, but unfortunately they often end up being slower than FNV when used e.g. on keys in hash maps, which are often short strings.
Glassdoor salaries for Google Switzerland: https://www.glassdoor.com.au/Salary/Google-Zurich-Salaries-E...
The average base salary seems to be CHF 136,344 (USD 140,000) per year.
Health insurance starts at around CHF 280/month for a 35 year old currently: https://en.comparis.ch/krankenkassen/grundversicherung/krank...
You can reduce that if you opt for less choice (e.g. you can only use particular doctors) to around CHF 235/month.
Just sticking with the pure types there's currently no generic stream model that works well. No stream fusion system fuses all cases (even in theory) and they also fail to fuse the cases they're supposed to handle too often in practice.
I haven't looked at pipes, but I'm guessing it doesn't all fuse away either.
This whole thread is exactly about how "write libraries!" (if done outside the standard library) doesn't work (see my top post).
I do agree that lack of modularity features certainly doesn't help though.
Risking to go off-topic a bit, I think the lazy versions of Text and ByteString wouldn't have been needed if we had nice abstractions for streams (lists are not, they cause allocation we cannot get rid of) so that you don't need to implement a concrete stream type (e.g. lazy Text and lazy ByteString) for every data type.
Rust does this well with iterators, for example.
Agreed, except for the "like Go" part, which is unnecessarily ad-hoc.
You don't need a standard library to win if you don't have any competitors (in the browser). :)
Fitness for purpose is relative to the other options.
There can be more than one problem, including having a small standard library.
But C didn't have competitors with large standard libraries, so it didn't suffer as much for it.
The "big corporate sponsor" argument often comes up when discussing language success. Google doesn't really put more than a few people's time into Go, the rest is open source. Other languages like Python didn't have any real backing until way after success.
I wouldn't recommend following the Haskell approach. It hasn't worked well for us. (I took part in creating the Haskell Platform and the process used to add packages to it. I also used to maintain a few of our core libraries, like our containers packages and networking).
Small vs large standard library:
A small standard library with most functionality in independent, community-maintained packages has given us API friction as types, traits (type classes), etc are hard to coordinate across maintainers and separate package release cycles. We ended up with lots of uncomfortable conversions at API boundaries.
Here's a number of examples of problems we currently have:
- Conversions between our 5(!) string types are very common.
- Standard library I/O modules cannot use new, de-facto standard string types (i.e. `Text` and `ByteString`) defined outside it because of dependency cycle.
- Standard library cannot use containers, other than lists, for the same reason.
- No standard traits for containers, like maps and sets, as those are defined outside the standard library. Result is that code is written against one concrete implementation.
- Newtype wrapping to avoid orphan instances. Having traits defined in packages other than the standard library makes it harder to write non-orphan instances.
- It's too difficult to make larger changes as we cannot atomically update all the packages at once. Thus such changes don't happen.
Empirically, languages that have large standard libraries (e.g. Java, Python, Go) seem to do better than their competitors.
"Managers focus on ..., creating a vision for how that team will execute its goals"
Confusing management with leadership is one of the main reasons for politics and empire building. Once managers think they're in charge of figuring out the vision, instead of that being the whole team's responsibility, you're lost in top-down management land.
It looks like you have a bit of a biased experience from working on Chrome. The absolute majority of the code is in the monorepo.
Look at hash array mapped tries, which is what most functional languages use to implement hashmaps.
Because he wrote one of the most successful ones?
As the designer of the Strict pragma I can say that Idris had nothing to do with anything.
The core set of packages (e.g. those in the platform) tend to not break backwards compatibility, but you're right that there are still packages that move fast and do.