> Windows support

WSL support maybe?

That's like recommending Office via Wine in 2001.

Not in the slightest. WSL is capable for most things.

Wine in 2001 was not usable

At that time I used it to play StarCraft and burn CDs with Nero Burning ROM, on Slackware. It was indeed usable!

The problem with wsl is that its a window like a small island extending 1000m into the air, and the moment you step off... Splat, you're back in Windows with the registry and such. I bought a surface a few weeks back - wsl is nothing but an improved cygwin, of no use to Linux/Mac users, and windows has become repulsively spammy. I've installed arch.

Can you use graphical applications with WSL?

While I don’t recommend WSL for serious production workloads, yes you can X11 forward applications from WSL and there’s a few implementations that are really good, all things considered.

If you install an X server for Windows, yes.

I've purchased X410 for this. Since then I haven't looked to see if there are free implementations of an X server that work nicely with WSL.

X servers pays along with WSL as well as with anything else. I've used Xming and VcXsrv with WSL without any problem specific to WSL.

As said elsewhere, I've had excellent X11 experience with WSL2 at least thanks to the open-source VcXsrv.

Bullshit, I played DeusEx a few months later just fine.

[Off Topic] Deus Ex had a profound effect on me growing up, and probably shaped my views which last to this day. Unfortunately, very few games like that are made nowadays.

Playing a specific game or 100 on it != a translation layer from one OS to another is ready or generally usable.

Games have minimal dependencies re OS APIs wise. Office apps and other programs make far more extensive use of OS facilities...

So hardly "bullshit".

> Games have minimal dependencies re OS APIs wise.

Sure, if you exclude "let's use every little quirk and undocumented feature in the graphics and audio and input stacks we can find because gotta go fast sanic noises".

Both games and office software (ab)use OS APIs; the difference is the specific subset of those APIs said programs (ab)use.

So yeah, you're right that it ain't "bullshit", but don't write off games as somehow "easy" compared to office programs; a substantial amount of effort has been poured into reimplementing Windows' multimedia stack in Wine and continues to be poured even now.

DirectX9 is not easy at all, it's almost Glide/Vulkan like low level-ish API. But hey. that's "bullshit". My balls. The above user should try running a pure DX9 game with Wine and GL 2.1 on a Intel Mobile 4 series with no noticeable frame drops. I tried. Hard.

But also, having DX7/8 being almost 100% compatible back in the day was a huge step on stability vs Windows 98, even if the RAM and CPU usage were higher. DX run fast, so did Max Payne.

It works great under WSL, but as others note, it needs first-class Windows support to really take off.

Wsl is good for webdev. Not something that you will use in production. And certainly not for other usecases like gamedev

That's not good enough.

Lots of the crop of new languages with cleaner designs have huge problems with windows. V doesn't work on windows and zig's compiler fails if you use carriage return newlines. They even built in an error message for it instead of just making the parser work. It's kind of ridiculous how these languages shoot themselves in the foot.

I think Zig is probably just being opinionated there; many of the new languages seem to be overly so. Last I checked, both the Zig and Nim compilers refused (on principle, not for any technical reason) to compile code containing tabs (among other things). I don't (usually) want my compiler to do linting, and I certainly don't want language authors to dictate my code style from on high.

Go is also annoying with its anal retentive source rules. I finally got so frustrated that I modified the compiler: https://github.com/kstenerud/go

Thank you for this. The passive-aggressive style of erroring on unused variable while staying absolutely silent when I accidentally print the &int variable with %d format, always seemed like an inconsistency to me.

It really is a sad state of affairs when disabling the linter requires patching the compiler. I wonder if any of the LLVM-based Go compilers will adopt a saner policy?

Making a compiler break with pretty much any file saved from a windows text editor is a very bold opinion, I can't say it would be my choice if I wanted to grow my user base.

What about Go? It seems like their approach is that if they define the style guide and build it into tooling, your code style (for Go) can only be the 'approved' style.

Or, put another way: People only have code styles because languages leave ambiguity. By removing that ambiguity you force your user-base to be consistent therefore increasing communication and productivity.

I tend to agree. It really grinds my gears when precious time is wasted on styling issues when there is no technical reason for either side. Granted it can be tough if you use three different languages with three different sets of rules.

Rust has grappled with the issue of how far to push styling rules. E.g. from 2016:

https://github.com/rust-lang/rfcs/pull/1607#issuecomment-227...

I think it's worth reading more of that thread for some pros and cons of being very strict with styling rules. Note that being too strict can lead to code being less readable in specific edge cases. This may or may not be considered a fair trade off.

To summarize the linked post (which I completely agree with), just provide officially recommended sane defaults and then get out of the user's way. In my view, that's how nearly all software ought to be written.

It's a fundamentally flawed approach in my opinion; viewing the users of a language as a single unified user base is a mistake. Various projects and groups will inevitably have vastly different use cases, and thus needs and considerations.

For example, I liberally mix C, C++, D, and occasionally other languages within a single code base on my personal projects. For sanity, I choose to observe my own consistent style across all languages when doing so. This obviously doesn't match common practice for any of the languages in question, but thankfully none of them attempt to impose the opinions of their designers on me.

I view languages being concerned with code formatting as a form of scope creep. A language should facilitate good code and communication by thoughtfully designing the syntax and providing useful constructs to the programmer. That's already an incredibly difficult problem - trying to tackle additional interpersonal or organizational issues is far too much, can't possibly accommodate everyone, and is bound to have unexpected negative consequences.

Put another way, core infrastructure should nearly always be as unopinionated as possible. Stick to as narrow a design goal as is reasonably possible and execute on it as well as possible. For a language, that means faithfully translating whatever I throw at it into machine code unless there is a legitimate technical barrier in the way of doing so.

> It really grinds my gears when precious time is wasted on styling issues when there is no technical reason for either side.

If this is happening it's indicative of an organizational or managerial problem. Any given project should have a clearly defined (and consistently enforced) code style, ranging from "use gofmt" to "follow PEP 8" to "adhere to our internal style guide".

> I don't (usually) want my compiler to do linting, and I certainly don't want language authors to dictate my code style from on high.

Enforced code style consistency has considerable advantages. "Linting" probably shouldn't be a thing.

Across a specific project, team, or org, sure. That's what style guides, formatters, linters, and pre-commit hooks are for. The core language is the wrong level of abstraction for this stuff.

Yeah, I still disagree. There's considerable value in being sure that you'll see the same code structure everywhere.

Presumably they're following python's example here.

Python works just fine with tabs, but the language-endorsed style guide (PEP 8) recommends against them. (However, the usual plugin for Vim requires adding "let g:python_recommended_style = 0" to work correctly.)

I must've misremembered, possibly what's disallowed is mixing tabs and spaces.

Well, good for them wanting to die on that hill.

They will remain dead..

"zig fmt" ostensibly cleans up carriage returns and tabs, for what it's worth.

Granted, I agree that it's silly that Zig's compiler can't just "do what I mean" and just accept that there will be tabs and carriage returns.

However, I'd say programming languages in general always seem to have trouble with Windows at first, in particular because Windows is pretty alien to those more accustomed to Unix-like environments (which, I reckon, is where most people making new programming languages are actually making said programming languages).

Crystal still doesn't have full Windows support, either, on that note (you can cross-compile a "Hello World" program, but there's a lot of pretty critical stuff missing).

Indeed, and if they do it via cygwin, MinGW, or even WSL, that is no way to win the hearts of Windows developers.

V has other, bigger issues :/

What are some? I wrote a small ascii snake game with it and found it generally OK.

It’s been somewhat overhyped by the author.

Can you give us examples where Alex "overhyped" the language? So far most of the promises he made have been fulfilled / currently work-in-progress.

I wrote a benchmark for V too and it’s fast but there are other issues internally and externally.

Have anyone know who is Alex?

He going to build compiler in AST, but as long as it’s useful for your works. It’s too early to tell whether it’s reliable for businesses, I’m more likely to trust Go as we know it’s battle tested.

It will definitely take more years to stabilise and promoting, other languages would have been mature and established.

V have first-class Windows support, what is your problem?

My problem is that it doesn't actually work on windows. Get the latest build, run it with no arguments, get a large error instead of the REPL.

What is "latest build"? V does not release any stable build and you can get "large error" on any platform right now when trying random "latest build" without any effort to investigate the issue.

The landing page has big links for executables for Mac, Linux and Windows - the windows build is completely broken.

Does anyone actually care about Windows support?

The StackOverflow 2019 survey suggests 47% of developers are on Windows (https://insights.stackoverflow.com/survey/2019#technology-_-...). This is a big chunk of developers you can't reach well, if you are limited to Linux and/or macOS. Windows devs might desire to have Crystal because they want to build native apps, but the reality is many people use the OS for other reasons that are beyond their control.

I don't find it surprising to see this question in a discussion involving a language related to Ruby. It's a bit sad it still comes up, but there is overwhelming demand for better Windows support of this and any other good or promising software running on Linux or macOS.

Historically, Python has had reasonable Windows support. It got to a point where it was OK and stopped improving. In recent years there has been more attention and improvements. This investment has meant that the language is reasonably viable for a lot of tasks on Windows. This doesn't mean that there hasn't been an influx of folks at points with little knowledge or care for Windows, but lots of packages work reasonably well.

Ruby is a different story. Rails was the big growth driver and there was a narrow focus. The pattern emerged of dev on macOS and deployment on Linux. I personally credit the tropes about only seeing Macs at dev conferences in a big way to Rails. The result is that it's infeasible to use Windows directly and you are best to go with a VM, or now WSL 2.0. It didn't have to be this way when a big chunk of developers are Windows. Rails could have taken an even bigger chunk of the market if Ruby had better Windows support.

Strategically, Crystal and other languages that want real adoption and the things that go with that (more recognition, more libraries, more real world use, more contributors, etc.) need to work out a good plan for Windows support.

I have had a huge amount of issues trying to use both Ruby and Rust on Windows for server / client use cases. It's not just that it "works" on Windows, but that it works easily out of the box for common use cases.

Meanwhile Python and Golang work great on Windows with no extra effort. It's like night and day.

What issues did you have with Rust? I use Rust on Windows every day.

It's been a while, but it was the common issue with certs that Ruby on Windows also has. I just couldn't get it sorted for whatever reason. Maybe it's not an issue anymore though? Rust http client works OOTB on Windows?

I have not had any cert issues, but I also have a pretty normal network. Maybe it’s better now!

Well, I guess devs on Windows do.

Windows support means less friction for people who wants to try it out.

You are aware that Windows thoroughly dominates the Desktop computing space right?

Sure but from a developer's perspective I've never found it compelling

So therefore it must not be to anyone else right?

Is this some kind of variation on Works for Me(tm)?

A lot of us who actually use Crystal do. Its still the most asked for feature in the language

I never thought there would come a time when I would want windows-support. However, the case is, that Windows as it is today, is quite inevitable. Hence if you want Crystal, you probably want Windows support.

That was the biggest problem for anyone jumping on to Ruby Rails in regions that has little to Zero Mac market shares and all Windows PC. With WSL2 this was (?) solved, but that is assuming everyone is on Windows 10 and latest version.

This has been hurting RoR adoption for long, although at this point it probably no longer matters.

Yes. Although I'd rather use Linux, most company IT will distribute windows computers and will not give you a Linux laptop. That means a lot of your work will be done on Windows.