Xledger | Mid/Senior Software Engineer | Colorado Springs, CO | ONSITE NO-VISA | 90K - 150K | https://xledger.com
Xledger is a cloud ERP system that gives customers better control of their businesses. We are expanding our team in Colorado Springs, and are looking for strong generalists to help us create best-in-class functionality for our customers.
If I type the name of an enum, then `.`, (and for my settings explicitly request autocomplete suggestions from VsCode), I either don't get anything, or I get a list of 50+ identifiers that have nothing to do with the enum. There seem to be a lot of cases like that where there is a very obvious context, but the suggestions are completely detached from that context. Stuff that works for any mainstream language like Java or TypeScript in just about every IDE or editor with a plugin.
KSON looks interesting. Where I work we did a metadata type project in Pkl recently, which is somewhat similar. Unfortunately, developments on the tooling front for Pkl have taken an extremely very long time. Not sure the the tooling/LSPs are anywhere close to what the language offers yet.
I like the language embedding feature in KSON - we would use that. Have you thought about having functions and variables? That is something you get in Pkl and Dhall which are useful.
Couldn't you just use static classes? I don't see how that would be a factor at all, seems like a very superficial reason that would be easy to work around.
Yea, I came here to say the same thing. Anders' reasons for not going with C# all seem either dubious or superficial and easily worked around.
First he mentions the no classes thing. It is hard to see how that would matter even for automated porting, because like you said, he could just use static classes, and even do a static using statement on the calling side.
Another one of his reasons was that Go was good at processing complex graphs, but it is hard to imagine how Go would be better at that than C#. What language feature that Go has, but C# does not supports that? I don't think anyone will be able to demonstrate one. This distinction makes sense for Go vs Rust, but not for Go vs C#.
As for the platform / AOT argument, I don't know as much about that, but I thought it was supposed to be possible now. If it isn't, it seems like it would be better for Microsoft to beef that up than to allow a vote of no confidence to be cast like this.
Norwegians are rich if you look at the average, but if you compare higher earners there vs the U.S. I would say they are actually poor. For example, take an above average software developer in the US and compare them to one in Norway - you will see a massive difference, especially in disposable income.
Not if he does the type of job hopping typical in silicon valley. There are plenty of programmers who only stay at a job ~2 years, and never have to maintain a program over a long period. You could imagine such a person saying 'this worked well at my last job' and just keep introducing that kind of pattern to new companies, eventually with '20 years of experience'.
I'd argue .NET isn't actually that great of a multi language platform. We have a mixed F# and C# solution at work, and that split sometimes causes a lot of friction. If you have some C# code that depends on F# code, that constrains your ability to have F# code depend on C# code. You need to be very careful about how you organize your work to get a good solution (more than on other platforms.)
In the JVM world, mixing languages works a lot better, because you can compile .class files instead of whole assemblies. So mixing clojure and Java, for example, is very easy to do in any order.
Saying there is an absence of evidence (of a leak) isn't useful by itself unless they also indicate whether that is evidence of absence (of a leak). I.e., they should indicate whether it is likely that they would have caught it if a leak had occured (e.g., via extensive logging).
> This doesn't make much sense. MSSQL does these already I think (except the first)
We tested all of these before taking the time to do the rewriting, and no, either they don't, or they way they did it isn't good enough. You can say I'm lying if you want, I'm not going to spend time arguing about it.
To check if rewrite rules are still helpful, yea - we just read release notes and test manually.
We've never had a rule change from being beneficial to detrimental. For most of them, I don't think that would be possible, because they just involve giving Sql less irrelevant things to chew on. For a few of them, like the manual scalar function inlining, I could see that being possible, so we will just need to keep checking.
For rewrite rule order, I guess we just do the ones that can enable other optimizations first. So far, that has been pretty simple to determine. For example, when we trim joins from inner queries, we first trim their selections (depending on what is actually used in the outer queries).
At my work, we often parse and rewrite a query before handing it off to SQL Server, because there are a lot of cases where Microsoft misses obvious optimizations. Sometimes there are also optimizations we can do because of things we know at compile time, but don't fit in the type system of SQL. The impact varies all the way from just shaving off 10% of the execution time, to changing some queries from timing out in a web request to executing in a few hundred milliseconds.
A few examples:
- Inlining scalar function calls (less impactful now with Sql Server 2019)
- Removing joins from a query when we know it won't impact the number of records
- Deepening where conditions against derived tables
- Killing "branches" of union queries when they can be determined to not matter statically
Yes, we could write the queries that way in the first place, but it would make them harder to compose, more verbose, and harder for the programmer to communicate intent. Not to mention, often the user can impact what the query will be, making it less feasible.
You think I'm saying "don't be different for any reason." What I'm actually saying is "don't be different without a good reason". Python for example has been criticized for the breaking changes in version 3, which caused a lot of problems for the community, arguably without a good reason.
> You may as well complain that the C guides didn't work in Java.
Java borrowed a lot of syntax from C, and it has been very successful. If Java had instead taken the powershell approach of needlessly deviating with the syntax, it probably would not have become as popular as it did. So that example supports the opposite of what you thought it does.
> It is a complete re-imagining of what a shell scripting language is. Hardly surprising that it isn't backwards compatible
By why does having richer return types necessarily mean you need to deviate from most other languages for the escape character (backtick in Powershell, but usually backslash)? That doesn't seem related, and it greatly impacts the initial impressions people get.
> The thing that disappoints me is that nobody from the *NIX world has tried to bring the same ideas there. They're good ideas.
I agree, and I hope someone does. But if they do, I hope they just focus on the ideas, and leave out the small and unimportant incompatibilities powershell decided to add.
Xledger is a cloud ERP system that gives customers better control of their businesses. We are expanding our team in Colorado Springs, and are looking for strong generalists to help us create best-in-class functionality for our customers.
Technology: .NET, SQL Server, Redis, Clojure, ClojureScript, ClojureDart, Postgres
You:
- Have a deep understanding of how the web works (HTTP, databases, caching, API's, etc)
- Have experience building and deploying several web applications
- Are comfortable with relational databases (we use SQL Server and PostgreSQL)
- BONUS: experience with Clojure
Our hiring process consists of a few video interviews and often a short (30 - 60 LOC) work sample submission.
Contact [email protected] with resume, and if available, links to some of your work (e.g., Github profile).
Note: No remote position or visa sponsorship available. Please don’t apply unless you know you can already legally work in the US.