5 ms·

It's interesting how C# is always far ahead of Java, they introduced it way earlier, the syntax is simpler, and you can make is safe by using FormattableString

by ko27 4y ago

It's interesting how C# is always far ahead of Java, they introduced it way earlier, the syntax is simpler, and you can make is safe by using FormattableString as the param type, for example in EF you can do this without worrying about SQL injection: FromSql($"EXECUTE dbo.GetMostPopularBlogsForUser {user}") https://learn.microsoft.com/en-us/ef/core/querying/sql-queries#passing-parameters https://learn.microsoft.com/en-us/ef/core/querying/sql-queri...

deleted 4y ago
[deleted]
DaiPlusPlus 4y ago
A major shortcoming with FormattableString is that the C# compiler is hard-coded to always prefer implicitly converting an interpolated string to a string, which makes it impossible to write extension-methods for FormattsbleString objects. …and they also always default to formatting with CurrentCulture instead of InvarintCulture. Apparently this was by-design as interpolated strings were never originally intended for generating machine-readable strings. Finally, there’s no way to perform common “mini-templating” with a FormattableString, such as repeating regions, show/hide regions within a string, or little things like inflection (e.g. rendering “{0:N} items” or “{0:N0} item” when arg0 is 1 or not. I’m happy to see Java (finally) gain a similar feature, but it, like C#,s, seems… limited in its abilities.
- brewmarche 4y ago
  C# 10 introduced interpolated string handlers. They allow to address some of your points (you can handle format strings however you want and you could also choose invariant culture by default, without using FormattableString.InvariantCulture) and at the same time avoid allocations.
pjmlp 4y ago
Not always, e.g. default interface methods, just to give one example.
knightofmars 4y ago
There's a history that partially explains why this is. https://news.ycombinator.com/item?id=16353398 https://news.ycombinator.com/item?id=16353398
pie_flavor 4y ago
You-the-user can make C#'s safe, you-the-library-developer can make Java's safe. All you need is for one silly person to assign the C# query to a `var` beforehand and then the behavior's wrong. I'd usually be the first to point out how C# did it earlier and better, but in this case Java's manages to surpass even Rust's, which I didn't think was possible.
- jayd16 4y ago
  Can you not make an analyzer that raises an error if you try to pass anything but a literal-as-format string?
  - kaba0 4y ago
    At that point Java is completely null-safe. But sure, static analysis and tooling is a great advantage of bigger languages.
    - jayd16 4y ago
      Well, no, its not that simple for Java's nulls. But anyway, Roslyn Analyzers are built into the language. If you throw them away then you might as well call these new template processors off limits too.
- kuhsaft 4y ago
  > All you need is for one silly person to assign the C# query to a `var` beforehand and then the behavior's wrong. That would cause a compilation error. `DbSet<TEntity>.FromSql(FormattableString sql)` [0] does not have a string overload. Therefore, if a user assigned the interpolated string to a SQL query to a `var` beforehand, then there would be an implicit conversion to a `string` [1] which will be a type mismatch for the `FromSql` call. The user would have to assign the interpolated string to a `FormattableString` instead of `var` for the program to compile. There is also no implicit conversion for a `string` to a `FormattableString`. There is a `DbSet<TEntity>.FromSqlRaw(string sql, params object[] parameters)` [2] method that explicitly documents that it is vulnerable to SQL injection. > You-the-user can make C#'s safe, you-the-library-developer can make Java's safe. You-the-library-developer can make C# safe. [0] https://learn.microsoft.com/en-us/dotnet/api/microsoft.entityframeworkcore.relationalqueryableextensions.fromsql?view=efcore-7.0 https://learn.microsoft.com/en-us/dotnet/api/microsoft.entit... [1] https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/tokens/interpolated#implicit-conversions-and-how-to-specify-iformatprovider-implementation https://learn.microsoft.com/en-us/dotnet/csharp/language-ref... [2] https://learn.microsoft.com/en-us/dotnet/api/microsoft.entityframeworkcore.relationalqueryableextensions.fromsqlraw?view=efcore-7.0 https://learn.microsoft.com/en-us/dotnet/api/microsoft.entit...
pron 4y ago
Whether or not a hoarder is "ahead" of you at having stuff is a matter of perspective. C# strives to be a very feature-rich language, while Java strives to be minimalistic. So it's pretty certain that any feature Java does end up adding will have been in C# first (although this one is not quite the same), but Java certainly doesn't want to go in the same direction. On the other hand, Java's GCs, JIT compilers, and observability features are more sophisticated than .NET's. We like adding stuff to our runtime, while C# likes adding stuff to the language.
- ko27 4y ago
  The point is that Java eventually adds the same stuff as well just with worse usability than the C# counterpart.
  - pron 4y ago
    It doesn't eventually add the same stuff (even in this case, the feature is quite different from C#'s) as it will never add most of the stuff C# has because we want to keep Java as minimal as possible. But if your point is that Java usually only adds features that other languages already have, that is absolutely true and we'd like to keep it that way. We believe most programmers generally prefer languages with fewer features over languages with many features. As to it having worse usability, that's usually a matter of personal aesthetic preference, and there's no evidence to suggest that's the case by some objective metric.
    - ko27 4y ago
      I don't think that's working out so well for you, because developers disagree https://survey.stackoverflow.co/2022/#section-most-loved-dreaded-and-wanted-programming-scripting-and-markup-languages https://survey.stackoverflow.co/2022/#section-most-loved-dre...
      - pron 4y ago
        Could a diet people would say "works well" be determined by looking at the dishes people say they love most? Topping the list would be foods that are too unhealthy or too expensive, foods that most would agree wouldn’t "work well" as a sustainable diet. When you've followed such polls for many, many years, you see that programmers report they "love" languages that they pick more than those that are picked for them, that they tend to use for hobby more than work, that they tend to use in newer/greenfield projects, that they tend to use in smaller projects, and that they tend to use alone or in a small team. But the languages that end up working out well -- for the kinds of projects where Java is used -- are those that gain wide adoption in industry, that scale to large codebases and large teams, and yield programs that are maintained for many years. The languages that have managed to achieve that best are Java and C, and, to a lesser degree, C++. If you've lived through the BASIC and later VisualBasic craze of the eighties and nineties, the SmallTalk craze of roughly the same era, the Haskell craze in academia in the mid to late nineties, the PHP craze of the early oughts, and the Ruby craze of the mid oughts, you see that the most "loved" languages are rarely the ones that end up working well. Aside from a short ~5 year period (its first five years), Java was never a particularly "loved" language. Hell, James Gosling designed it to be a boring, conservative, "blue collar" language for work, and this work-in-teams-on-large-import-projects has been the main focus of Java's evolution. It's hard to argue that this hasn't worked out really well for Java. Even if Java isn't your cup of tea, you should appreciate the need for a language you can safely bet on to build a very important codebase that should be maintained for twenty years or more. Having said that, I believe we should work on making Java more suitable for smaller, more fun projects without giving up its scalability. That's a difficult challenge, and, as far as I know, no language has ever achieved it, but perhaps Python is a reasonable source of inspiration.

by ko27 4y ago

deleted 4y ago

[deleted]

DaiPlusPlus 4y ago

A major shortcoming with FormattableString is that the C# compiler is hard-coded to always prefer implicitly converting an interpolated string to a string, which makes it impossible to write extension-methods for FormattsbleString objects. …and they also always default to formatting with CurrentCulture instead of InvarintCulture. Apparently this was by-design as interpolated strings were never originally intended for generating machine-readable strings. Finally, there’s no way to perform common “mini-templating” with a FormattableString, such as repeating regions, show/hide regions within a string, or little things like inflection (e.g. rendering “{0:N} items” or “{0:N0} item” when arg0 is 1 or not. I’m happy to see Java (finally) gain a similar feature, but it, like C#,s, seems… limited in its abilities.

brewmarche 4y ago
C# 10 introduced interpolated string handlers. They allow to address some of your points (you can handle format strings however you want and you could also choose invariant culture by default, without using FormattableString.InvariantCulture) and at the same time avoid allocations.

pjmlp 4y ago

Not always, e.g. default interface methods, just to give one example.

knightofmars 4y ago

There's a history that partially explains why this is. https://news.ycombinator.com/item?id=16353398 https://news.ycombinator.com/item?id=16353398

pie_flavor 4y ago

You-the-user can make C#'s safe, you-the-library-developer can make Java's safe. All you need is for one silly person to assign the C# query to a `var` beforehand and then the behavior's wrong. I'd usually be the first to point out how C# did it earlier and better, but in this case Java's manages to surpass even Rust's, which I didn't think was possible.

jayd16 4y ago
Can you not make an analyzer that raises an error if you try to pass anything but a literal-as-format string?
- kaba0 4y ago
  At that point Java is completely null-safe. But sure, static analysis and tooling is a great advantage of bigger languages.
  - jayd16 4y ago
    Well, no, its not that simple for Java's nulls. But anyway, Roslyn Analyzers are built into the language. If you throw them away then you might as well call these new template processors off limits too.
kuhsaft 4y ago
> All you need is for one silly person to assign the C# query to a `var` beforehand and then the behavior's wrong. That would cause a compilation error. `DbSet<TEntity>.FromSql(FormattableString sql)` [0] does not have a string overload. Therefore, if a user assigned the interpolated string to a SQL query to a `var` beforehand, then there would be an implicit conversion to a `string` [1] which will be a type mismatch for the `FromSql` call. The user would have to assign the interpolated string to a `FormattableString` instead of `var` for the program to compile. There is also no implicit conversion for a `string` to a `FormattableString`. There is a `DbSet<TEntity>.FromSqlRaw(string sql, params object[] parameters)` [2] method that explicitly documents that it is vulnerable to SQL injection. > You-the-user can make C#'s safe, you-the-library-developer can make Java's safe. You-the-library-developer can make C# safe. [0] https://learn.microsoft.com/en-us/dotnet/api/microsoft.entityframeworkcore.relationalqueryableextensions.fromsql?view=efcore-7.0 https://learn.microsoft.com/en-us/dotnet/api/microsoft.entit... [1] https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/tokens/interpolated#implicit-conversions-and-how-to-specify-iformatprovider-implementation https://learn.microsoft.com/en-us/dotnet/csharp/language-ref... [2] https://learn.microsoft.com/en-us/dotnet/api/microsoft.entityframeworkcore.relationalqueryableextensions.fromsqlraw?view=efcore-7.0 https://learn.microsoft.com/en-us/dotnet/api/microsoft.entit...

pron 4y ago

Whether or not a hoarder is "ahead" of you at having stuff is a matter of perspective. C# strives to be a very feature-rich language, while Java strives to be minimalistic. So it's pretty certain that any feature Java does end up adding will have been in C# first (although this one is not quite the same), but Java certainly doesn't want to go in the same direction. On the other hand, Java's GCs, JIT compilers, and observability features are more sophisticated than .NET's. We like adding stuff to our runtime, while C# likes adding stuff to the language.

ko27 4y ago
The point is that Java eventually adds the same stuff as well just with worse usability than the C# counterpart.
- pron 4y ago
  It doesn't eventually add the same stuff (even in this case, the feature is quite different from C#'s) as it will never add most of the stuff C# has because we want to keep Java as minimal as possible. But if your point is that Java usually only adds features that other languages already have, that is absolutely true and we'd like to keep it that way. We believe most programmers generally prefer languages with fewer features over languages with many features. As to it having worse usability, that's usually a matter of personal aesthetic preference, and there's no evidence to suggest that's the case by some objective metric.
  - ko27 4y ago
    I don't think that's working out so well for you, because developers disagree https://survey.stackoverflow.co/2022/#section-most-loved-dreaded-and-wanted-programming-scripting-and-markup-languages https://survey.stackoverflow.co/2022/#section-most-loved-dre...
    - pron 4y ago
      Could a diet people would say "works well" be determined by looking at the dishes people say they love most? Topping the list would be foods that are too unhealthy or too expensive, foods that most would agree wouldn’t "work well" as a sustainable diet. When you've followed such polls for many, many years, you see that programmers report they "love" languages that they pick more than those that are picked for them, that they tend to use for hobby more than work, that they tend to use in newer/greenfield projects, that they tend to use in smaller projects, and that they tend to use alone or in a small team. But the languages that end up working out well -- for the kinds of projects where Java is used -- are those that gain wide adoption in industry, that scale to large codebases and large teams, and yield programs that are maintained for many years. The languages that have managed to achieve that best are Java and C, and, to a lesser degree, C++. If you've lived through the BASIC and later VisualBasic craze of the eighties and nineties, the SmallTalk craze of roughly the same era, the Haskell craze in academia in the mid to late nineties, the PHP craze of the early oughts, and the Ruby craze of the mid oughts, you see that the most "loved" languages are rarely the ones that end up working well. Aside from a short ~5 year period (its first five years), Java was never a particularly "loved" language. Hell, James Gosling designed it to be a boring, conservative, "blue collar" language for work, and this work-in-teams-on-large-import-projects has been the main focus of Java's evolution. It's hard to argue that this hasn't worked out really well for Java. Even if Java isn't your cup of tea, you should appreciate the need for a language you can safely bet on to build a very important codebase that should be maintained for twenty years or more. Having said that, I believe we should work on making Java more suitable for smaller, more fun projects without giving up its scalability. That's a difficult challenge, and, as far as I know, no language has ever achieved it, but perhaps Python is a reasonable source of inspiration.