> I get the impression that's the same reason their fine-tuning services never took off either
Also, very few workloads that you'd want to use AI for are prime cases for fine-tuning. We had some cases where we used fine tuning because the work was repetitive enough that FT provided benefits in terms of speed and accuracy, but it was a very limited set of workloads.
Very typical e-commerce use cases processing scraped content: product categorization, review sentiment, etc. where the scope is very limited. We would process tens of thousands of these so faster inference with a cheaper model with FT was advantageous.
Disclaimer: this was in the 3.5 Turbo "era" so models like `nano` now might be cheap enough, good enough, fast enough to do this even without FT.
> most people who want public transit want it so they can get OTHER people off the road
Such a bad take. I would guess you've never been to Japan, Taiwan, any country with a fast, well-functioning public transit system. It's so convenient to not have to drive everywhere and have dependable transit options. Not to mention for seniors and even children (yes; kids in Asia board transit by themselves all the time).
You’re welcome to say you cannot use searches well and ask me for one, rather than pretending it’s a gotcha to never have been given something you never asked for.
Again, brain rot. I’m outta here - people line you are ruining this site.
> But I haven't used source generators in C# in at least 10 years, and I honestly don't know why anyone would at this point.
A challenge with .NET web APIs is that it's not possible to detect when interacting with a payload deserialized from JSON whether it's `null` because it was set to `null` or `null` because it was not supplied.
A common way to work around this is to provide a `IsSet` boolean:
private bool _isNameSet;
public string? Name { get; set { ...; isNameSet = true; } }
Now you can check if the value is set.
However, you can see how tedious this can get without a source Generator. With a source generator, we simply take nullable partial properties and generate the stub automatically.
public partial string? Name { get; set; }
Now a single marker attribute will generate as many `Is*Set` properties as needed.
Of course, the other use case is for AOT to avoid reflection by generating the source at runtime.
That is tedious with or without a source generator, mainly because there's a much better way to do it:
public Optional<string> Name;
With Optional being something like:
class Optional<T> {
public T? Value;
public bool IsSet;
}
I'm actually partial to using IEnumerable for this, and I'd reverse the boolean:
class Optional<T> {
public IEnumerable<T> ValueOrEmpty;
public bool IsExplicitNull;
}
With this approach (either one) you can easily define Map (or "Select", if you choose LINQ verbiage) on Optional and go delete 80% of your "if" statements that are checking that boolean.
Why mess with source generators? They're just making it slightly easier to do this in a way that is really painful.
I'd strongly recommend that if you find yourself wanting Null to represent two different ideas, then you actually just want those two different ideas represented explicitly, e.g. with an Enum. Which you can still do with a basic wrapper like this. The user didn't say "Null", they said "Unknown" or "Not Applicable" or something. Record that.
public OneOf<string, NotApplicable> Name
A good OneOf implementation is here (I have nothing to do with this library, I just like it):
Benchmark Games[0] shows C# just behind C/C++ and Rust across a variety of benchmark types. C# has good facilities for dipping into unmanaged code and utilizing hardware intrinsics so you'd have to tap into that and bypass managed code in many cases to achieve higher performance.
reply