[HN Gopher] Microsoft rewrote Q# compiler in Rust
___________________________________________________________________
Microsoft rewrote Q# compiler in Rust
Author : avestura
Score : 59 points
Date : 2023-06-21 18:50 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| avestura wrote:
| It was previously written in C# and F#:
| https://github.com/microsoft/qsharp-compiler
| nwah1 wrote:
| Was there a write-up of what the goals of the rewrite were, and
| why they switched the language and made the new engineering
| decisions?
| bitwize wrote:
| I don't think any language sparks joy the way Rust does --
| not even Lisp and certainly not C# or F#. Rust gives the
| compiler lower memory overhead and attracts a broad base of
| developers.
| HumblyTossed wrote:
| I actually don't like Rust. It just doesn't fit me.
|
| To each their own, I suppose.
| tmtvl wrote:
| YMMV, of course, I have a hard enough time managing with
| one style of brackets, Rust has, what, five (round
| brackets, square brackets, curlies, angles, and vertical
| bars)? Never mind the fact that some operators are prefix:
| do_something(a_thing);
|
| Others are infix: x = a + b * c;
|
| And yet others are postfix:
| foo.frobnicate()?;
|
| My sole braincell can't handle all that complexity, which
| is why I'll just stick with simple old Lisp.
| antonvs wrote:
| > I don't think any language sparks joy...
|
| Let the Marie Kondofication of programming languages begin.
|
| But one of Kondo's points is that "Only you can know what
| kind of environment makes you happy," i.e. there are no
| universals.
| ohgodplsno wrote:
| Begin?
|
| The entire reason we have people trying to cram
| JavaScript everywhere is that, for some reason, it sparks
| joy for them.
|
| Hell, even going back, K&R vs Allman brace style was
| about what sparked joy. Color themes? Spark joy. At this
| point, I am convinced that the way to get a software
| developer to do anything is to just play on that need for
| joy.
| insanitybit wrote:
| > The entire reason we have people trying to cram
| JavaScript everywhere is that, for some reason, it sparks
| joy for them.
|
| Wait really? I feel like it's just "you literally have no
| choice for frontend" and the various side effects of
| that.
| ohgodplsno wrote:
| That would explain frontend, yes. But that would not
| explain NodeJS, JavaScript for embedded microcontrollers,
| and so many more.
|
| Some might say it's Stockholm syndrome, but then there's
| the Python developers doing the same thing everywhere.
| And the LISP enthusiasts. So unless there's a lot of
| Stockholm syndrome (although it's not out of the question
| when it comes to LISP), a lot of it is easily explained
| by "me like language here, me go put language elsewhere
| to keep language"
| comboy wrote:
| > I am convinced that the way to get a software developer
| to do anything is to just play on that need for joy.
|
| Works outside software development too.
| lionkor wrote:
| Whichever language one prefers sparks joy like Rust does
| for you
| miohtama wrote:
| While this is true on individual level, Rust has been
| ranked most liked programming language in many surveys
| and sparks joy to most of people more than other
| languages
|
| https://survey.stackoverflow.co/2023/#section-admired-
| and-de...
| antonvs wrote:
| What's missing from a survey like that is correlation
| with prior experience and education. Python was a
| previous winner on those kind of surveys, and it's a
| terrible language in many ways.
| IshKebab wrote:
| Yeah someone needs to do a ranked preference test. Rank
| all the languages you are familiar with...
| tmtvl wrote:
| Funnily enough I'm not very familiar with languages I
| don't like, probably because I elect not to use them.
| miohtama wrote:
| Where you are failing here is likely empathy, or
| understanding how other people work or think. This might
| be because lack of experience in programming, or just
| because of reflexive negativity. Even if you think Python
| is a terrible language, for many people it's the best
| language for the job. This also includes must PhDs,
| because Python is the most used languge in science and
| academia.
|
| When doing critical thinking, please set asides your own
| biases and try to understand that your own viewpoint is
| not always the correct one.
| patrec wrote:
| I think you are a bit detached from reality if you think
| controlling for experience and education would massively
| change the picture for python, which evidently enjoys
| above average popularity with anyone from junior devs to
| elite programmers (such as Google's Director of Research,
| geohot etc.).
| Dudester230602 wrote:
| While I admire it I most certainly do not desire it -
| like Haskell. I need to ship things, not figure out some
| borrow of a monad.
| systems wrote:
| Well Rust was written OCaml on which F# was based So i think
| this was probably for performance, not for any expressive
| reasons
|
| And personally i consider Rust to be from the OCaml/SML family
| of languages similar to F#, so i guess they moved within the
| family
| reocha wrote:
| If it isn't clear from this comment rust is no longer written
| in OCaml and is fully self hosted (as far as I know).
| klabb3 wrote:
| Correct. In this context it's perhaps also worth mentioning
| that Rust depends on LLVM.
| tialaramex wrote:
| Yes. Rust's compiler, rustc, is a bunch of Rust code that
| parses Rust syntax into an Abstract Syntax Tree to which
| it can apply macros, then this is lowered through two
| levels of intermediate representations, where more Rust
| code does the type inference and type checking and
| eventually borrow checking and various optimisations,
| until eventually it's lowered to LLVM Intermediate
| Representation LLVM IR, which LLVM will further optimise
| then produce machine code for the target architecture.
| reocha wrote:
| Impressive knowledge o7
| Dudester230602 wrote:
| What do Rust developers tend to do while the code is
| compiling? Vote 'Rust' in all the programming language
| surveys?
| Vecr wrote:
| You can kind of compile (a version of) Rust into C and
| then compile that as well, but I assume miscompiles are
| common and there's very little checking done. It's used
| to bootstrap the compiler for Debian.
| pjmlp wrote:
| I guess yet another minus for F# at Microsoft. Really funny how
| they manage it.
| progmetaldev wrote:
| Really puts me off learning it, other than dipping my toes in
| functional programming and being experienced in C# and the
| .NET Core/Framework libraries. I thought it may be easier to
| start with F# before moving to another functional language.
| Jenk wrote:
| The tooling (Visual Studio, LSPs, etc.) around F# is very
| lacklustre, I wish it had better support from MS. At the
| moment F# just seems to be a playground for experimenting
| with FP ideas that then get ported to C#.
|
| As for learning a functional language, I recommend this
| Haskell tutorial[0], and accompanying video series of an
| experienced haskeller (Brian McKenna) running through
| it[1]. I've read countless texts and tutorials explaining
| Haskell and FP to me but it didn't fully click until I saw
| someone with experience using the language and tooling
| effectively.
|
| [0]: https://github.com/system-f/fp-course [1]: https://www
| .youtube.com/playlist?list=PLly9WMAVMrayYo2c-1E_r...
|
| There are a few other video series from other experienced
| haskellers available that may be better, too, I just
| haven't watched them so I cannot comment.
| Dudester230602 wrote:
| I am ready to treat Q# same way as Microsoft is treating F#.
| FrustratedMonky wrote:
| So sad. Love F#, and Q# seemed like a natural extension, or at
| least brotherly.
|
| At a high level, it seemed like F# is more functional like OCaml,
| than Rust is. I'd like to hear more about the reasoning, was it
| just performance? How different was it to justify a re-write?
| hu3 wrote:
| > I'd like to hear more about the reasoning
|
| My guess is because Rust is great with WebAssembly and they
| seem to target it with Q#:
|
| https://github.com/microsoft/qsharp/tree/main/wasm
| FrustratedMonky wrote:
| Well, wasm runs slower right? I'm not that familiar. Seems
| that if wasm is a goal, then that might negate they did this
| for performance. What other benefit is there to wasm that
| would make it a fit for Q#?
| hu3 wrote:
| Slower than native perhaps. But usually faster than
| JavaScript on V8.
|
| So if you want fast browser perf, Wasm is a great choice.
|
| There's also Wasm on the edge with the likes of Cloudflare
| Workers and Vercel
| https://vercel.com/docs/concepts/functions/edge-
| functions/wa...
|
| It also has some interesting isolation properties.
| syrusakbary wrote:
| Shameless plug for WebAssembly on the Edge: Wasmer
| recently launched Wasmer Edge, which is Wasm-focused
| instead of JS-focused compared to Cloudflare Workers and
| Vercel
|
| https://wasmer.io/products/edge
| hu3 wrote:
| I respect the hustle. Sorry for not mentioning
| https://wasmer.io. Keep it up! Competition is great.
| billti wrote:
| Disclaimer: engineering manager for the team building it
|
| Yes, targeting WebAssembly, and the ability to then run in
| the browser, was a big part of it.
|
| WebAssembly (will) also enable our language service extension
| to run in VS Code for the Web, as well as VS Code for
| desktop, with largely the same feature set.
|
| It also means the core logic compiles to very performant
| native code for most platforms, which we use for the CLI.
|
| It's early days for the project, with lots of work ahead of
| us, but I'm really proud of this first step. Happy to answer
| any other questions where I can!
| gavinray wrote:
| But C# has the ability to compile to WASM and run in the
| browser, using the Mono WASM runtime that's part of the
| .NET core repo now.
|
| This is what underpins Blazor.
|
| https://github.com/dotnet/runtime/tree/main/src/mono/wasm
|
| Example C# app running in a browser:
|
| https://github.com/dotnet/runtime/blob/main/src/mono/sample
| /...
| FrustratedMonky wrote:
| Isn't one of the benefits of F# the ability to compile into
| other languages. I'd think it would be possible to have F#
| run on WebAssembly. But, guess I'm too focused on F#, this
| is really about Q# running on web assembly, so maybe
| writing Q# in F# and F# being able to generate web
| assembly, is too many layers? Added complication?
|
| So, am I hearing correctly, the goal was really about
| portability, and allowing Q# to run in a browser, not for
| any performance reasons of .NET.
| billti wrote:
| Portability, minimal size, and speed are all priorities.
| Building with Rust allowed us to really focus on all of
| these for both WebAssembly and OS binaries.
|
| For example, if you go to the playground that we publish
| on every push to main
| (https://microsoft.github.io/qsharp/), and open the
| Developer Tools to see the network traffic, you'll see
| that our WebAssembly module is just 1.5MB (504kb over the
| wire) - which includes the not just the language (parser,
| type system, IR, etc.) but also the runtime interpreter
| and quantum simulator.
|
| Similarly, for the native tools, on my MacBook (i.e.
| ARM64) the command line compiler ("./target/release/qsc")
| is 3.9MB, which is entirely standalone with no
| dependencies.
|
| We do have many features to add, so I'm sure those will
| grow a bit, but we are focused on keeping things as
| small, portable, and fast as a general principal.
| nightski wrote:
| Interesting and disappointing that someone from Microsoft
| would convey that .NET Core is too slow and not portable
| enough :) VS Code is Microsoft's tool after all.
| phillipcarter wrote:
| It's true though. I mean, not a knock on the .NET team.
| They (we in a past life!) have moved mountains to get a
| crusty old Windows desktop development framework into the
| modern era. But all this does is highlight that the work
| isn't done yet.
| ilc wrote:
| Maybe WASM is going to finally deliver the dream of the JVM,
| and CLR.
|
| Maybe.
| Zambyte wrote:
| But the language that the compiler is written in doesn't
| really relate to the target system (ie WASM). Unless they're
| planning in running the Q# compiler itself in a WASM
| environment. Which in that case... why?
| FrustratedMonky wrote:
| This got me thinking of switching from F# to Rust, so did search
| and found this article that was good comparison. Others thinking
| of F# and Rust might dig.
|
| https://jkone27-3876.medium.com/f-is-the-net-rust-62f71f8dae...
| adamnemecek wrote:
| Microsoft gets developer relations.
| Dudester230602 wrote:
| Keep nerds around by letting them re-write things for no good
| reason?
| zohvek wrote:
| https://www.youtube.com/watch?v=EMldOiiG1Ko&ab_channel=fb
|
| tldr: developers
| asylteltine wrote:
| Why not...just use rust then? I don't understand the point of all
| of these niche languages in real life. Python, Go, rust, c, cpp,
| js, C#, kotlin, but why use others? Each of these have clearly
| defined strengths and community support.
| hu3 wrote:
| While I understand your sentiment, Q# is specialized for
| Quantum Computing: https://en.wikipedia.org/wiki/Q_Sharp
|
| It's arguably different enough of a domain to justify a new
| language.
| Alupis wrote:
| This strikes me as a bold (probably marketing) claim more
| than anything. Looking at the example code, it seems to make
| use of many "quantum" libraries, but why could those libs not
| be made available to C# or whatever?
|
| Quantum computing is a niche, to say the least, and the field
| is far from clearly defined. This sounds a lot of IBM
| proclaiming RPG will be the best "big iron" language ever -
| and today nobody uses it.
| erk__ wrote:
| Programming languages for quantum computing needs to uphold
| some rules normal programs does not need to. The biggest is
| likely that no information may be destroyed when the
| program is run, from this follows that it needs to be
| reversible. This means that from any result you should be
| able to compute the input. Rules like these can be hard to
| uphold in normal languages (I have done it with a subset of
| rust in the past) so a specialized language is often used
| instead.
|
| There is probably more to it, but these are the parts I
| know a bit about.
| saraham wrote:
| I'm a compiler engineer on the Q# team - to add to what
| others have said, Q# is more than a set of quantum APIs,
| and the Q# compiler does quantum-specific checks and
| transformations on the AST representation of your program.
|
| To do the same thing in an existing language, you'd need a
| deeply embedded DSL so that the program can be manipulated
| by the Q# "compiler" before running it. It's possible, but
| it can get kind of clunky, where you have to use the
| "embedded" if statements, for loops, etc. instead of the
| ones from the host language. A new language helps with
| having a cleaner separation.
| ko27 wrote:
| The simple reason is that if you design your language with
| limitations of a quantum computing you can make certain
| guarantees about your program being able to physically
| execute on any quantum computer. You can find more details
| here:
|
| https://learn.microsoft.com/en-us/azure/quantum/overview-
| wha...
| [deleted]
___________________________________________________________________
(page generated 2023-06-21 23:02 UTC)