-IDE support from MS is markedly better on Windows (real Visual Studio) and Mac (VS for Mac). VS Code+Omnisharp is still pretty rough around the edges for C#.
-Many of the older .NET class libraries were just not designed with *nix in mind. System.IO still doesn't support symlinks https://github.com/dotnet/corefx/issues/26310
Windows supports symlinks, so that problem is not unique to netcore on nix. Many of the newer APIs are designed with explicit support for nix.
Isn’t someone pushing .Net by definition a .Net person?
Have you ever had a problem with .Net Core on Linux that you couldn't find an answer to?
- OmniSharp just plain doesn't work on NixOS, because it hardcodes a bunch of Ubuntu paths.
- It seems to support automatically switching between multiple SDK versions, but I've never been able to get that to work.
We aren't using SQL Server, but I've used most of the big RDBMS and SQL Server is the best. It just tends to be more expensive.
So far it has been anything but a "pain".
Because sql server is a fantastic product that has basically no real equivalent on the market.
And funnily enough, I always feel that .Net core primary platform was Linux and not windows. Same for visual studio code, and I wouldn't be surprised if in a few years, new sql server features won't appear first on the Linux version. And actually it's somewhat the case with sql server big data cluster.
NuGet constantly fails silently when trying to restore packages.
Visual Studio is an editor built primarily around a folder tree, with no competent way to navigate that tree without constantly losing your place. It's also the only IDE that I have used where I just had to give up trying to find the application logs.
> Because sql server is a fantastic product that has basically no real equivalent on the market.
MSSQL's utter incompetence makes MySQL's `utf8` troubles look like small potatoes. For example: the `uniqueidentifier` type doesn't have a defined endianness, meaning that there is no guarantee that two languages reading the same cell will produce the same UUID string.
SSMS is an unusable hog. There is just no nice way to put it.
SQLCMD must have been designed by people who have never actually used a CLI.
I'm actually curious about this one:
>SSMS is an unusable hog. There is just no nice way to put it.
I've been using both postgre and sql server for like 1.5 year and tooling difference between pgAdmin and SSMS is insane
SSMS is mature, reliable and makes my life easier meanwhile pgAdmin is just viable, but nothing more.
Generally SQL Server seems to be years ahead in compare to postgre when it comes to features/tooling.
I also used mysql via xamp and sql management in compare to all of those is world class
>NuGet constantly fails silently when trying to restore packages.
what?
Not really. Just try keeping a .NET/MSSQL environment running for a few days, and the stories will build up quickly.
> SSMS is mature, reliable and makes my life easier meanwhile pgAdmin is just viable, but nothing more.
But psql is good enough that I pretty much never have to touch pgAdmin. And for ad-hoc editing (the only case where graphical editors have any real advantage), surprise, SSMS can't edit the results of custom queries. pgAdmin doesn't care, as long as the query contains the primary key.
And there is also a lot of polish that SSMS just doesn't have. Like how it forgets the order of your tabs as soon as they overflow. Or how you can't just do an ad-hoc query and see the result, you need to open a new query "document".
>> NuGet constantly fails silently when trying to restore packages.
> what?
That was my reaction too. Sometimes it decides that it won't build at all because it complains about unresolved references. Sometimes it builds but assets will be missing. And of course it's an opaque black box in the usual MS fashion, so there is no way to force it to retry, or to find out why it's not cooperating.
Also pgAdmin has no(?) Intellisense.
Export to SQL with pg_dump[0], or export to CSV with COPY[1] or \copy[2].
> Also pgAdmin has no(?) Intellisense.
Press ctrl+space for auto-complete. It also seems to pop up when you press `.` (in a valid place).
psql follows the more typical convention of auto-completing on tab.
[0]: https://www.postgresql.org/docs/12/app-pgdump.html
[1]: https://www.postgresql.org/docs/current/sql-copy.html
[2]: https://www.postgresql.org/docs/current/app-psql.html#APP-PS...
I'm using dotnet's CLI mostly for migrations/publishing
...huh? SSMS (plus the free Red Gate SQL Search addin) is hands-down the best DB tooling I've ever used. If you're aware of similarly full-featured equivalents for Postgres (or any other RDBMS), I'd love to hear about them.
I have tried DataGrip briefly with Postgres – my first impression was that it's a competent tool for things that are generic across all RDBMSs, but limited in RDBMS-specific management/administration functionality. Not far off from what you said :)
If you have time, what about DataGrip do you find to be "a lot nicer than SSMS"? Which features should I (a DataGrip noob) try using?
First of all Start writing queries and see how much it will help you, for the most it will autocomplete lots of things, once you are used to joins been auto written for you, hard to go back!
personal preference, but, it supports vim bindings.
Its table editor works on partial queries for updates, so you can select something and as long as you selected the key, you can do a update using the table editor. Speaking of the table editor, it is vastly superior and allows batching of changes, it shows you queries its going to do, has lots of helpers for all sorts of things including datetimes. It has lots of options to capture the table in lots of formats. It also allows across database comparisons of tables and synchronization or generation of sql scripts of differences/database changes.
Its ide is standard jetbrains ide ish and has lots editing goodness, refactoring, auto generation, surrounds, templates, local change history, lots of navigation tools ( go to references / usages etc )
What are some of these tools besides VSCode, and what makes them 'the best'?
> Because sql server is a fantastic product that has basically no real equivalent on the market.
What makes SQL Server so much better than, say, PostgreSQL or MariaDB?
> And funnily enough, I always feel that .Net core primary platform was Linux and not windows.
Why?
Tooling and speed. I can vouch for the quality of SQL Server's tooling – SSMS is very nicely integrated with SQL Server.
If you watch the CMU DB Group's lectures on YouTube, they mention that the commercial RDBMSs have put a lot more time+research into query optimization than the open source ones (and apparently SQL Server has the best optimizer).
That's too vague to be of any use. What tooling? What benchmarks?
> I can vouch for the quality of SQL Server's tooling – SSMS is very nicely integrated with SQL Server.
The fact that you like SSMS doesn't really say anything about tooling for PostgreSQL. I find the quality of PostgreSQL tooling great.
There is certainly plenty of reason to believe PostgreSQL is superior to MS SQL [1]. I don't agree with everything in the referenced article, but your claim of MS SQL being far superior is, so far, completely unsubstantiated.
As I’m sure you’re aware, publishing benchmarks of commercial RDBMSs is usually prohibited - I’m just passing on what I’ve heard from an expert about query optimizers.
Interpreting the questioning of your grand claims as combative should tell you something about your own attitude.
> As I’m sure you’re aware, publishing benchmarks of commercial RDBMSs is usually prohibited
I only know that MS and Oracle prohibit publishing such benchmarks - and that's yet another reason not to use them.
Tooling
Miguel de Icaza would probably have an issue with that statement.
.Net Core is fantastic, C# is a great language, I don't see any downsides with our stack.
There's two decades of answers and examples out there, many of which don't work. Not to mention many third party libraries that do stuff that's now in the box.
Biggest gripe to me, is lack of in the box support for PEM files in the crypto library. There are others, Core 3 breaks DI for logging in the Startup is another big one.
In the end, it's decent... I'd still largely rather use Node, or if I need more performance Rust of even Go. I will say I don't hate it, it's just frustrating finding examples and answers.
You pick your poison.