871–880 of 943 posts
Earlier quoted context omitted.
The compiler ensures you are writing memory safe code. Otherwise it rejects that code and helps you see the mistake you made. Why people are so upset when the compiler prevents them from building and shipping unusable code will always baffle me.
There is nothing automatic in that.
I notice this time and time again: projects start with a flexible scripting language and a promise that the performance will be sufficient. I mean, JS is pretty performant as scripting languages go and it is hard to think of any language runtimes that get more attention than the browser VMs. And generally, 90% of the things people do will run sufficiently fast in that VM. Yet projects inevitably get to the stage wher…
AI tooling is the new wave of Assembly => Compilers transition. It won't happen tomorrow, but I am quite certain eventually it will be in a position where executables are generated directly, and we will enter into a new computation model. Like you can nowadays still inspect the generated Assembly, and eventually fine tune it, our AI tools of the future might provide a similar approach.
Just like being familiar with assembly is extremely useful in certain circumstances (I spent a lot of time looking at assembly while working in the games industry. In fact, I was part of a small group that found a bug in the MS C++ compiler which we discovered by inspecting the output assembly) it will be extremely useful for programmers to be competent in the low level representations. At least for a good long while (probably years) we'll review almost all of the code generated before shipping it. But it won't be long until we just "trust" the output of the AI tooling.
And by "trust" I mean we will have engineering practices in place to validate the software before release. Unit testing, integration testing, functional testing, static analysis, etc.
At some point the volume of code generated by the AIs will be so much that it won't be practical to consider every single line of code. Just like the volume of assembly created by the C compiler is so much that for the most part we just assume it is fine. Only in special cases do we narrowly focus on a hot loop or some other part of the code.
This might happen slowly, over decades, or quickly over the next two years.
Earlier quoted context omitted.
> " So it's not just that the lead architect of C# is involved in the TypeScript changes. " Anders Hejlsberg hasn't been the lead architect of C# for like 13 years. Mads Torgersen is: https://dotnetcore.show/episode-104-c-sharp-with-mads-torger... - " I got hired by Microsoft 17 years ago to help work on C#. First, I worked with Anders Hejlsberg, who’s sort of the legendary creator and first lead designer of C#. And…
> Like these... Nope. None of those are even close to Ford + Chevy. (Ford + Mazda is well known of course). I chose the analogy carefully.
Earlier quoted context omitted.
A tiny thing that's not relevant to this particular piece of work but is worth having in background when thinking about Go is that while Go would like Python typically be described as "memory safe" unlike Java (or more remarkably, Rust) it is very possible for naive programmers to cause undefined behaviour in this language without realising it. Specifically if you race any non-trivial Go object (say, a hash table, or…
I'm confused what you ascribe to as undefined behaviour. What does that mean in the Go context? There is no mention of what UB is in Go at https://go.dev/ref/spec .
In terms of concrete examples, this might allow remote code execution, arbitrary reads or writes of memory that you otherwise don't have access to, stuff like that.
Earlier quoted context omitted.
> " So it's not just that the lead architect of C# is involved in the TypeScript changes. " Anders Hejlsberg hasn't been the lead architect of C# for like 13 years. Mads Torgersen is: https://dotnetcore.show/episode-104-c-sharp-with-mads-torger... - " I got hired by Microsoft 17 years ago to help work on C#. First, I worked with Anders Hejlsberg, who’s sort of the legendary creator and first lead designer of C#. And…
> "why aren't you using YOUR LANGUAGE, huh? What's the matter, you don't like YOUR LANGUAGE?" is pushy and weird It's also not what anyone said. > It's best not to use quotation marks to make it look like you're quoting someone when you're not. https://news.ycombinator.com/item?id=21643562 >
> "An indirect quote lets you capture or summarize what someone said or wrote without using their exact words. It helps to convey the tone or meaning of your source without quoting them directly." - https://www.grammarly.com/blog/punctuation-capitalization/qu...
I'm distilling and exaggerating multiple the comments to convey the tone and meaning of the bit I want to focus on. Asking "why not C#?" has the implicit framing "it should be C# by default and you have to justify why not" and calling out that bias to show it to be unreasonable is the intent.
I notice this time and time again: projects start with a flexible scripting language and a promise that the performance will be sufficient. I mean, JS is pretty performant as scripting languages go and it is hard to think of any language runtimes that get more attention than the browser VMs. And generally, 90% of the things people do will run sufficiently fast in that VM. Yet projects inevitably get to the stage wher…
Yes, I think the promises of the "we can JIT all the overhead away"-camp were always overblown, and never materialized in practice. This is another very strong datapoint for that hypothesis[1]. However, it is important not to conflate "scripting language" and "dynamic language" and "interpreted". While there is some correlation there, it is not a necessary one. Objective-C is an example of a fast AOT-compiled pretty…
> And I'd much rather debug/modify semantically rich, high-level code that my LLM generated.
This I agree with. In fact, we may find that the natural fit for use with LLMs is a language not popular amongst humans. The main issue, in my opinion, is we end up with native code executables, complete control over memory layout and direct access to system calls. Those properties just happen to align with languages like Rust, Go, Zig, C/C++, etc. but they aren't limited to them.
Earlier quoted context omitted.
I think they answered in their FAQ here: https://github.com/microsoft/typescript-go/discussions/455#d... . If I got it correctly, they created a node native module that allows synchronous communication on standard I/O between external processes. So, this node module will make possible the communication between the typescript compiler GO process, that will expose an “API server compiler”, and a client side JavaScript…
I really wonder how tough that is going to be to migrate to. I have API use that falls into a few categories, that aren' just LSP-ish type cases: - Transforms, which presumably there has to be some solution for, even if it's porting to Go. - Linters, which integrate with typescript-eslint and need the type-checker. - Codemods, which create and modify AST nodes and re-emit them. - Static analyzers, which build us app-…
1. “We expect to have a more curated API that is informed by critical use-cases (e.g. linting, transforms, resolution behavior, language service embedding, etc.).”
2. “We also can imagine opportunities to optimize, use other underlying IPC strategies, and provide batch-style APIs to minimize call overhead.”
Anyway, I’ve used the compiler API a lot too, and I really enjoy its huge capabilities, making possible practically everything on the source code (EDIT: and hijack the build process too). I hope we won’t miss too much.
Earlier quoted context omitted.
I think it's smart to start with a high level language which should reduce development time, prove the worth of the application, then switch to a lower level language later. What was that saying again? Premature optimisation is the root of all evil
I think a lot of people are running on facts that are between 10 to 25 years out of date. There was a time when the scripting languages had a very, very large step up in prototyping capability, because the static languages of the time were frankly terrible. But the static languages have changed, a lot, for the better since then. I now find that when I'm greenfielding something, if I have even a clue how I want to str…
And when you factor in LLMs being ridiculously good at scaffolding basic apps, the time to reach that turning point will continue to decrease. It takes me time to write out test harness boiler plate, or making a nice dev/staging environment configuration. It is why many languages come with a `mylang create proj` command line tool to automate a basic project. But the custom scaffolding that a LLM can provide will eventually beat any command line project creation tool we can imagine.
This is one of the driving realizations of my point. I've coded in a lot of dynamic languages and a lot of static languages and the distance between their developer experiences are shrinking drastically. I would expect a decent dynamic language expert to become productive in Go very quickly. Rust may be more difficult but again should be totally possible for any competent programmer. Then you add on top of that the fact they will be ramping up using an LLM that can explain the code they are looking at to them, that can provide suggestions on how to approach problems, that can actually write example code, etc.
And then there are all of the benefits of deploying statically compile binaries. Of managing memory layouts precisely. Of taking direct advantage of things like simd when appropriate.
Earlier quoted context omitted.
For example, look at the Techempower benchmarks. I benchmarked HTML rendering and Dotnet was 2-3x faster than Go using either Templ or html/template. Etc.
The c# benchmarks where they didn't use the framework to do any of the actual templating? those hardcoded byte arrays are how everyone does templating everywhere right? or are you talking about after they changed back their "platform" test to not do that and is substantially slower than go https://dusted.codes/how-fast-is-really-aspnet-core
The link your provided is severely outdated using data from Round 21 and .NET 6.
Earlier quoted context omitted.
I'm not here to predict the future, rather to reconsider old assumptions based on new evidence. Of course, LLMs may stay as "autocomplete" forever. Or for decades. But my intuition is telling me that in the next 2-3 years they are going to increase in capability, especially for coding, at a pace greater than the last 2 years. The evidence that I have (by actually using them) seems to point in that direction. I'm perf…
> Given LLM assistance, why wouldn't I write my web app layer in Rust or Zig? Same reasons as with no LLM assistance. You would be choosing higher maintenance burden and slower development speed compared to your competitors, though. They will get it out faster, they will have fewer issues, and will be able to find people to support it more easily. Your product may run faster, but theirs will work and be out faster.
I show up and say "I have a C compiler". Does it matter at that point how good your assembly is? All of a sudden I can generate 10x the amount of assembly that you generate. And you are probably aghast, what crappy assembly my C compiler generates.
Now ask yourself: how often do you look at generated assembly?
Compilers don't care about writing maintainable assembly. They are a tool to generate assembly in high volumes. History has shown that people who use C compilers were able to get products to market faster compared to people who wrote using assembly.
So lets assume, for the sake of understanding my position, that LLMs will be like the compiler. I give it some high-level English description of the code I want it to run and it generates a high volume of [programming language] as its output. My argument is, the programming language that it outputs is important and it would be better for it to output into a language that low level native binaries. In the same way I don't care about "maintainable assembly" coming out of a C compiler, I don't care about maintainable Python coming out of my LLM.