3 ms·
WRT CoreRT... It -is- a bit of a shame, yes. But 'not productized' isn't quite the same as non functional. Streets of Rage 4 actually uses it for some environm
by 737maxtw 6y ago
WRT CoreRT...
It -is- a bit of a shame, yes. But 'not productized' isn't quite the same as non functional. Streets of Rage 4 actually uses it for some environments.
The problem is that it seems Microsoft more wanted CoreRT as a research/testbed project for UWP compilation. The community is still trying to get Microsoft to productive it.
> When I google "c# web server", the first thing that pops up is a tutorial for how to write your own from the ground up with sockets. When I do the same thing with Go, I get a practical tutorial for how to use the standard library web server to build an interactive wiki application.
Not that it's a great defense but I checked, and you are right about the first link. the second link, while still a little deeper than one may like, hopefully is enough to realize that ASP.NET is the library to use and puts you just a click or two away from the proper tutorials. I.e. I'm not sure we should be dinging a language based on SEO.
- coder543 6y ago> I.e. I'm not sure we should be dinging a language based on SEO. I completely agree that one google search is not enough to ding a language. I’m trying to indirectly make a larger point there, which is that of approachability, especially for people who haven’t been doing all of this for forever. I didn’t want to make that comment significantly longer than it already was, so I’ll expand on that idea in this comment. > the second link, while still a little deeper than one may like, hopefully is enough to realize that ASP.NET is the library to use and puts you just a click or two away from the proper tutorials. The second link (for me, at least) appears to be a blog post comparing Kestrel vs HTTP.sys within ASP.NET Core, which wouldn’t be very enlightening to someone who isn’t already familiar with the term “ASP.NET” and how that is basically the standard .NET web framework. Literally none of the links on the first page for that ill-fated (and arguably slightly wrong) search query, as far as I can tell, are a tutorial that involves serving a web page without writing your own socket code. From experience trying to help a friend transition from Python to C#, a lot of tutorials I expected to find either weren’t at the right level for a beginner, were way out of date, or didn’t exist at all. With how rapidly C# and the surrounding tooling and frameworks have been evolving over the last 5 to 10 years (.NET Framework to .NET Core, ASP.NET 4 to ASP.NET Core, etc.), my experience is that there’s a lot of so called “inside baseball” in the C# world, partially due to how out of date a lot of the materials that Google is likely to surface are. I’ve used C# enough over the years that I don’t think I would have much of a problem finding what I needed if I chose C# for a project, but the language itself has a large amount of complexity, and developers have to make a lot of choices. They have to first figure out .NET Framework versus .NET Core, then they need to figure out that ASP.NET is the very intuitively named web framework that most people use. Also, do I need HTTP.sys or Kestrel? I really don’t know without doing some research, but luckily there’s an article diving right into that topic on link #2 on Google. To give an even more concrete example, the official ASP.NET tutorial on creating a Web API[0] involves a ton of autogenerated code that is either generated through clicking around all over Visual Studio, or running a bunch of `dotnet` commands on the command line. All of that autogenerated code is brushed over as if the reader must already be an expert in the world of C# but has just somehow never used ASP.NET before. (That seems like an unlikely combination to me.) Even if you’re used to other statically typed languages, you see this exciting code[1]: // POST: api/TodoItems [HttpPost] public async Task<ActionResult<TodoItem>> PostTodoItem(TodoItem todoItem) { _context.TodoItems.Add(todoItem); await _context.SaveChangesAsync(); //return CreatedAtAction("GetTodoItem", new { id = todoItem.Id }, todoItem); return CreatedAtAction(nameof(GetTodoItem), new { id = todoItem.Id }, todoItem); } First of all, what is a Task? What is an ActionResult? Where did `_context` come from and why does it start with an underscore? The tutorial literally does not even attempt to address the magical appearance of `_context`, or its ability to hold TodoItems. Ok, thinking for just a second, I remember we added a database context, but how would I know it’s going to be called `_context`? Registering our TodoContext object also felt super magical. We just had to “know” to put it in ConfigureServices, and does it matter that the tutorial puts it before `services.AddControllers`? Does the `//POST: api/TodoItems` line actually control anything, or is it just documentation for us? Why do we want to “Replace the return statement in the PostTodoItem to use the nameof operator” anyways? The code seems to do the same thing either way. (I know most of the answers, but these are the questions I would expect someone else to ask as a beginner being confronted with this tutorial.) I think approachability is not currently where I would want it to be with C#. Compare that tutorial to this Go tutorial.[2] It walks the reader gently through the entire process with only an assumption that the reader has some programming experience, a little knowledge of HTML and HTTP, and the know-how to run a few commands on the command line. The tutorial explains most of the Go-specific stuff you encounter, and it iteratively builds up the project code from scratch, rather than just telling you to “insert a line here in this autogenerated file”, and “swap this one random piece of an already functional piece of code with another piece of code that yields exactly the same result.” Go “includes the batteries” with its standard library that gives you easy defaults for many things, and the standard library docs often give you great examples for many situations. Goroutines make it so that you just write normal synchronous code, but it still scales extremely well. Tutorials are plentiful, and rarely feel out of date. There are no magically-appearing, unexplained variables like `_context`, and there isn’t a ton of scaffolding that you just have to figure out. All of this makes Go feel like a very approachable language to me. Is approachability super important to everyone? No, and that’s fine. There are lots of C# developers out there already, and there are lots of people who will figure it all out on their own anyways. I want to point out that I really do like C# and .NET Core. I would personally much rather use C# than Java, although I tend to think Kotlin is better than either of those. The last time I used C#, it had really great developer tooling, and it really did get a lot of things right. I think I would also prefer to use use C# with ASP.NET Core rather than Ruby on Rails or most Python frameworks these days. I’ve just had a lot of great experiences with Go (and Rust too!) in professional projects over the last several years, and those experiences make it hard for me to want to reach for anything else these days, C# included. [0]: https://docs.microsoft.com/en-us/aspnet/core/tutorials/first-web-api?view=aspnetcore-3.1&tabs=visual-studio https://docs.microsoft.com/en-us/aspnet/core/tutorials/first... [1]: https://docs.microsoft.com/en-us/aspnet/core/tutorials/first-web-api?view=aspnetcore-3.1&tabs=visual-studio#examine-the-posttodoitem-create-method https://docs.microsoft.com/en-us/aspnet/core/tutorials/first... [2]: https://golang.org/doc/articles/wiki/ https://golang.org/doc/articles/wiki/
- zeroc8 6y agoSame here. C# is a great language and has great features, but Go just feels lightweight and easy to handle. That said, for the type of software I do mostly nowadays (Microservices, APIs, Angular Frontends), the main contenders are NestJS and Deno. Typescript all the way.