101–110 of 121 posts
Earlier quoted context omitted.
Bach WTK prelude 1? It was the first real piece I ever learned so that's why it's there :)
I was thinking about Frère Jacques :)
this is a great opportunity to ask something I've been wondering about for awhile: what are the best options out there for hosting websites built as HTTP-serving executables (either Windows or Linux)? is it possible to do this relatively cheaply? I ask because I've been working on a framework[0] for building websites in a compiled language recently, and while it's been a ton of fun to build and test locally as a hobb…
This site has a good tutorial for this. It recommends vultr (which is what I use), for $2.50 - $5 a month. https://landchad.net/
this is a great opportunity to ask something I've been wondering about for awhile: what are the best options out there for hosting websites built as HTTP-serving executables (either Windows or Linux)? is it possible to do this relatively cheaply? I ask because I've been working on a framework[0] for building websites in a compiled language recently, and while it's been a ton of fun to build and test locally as a hobb…
Maybe look at container hosting with your (statically linked) binary being the only thing in the container? Otherwise, why not just get a cheap VPS and host the binary there? I’ve used Vultr and it’s $3.50/month all-in, at the low end. There are even cheaper providers, although I don’t know about their quality. I bet this option would be the cheapest. This is the beauty of a single binary—it’s trivial to deploy!
this is the question driving the framework I'm building—it even has support for simple HTML templates, but they're interpreted, type-checked against the structs that get passed into them, and baked into the executable, all at compile time. this is all coming off of building a website for a client using PHP for the first time in over a decade—on one hand, I appreciate the relative simplicity and ease of deployment compared to modern backend stacks, but on the other hand, it's still an interpreted language, with all the baggage associated with that. I believe it is possible to take the ease of use and speed of iteration of interpreted languages, and the benefits of strongly-typed compiled languages, and get the best of both worlds—at least, for the scale and complexity of website that I want to build and maintain.
Earlier quoted context omitted.
My recollection of the timeline is a bit different: 1. The current proposals for generics are bloated and don't fit properly with our vision for Go. 2. We will do heaps and heaps of work over many years until we get something we like. 3. Go has generics! Also, AFAIK Go is not a single-pass compiler, at least not in the way I learned about compilers.
> 1. The current proposals for generics are bloated and don't fit properly with our vision for Go. > 2. We will do heaps and heaps of work over many years until we get something we like. I suppose repeatedly suffering the pain of not having generics until you finally get enough of your community to admit generics aren't just bloat can be described as "heaps and heaps of work". ;) I'd love to hear what meaningful diff…
Go couldn't have Option before, and it cant have option now. Option is not only generic, but its also an Enum, which Go still doesn't have:
https://doc.rust-lang.org/std/option/enum.Option.html
so its not really clear what you mean by this.
Earlier quoted context omitted.
My recollection of the timeline is a bit different: 1. The current proposals for generics are bloated and don't fit properly with our vision for Go. 2. We will do heaps and heaps of work over many years until we get something we like. 3. Go has generics! Also, AFAIK Go is not a single-pass compiler, at least not in the way I learned about compilers.
> 1. The current proposals for generics are bloated and don't fit properly with our vision for Go. > 2. We will do heaps and heaps of work over many years until we get something we like. I suppose repeatedly suffering the pain of not having generics until you finally get enough of your community to admit generics aren't just bloat can be described as "heaps and heaps of work". ;) I'd love to hear what meaningful diff…
It’s not like we’ve seen some massive regression in compiler performance. Circumstances changed, and the Go developers changed their minds. What would you do?
Earlier quoted context omitted.
> 1. The current proposals for generics are bloated and don't fit properly with our vision for Go. > 2. We will do heaps and heaps of work over many years until we get something we like. I suppose repeatedly suffering the pain of not having generics until you finally get enough of your community to admit generics aren't just bloat can be described as "heaps and heaps of work". ;) I'd love to hear what meaningful diff…
> option types Go couldn't have Option before, and it cant have option now. Option is not only generic, but its also an Enum, which Go still doesn't have: https://doc.rust-lang.org/std/option/enum.Option.html so its not really clear what you mean by this.
Earlier quoted context omitted.
> 1. The current proposals for generics are bloated and don't fit properly with our vision for Go. > 2. We will do heaps and heaps of work over many years until we get something we like. I suppose repeatedly suffering the pain of not having generics until you finally get enough of your community to admit generics aren't just bloat can be described as "heaps and heaps of work". ;) I'd love to hear what meaningful diff…
Quoting 1984 when discussing the history of a programming language really detracts from any point you’re trying to make. It’s not like we’ve seen some massive regression in compiler performance. Circumstances changed, and the Go developers changed their minds. What would you do?
1. Yes, we didn't see a massive regression in compiler performance. Which begs the question why they didn't benchmark the options to see that might be the case.
2. Circumstances didn't change. The options for how to implement generics are roughly now what they were in 2009. What we need from languages in Go's sphere, is roughly the same as well.
3. What would I have done? a) Benchmark before making claims about speed. b) Assess features from other languages to see what works and what hasn't (literally nothing about the problems with lacking generics was unforseeable--I was talking about them early on and I'm not some sort of prophet). c) Admit rejecting generics was a mistake instead of pretending they were part of the plan all along.
Earlier quoted context omitted.
> 1. The current proposals for generics are bloated and don't fit properly with our vision for Go. > 2. We will do heaps and heaps of work over many years until we get something we like. I suppose repeatedly suffering the pain of not having generics until you finally get enough of your community to admit generics aren't just bloat can be described as "heaps and heaps of work". ;) I'd love to hear what meaningful diff…
> option types Go couldn't have Option before, and it cant have option now. Option is not only generic, but its also an Enum, which Go still doesn't have: https://doc.rust-lang.org/std/option/enum.Option.html so its not really clear what you mean by this.
Earlier quoted context omitted.
> 1. The current proposals for generics are bloated and don't fit properly with our vision for Go. > 2. We will do heaps and heaps of work over many years until we get something we like. I suppose repeatedly suffering the pain of not having generics until you finally get enough of your community to admit generics aren't just bloat can be described as "heaps and heaps of work". ;) I'd love to hear what meaningful diff…
Quoting 1984 when discussing the history of a programming language really detracts from any point you’re trying to make. It’s not like we’ve seen some massive regression in compiler performance. Circumstances changed, and the Go developers changed their minds. What would you do?
What circumstances changed, specifically?
Earlier quoted context omitted.
It can be simple, or it can be fast. Or it can be neither. But it can't be both. If you want fast web at all cost (and you need encryption), you get HTTP3/QUIC.
At the end of the day, the question is never one debating simplicity. If you consider the amount of complexity implemented just to even boot into an operating system to run these systems, the lack of simplicity is already a forgone conclusion. The crux of issue is going back to abstractions and my worry is specific to how our abstractions are getting larger and larger and doing more work at even level with very tight…
The IP model won over the OSI model due to lower number of larger layers.
I think it's a very reasonable question, but also the HTTP3/QUIC advantages do seem to offer advantages.