I think if you want to compete with Rust, C or Zig you want to have a rich standard library. I still hold that Go's success is attributed to the fact that you could build a web application out of the box, minus database drivers. The templating and web server is purely built in to Go itself.
I don't have to waste time evaluating web frameworks I can just start coding a website with net/http right away. Oh its production ready!? Amazing!
I do wish Go had more things built-in like email and other protocols.
If I were maintaining or creating a systems language, I'd invest in the standard library being powerful out of the box. I really secretly wish Rust / D had a web server baked in sometimes.
All things said, this is the first I've heard of Hare, and it looks nice to me from what little I've looked at.
> If we use Rust as an example, it's super easy to include high quality libraries (just add s line in Cargo.toml and you're good to go).
Assuming a web server—Which library? Which version? How many commits does it have? When was the last one? How long will it be supported? Is it async? How many deps will it pull in? Will it be superseded by a fork? Does that fork have a different API? Will I have to bump the Rust version to match it in the future? Ok, I've gone to another team and their app uses a completely different library, what's the answer to all those questions again? Etc.
With Go, the answer is and always has been:
include "net/http"
I love Rust, but its DIY libraries can be quite a barrier to overcome when starting a project.
I'm not quite ready to announce it yet, but I'm working on a site that will provide a curated guide to the Rust ecosystem. There are packages that are well supported and de facto standards, you just need to know which ones they are (in this case the answer is "axum").
In the future the answer may be go to <SITE-URL>, look up the HTTP server category and either read through a few one-line descriptions or just use the recommended package.
That is great, and as someone just starting to dabble with Rust I'd love a resource like that.
But: no matter how well-curated your site is, and no matter how quality those libraries are, and how well maintained, "batteries-included, in the stdlib, backed by a compatibility promise that the dev team is willing to uphold" carries some serious weight.
It does, but it's not without its downsides either. stdlib modules might end up being abandoned or deprecated because the design can't be changed and it doesn't work well anymore or there are unfixable security issues. Python's stdlib has plenty of such modules for example.
Considering that the Rust dev team is mostly volunteers, and many of the most important non-std-lib libraries in the Rust ecosystem are maintained by those same people I feel like there's less of a distinction than there is made out to be.
If you email hn@my-hn-username.com then I will be happy to notify you. Otherwise I'll probably submit it here and on /r/rust. Whether it makes the front page, who knows.
signs that things might not be that easy, i'd say that the answer is rather "actix-web". axum has tokio's momentum, but a much shorter track record than actix.
So "web servers" is a particularly competitive category and there are number of options that are all solid choices. For most categories I have 1 or 2 options with 1 recommended. For web servers I have 6: axum, actix-web, warp, rocket, tide, and poem. With a couple of sentences for each explaining why you might or might not want to choose that option.
For me Axum should be the default recommendation because it's the least quirky option. It's also a very thin layer on top of hyper, and built by the tokio team, both of which have a very long track record.
Actix-web is a fine choice, but it's a bit of an odd duck in things like not being based on hyper, which makes it a little harder to integrate with the rest of the ecosystem.
thanks, i appreciate the detailed response. I do believe, though, that "least quirky", while definitively important, is not the most deciding factor here.
Axum is very young (was announced <1y ago), it has good momentum, is based on hyper and built by the tokio team. On the other hand, it has few actual projects built with it, I couldn't find a guide for it like actix or even Rocket have (it has some documentation in its docsrs documentation, but it is pretty minimal). Crucial questions like how to handle configuration, integration with database, autoreload, are left to the examples at best.
I have no doubt that these things will come if the framework matures. I'm just questioning if it should be the default choice right now, as opposed to in a year.
(Btw, I would absolutely recommend against Rocket right now, even though API wise it clicked the best with me, until it gets more maintainers and development resumes)
That's definitely a fair point on the documentation for actix-web being better (and rocket, but I agree with you on Rocket's maintenance status being problematic). Once I've got my site into a launchable state, my intention is to open up contributions on the github repo so that we can capture the wisdom of the community from all it's diverse set of perspectives. I definitely don't have all the answers myself.
A curated list doesn't have to be "The Best(tm)" in every choice. It just has to recommend one of the top 3 for every choice and never recommend something that sucks.
The issue with Go is that "net/http" is rife enough with footguns that for example Cloudflare has en entire blog post on how to handle timeouts. The defaults will cause production issues.
I’m mostly an infrastructure guy. I mostly fix C or identify bugs, and write integrations in Go or Python.
But I spend probably 50% of my time dealing with production problems due to this in Java business applications.
Nearly every client library in the Spring ecosystem has the worst of all possible defaults, and all internet code examples are “look at how easy X is” without anything around making it real.
Devs chuck code out without HTTP connection pooling or pipelining requests, let alone reasonable timeouts. Hikari has an awful default DB pooling config, and on and on. Inevitably it gets reported as “latency” when a quick look at [APM tool] shows all the time is spent waiting on a connection, or a stack trace shows which library chucked the timeout.
And often devs just bump connection pools higher when they see a bottleneck and there’ll be 1000 idle connections wasting DB resources and not helping the problem (inefficient query, missing index, etc).
I complain because the defaults here are masochistic. But there does need to be a cultural change where using a client or server library assumes a tuning exercise. And yeah, good testing would be great too.
There are no 1-size-fits-all values. You have to look at the use case and the SLOs of the app and it’s up and downstream dependencies. You don’t want optimizing a config in isolation to break a larger system either.
Software development is hard. It requires understanding. No language or library can solve that for this stuff. I just wish all of these libraries’ docs called that out up front vs projecting plug and play. It’s all there, but buried in the godoc for you to have to know what you’re looking for. Others are worse.
This is especially the case with http libraries, since it’s usually building a client or server object/whatever correctly and not just a config tweak you can slap in at 2am.
And back to the original point, when there are 12 implementations that can mean having to relearn this activity for each one. That said, if I’m using Go, that usually means building something with net/http and handing it to the library to use instead of the default. Other languages without that base layer baked in don’t get that advantage.
Back to Java/Spring: usually Catalina vs netty/Reactor Core are 2 totally different worlds and often dev teams don’t know which they picked or that they switched when they generated a new project and pulled their code in from Spring Boot 1.5 to 2.x.
When you code go by sticking to the standard lib like that, that the friction of updating becomes as smooth as compiling with the new version and deploying. Really quite sweet.
You -CAN- go the route of using a well supported, well maintained library but I have seen some code rot on larger projects in the go code ecosystem for stuff that tried to include more batteries.
I'm on the opposite side here, the slim standard library is something I enjoy with Rust. I can pick and choose from a multitude of different libraries with different trade-offs, strong suits and so on without being locked to one single implementation. I don't know what the guarantees for the standard library for Go is, but Rust's is very strict, you better be damn sure the design once something goes into `std` is near perfect and thought through, there are already mistakes, deprecations and design mistakes in Rust's standard library that will forever be there. Similar to how Python has both `urllib` and `urllib2`, and others like it, I'm of the opinion that a big standard library is where good libraries go to die once the stability guarantees come into play; though being able to do so much when scripting with Python is certainly a boon.
> I attribute Go's success purely by it being pushed by Google.
At the beginning Google's support really made a difference, but the continued traction of Go is really the result of it being a great tool to build network servers where you want a high level of performance.
> [...] being a great tool to build network servers where you want a high level of performance.
This was the case from the Day 1. Google strongly shaped the language's direction and that has a continuing effect on Go's success. Put it differently, if somehow we end up with the future without servers Go will have a very hard time.
Had the Kubernetes team not rewritten it from Java into Go, it would had surely been a different outcome, specially taken into account the Mesos ecosystem originally.
I think "high level of performance" encompasses a wider range of performance levels than you're thinking.
Go will be more than fine for the vast majority of servers people need to build. Sure, there are some things where Go might not fit the bill, but that doesn't really matter; Go is still super relevant for writing servers, just as Java (another GC'd language that some people call "slow") is too.
I completely agree, but the "high speed" claims by go enthusiasts are really tiresome, because the language is not particularly faster then any other that's compiled and has GC.
There are very few languages which are categorically slower then Golang, and these are generally languages which explicitly accepted slow executions for ergonomic reasons such as ruby and python
> If you actually needed performance you couldn't use a garbage collected language.
This is incorrect; HFT platforms have been written in Java for example (https://news.ycombinator.com/item?id=24895395). But it's about either tweaking GC settings or mode, or avoiding using the heap entirely if you can.
Go is still slow if you (over)use the heap, but at least it gives you the choice and plenty of tooling to analyze it.
No. There's one that made noise about it, but I personally know more than one other from working on their code. Not going to name anyone because I'm not sure they want their tech decisions publicized.
Also some performance-sensitive chunks of wall street itself (depending on how you define "wall street itself". And "performance sensitive" (what I worked on was more "high throughput" than "no pauses".).) run on java.
TBF, I write a lot of java, so my perspective is probably biased, but I can assure you, it's out there.
Many companies did this in the past. Nowadays Java, Go, etc GCed languages are still used but not for the hot path anymore. They are a couple million times slower than what we need.
Compared to Python, Ruby and Javascript, Golang is high performance. Compared to C, C++ or assembly language, you sacrifice ergonomics for a bit more performance.
GC is actually a hard requirement for some problem domains such as anything making heavy use of general graphs. (One well-known example of that is GOFAI applications, which are commonly implemented in LISP.)
> GC is actually a hard requirement for some problem domains such as anything making heavy use of general graphs.
This is manifestly false. I used to write general graph analysis kernels on supercomputers. We used (old-style) C++ and never had an issue with memory management. Your assertion is assuming a naive implementation that would have offered poor performance regardless.
There is no implication that memory is not being reused. You seem to be assuming how graphs are represented in large-scale systems which are not actually correct in practice.
> I attribute Go's success purely by it being pushed by Google.
I would say that having Ken Thompson and Rob Pike's names attached was far more significant than Google. More than that, though, it was successful because it solved problems people had at the time. The solution space is much larger today, but at the time Go was quite unique in filling its niche.
It probably helped, but it is not at all the reason why it got that traction
For comparison see Dart which was pushed even more by Google (I still remember when we were being inundated by "dart is soon gonna replace javascript everywhere" posts/videos) and now has not even remotely the userbase of Go and it's just a niche language for its specific framework Flutter
> it's super easy to include high quality libraries
Which add +100 dependencies, many of them 0.x and constantly changing. I remember updates where I clicked through the docs of three different crates to decipher cryptic compiler errors. And don't get me started on getting started with Rust - Go is much easier to learn.
Dart is also a Google conceived language but it’s not exactly what I’d call popular despite only hearing positive things about the language itself.
Unlike Swift or Kotlin that are heavily entwined with the main mobile platforms, nobody needs to use Golang for any particular reason. As far as I can tell its developer experience is pretty good so people have opted for it because it fits their needs.
This is a good example of why a big name doesn't guarantee adoption. Look at failed Microsoft development stacks too, and hell JavaFX had potential but I have seen zero effort from Oracle in terms of UI libraries. It's a shame, if Java could produce a serious UI solution I would of crawled back long ago. I can only hope Maui runs on Linux eventually.
Agree about Go and Google. With Google at your back, the question changes to how could you possibly fail? Not to say it's impossible, but is to say it's quite hard to do.
I don't agree. Go being created by the Bell Labs legends, the same people who fathered C, Unix, UTF-8, Plan 9, etc., was what caught attention. Google's involvement was downplayed, and, in fact, at the time Google people were all like "We don't use Go or even like it."
I don't totally disagree with your point. Ken Thompson is a legend, by himself. However, neither he nor the other creators made their own language, without backing. We will likely never know if by themselves, the Go creators would of had a hit. Even when it comes to talking about a legend like Ken Thompson, he still was working at Bell Labs (AT&T), and had that huge company behind his work.
Go was created at Google, and prominent among the language's goals, is that it serves their purposes.
Connected to that, it's easier for Google (in tandem with YouTube) to destroy or inhibit competing programming languages as well. Quite easy for them to depress views, spread or emphasize misinformation, etc... The power of Google to influence how people see things, is not something to be underestimated, even for what might seem minor or beneath them to do.
Recently I've been writing a good amount of rust, looking for libs to help out, and have been pleasantly surprised at the depth of the Rust standard library at this point!
I started trying to use something like tokio for async stuff, but found that Rust's standard lib threading primitives were already nice and numerous enough to get a lot of work done.
The rust programming language book has a nice little project of building a multithreaded HTTP web server from scratch. Of course you don't necessarily want to do this for everything, but the fact that a lot of the primitives are present and with good abstractions is commendable!
Go's stdlib stuff for web servers is obviously much easier to get rolling though.
That's amazing! I have the Rust Book but never finished it all the way through, I'm definitely looking forward to this, I had no idea it takes full advantage of other packages.
It does not (well, historically it does not, I haven't checked it out in a while) use other packages. You build one yourself with the standard library. It's expressly about learning via a bigger project, not something you'd use in production. That'd be a waste, just use axum, and focus on writing your application, not on building a (very minimal and incomplete) http/1.1 implementation.
That's fine, it's the kind of project I've been meaning to do for myself, so wherever it leaves off at... chances are high I'll continue for my own personal learning.
Go has other things. Fast compile times. I can ship a binary, in place of Python, which requires a Python environment with all the modules I need, or a container, what have you.
I can't speak for Rust or Zig, but for C I don't think this is true. If anything it's the opposite -- the C community is constantly writing replacements and enhancements to the standard library. C lacks good support for modules, but has excellent support for libraries installed on the OS level.
The ability to have all the bells and whistles out of the box may be a lot of the appeal of Go, and is certainly a lot of the appeal of languages like Python. But it's not core to the ethos of C.
Go's standard library is quite far beyond C and C++ in terms of features. Neither C nor C++ as far as I know have a JSON parser, CSV parser, language parser (Go for Go, but C for C, C++ for C++), web server, crypto libraries, and so on.
Though C++ and Java both probably have more container/algorithm libraries builtin than Go does.
> Neither C nor C++ as far as I know have a JSON parser, CSV parser, language parser (Go for Go, but C for C, C++ for C++), web server, crypto libraries, and so on.
people already complain constantly that the C and C++ standard libraries are bloated though
Who has complained that the C standard library is bloated?
In C++ the standard library has several entire features that are regrettable and so just take up space (e.g. regex, yes regular expressions are useful, no the standard library implementation isn't what you want), as well as places where they kept thinking of new better ideas and now there's a trail of old busted stuff you shouldn't use in new projects.
So of course people are going to say that's bloated, it is.
I think that Hare has a pretty rich standard library, though balanced with a constrained scope which prevents it from growing without bound. Note, though, that web programming is not really a domain that Hare is designed for, so we're not too concerned about being able to pick it up and write a website with it.
Personally, I find it hard to appreciate the stdlib when every identifier is optimized to use the least amount of characters. There's a module called `shlex` (what does that mean?), there are two types called `pwent` and `grent`, a type (can't find it again) has a size field called `sz`. Various types have single letter fields. There's a `chown` function under `os` and another one under `fs`. The "interface" for streams is defined by the very generically named type `vtable`. There's also a dedicated module just for creating a temp directory? There are dedicated modules for `linux` and `unix`, but then various os level types are defined in a catch-all module called `rt`.
Also, no data structures? I don't see maps, arrays, sets. No support for custom allocators (where's the `mem` module)?
The roadman mentions TLS, smtp, sql and http (no json?) but you're not too concerned with people wanting to use it for web development?
Many of these names come from Unix, and we chose not to make an opinionated renaming of something that most C programmers are already familiar with. Regarding rt - read the docs, it's a low-level module which is not meant to be used by most users.
Arrays and slices are built into the language, sets and maps are not. Much like C, though slices are new to Hare.
Similarly, chown. Or is your complaint that there are two different chown calls?
Trying to rename these things would make the library a lot harder to understand. Can you imagine if someone decided to call the USA "Samland" because they thought the three-letter identifier was too short? Would that reduce confusion?
I kind of agree about vtable, though.
Arrays are part of the base language, not a module. Not sure about sets and maps.
I really appreciate that Hare already has high-quality documentation (in terms of tutorials, language reference, standard library, etc.), which you usually don't get to see in other work-in-progress languages.
Problem with that approach is best demonstrated with Python.
Standard library usually comes with strong backwards compatibility guarantees. So it becomes ossified over time. Leading to - standard lib is where libraries go to die.
Without stability guarantee, you risk introducing breaking changes between versions, which is worse. And inferior to just downloading a lib with most stars.
1. Include as much as possible. This has been Python's approach and is showing its limitation: you end up with lots of historical baggages you can't maintain. It took an eon to remove some dead batteries from the Python standard library [1].
2. Exclude as much as possible. This is the preferred approach for most newer languages, which can't readily determine at which direction the language would be heading. These languages tend to weigh more on third-party libraries with their pros and cons.
3. Pick use cases and design the standard library only for those use cases. It would mean that you have a near-total control over the language's evolution, so you can include whatever you want without thinking about its long-term consequence (because you know a new addition would be necessary for your use case). This can be often seen from some smaller languages, but Go is in my opinion the only mainstream language using this approach and that's only possible due to Google's involvement.
Then why is C# or F# not more popular? Microsoft ships a huge array of first party supported packages that include low level protocol libraries.
I have yet to work at a Silicon Valley startup that used C# or F# though, despite it being a pretty solid choice in terms of "one language to rule them all" kind of thing like Kotlin / Java and (to maybe a lesser extent?) JavaScript.
I respect the tools and the language Microsoft has put out there, I'm not saying its objectively better or worse.
Especially F#, which is, to interject my opinion, an incredibly productive language on the same level as Go, and you get access to the rich .NET ecosystem out of the box.
To give a slight clarification (though I ask the exact same question every Who's hiring thread time of the month) I think "not more popular in the startup bubble" is more accurate.
As far as I'm aware Java and C# are still first/second by job listings in both the US and UK but in significantly less sexy enterprise settings. This might have changed since python became more widespread though.
> I think if you want to compete with Rust, C or Zig you want to have a rich standard library. I still hold that Go's success is attributed to the fact that you could build a web application out of the box, minus database drivers. The templating and web server is purely built in to Go itself.
Rust doesn't seem to have that rich of a standard library, bunch of the official documentation asks you to add crates for lots of things. I find myself reaching for external crates for tons of things I'd expect to be in the language as well.
I also don't think Go's success can be attributed to one single thing, but probably the biggest attribute would be that they are backed by one of the biggest tech company in the world, who have adopted it wholesale and would do so, no matter what, since they built and control it.
> I still hold that Go's success is attributed to the fact that you could build a web application out of the box, minus database drivers.
May, partly, sure...
I attribute Go's success due to the simplicity of the language. All successful languages tend to have one thing in common - they are extremely easy to read.
It also has some really unique meta aspects to it which are the appeal for me.
Forget about needing to decide on a web server library because there isn't one in the standard library. With C++ you have to decide which parts of the language itself you're going to use. Trying to learn is incredibly intimidating, because you look up how to do something simple and there's 17 unique answers with a million opinions on which is best, and which will lead you into a nightmare of unmaintainable code.
Go was built on the principle of being incredibly picky regarding what features are added to it. It's best assumed that any new feature that's proposed to be added will never be added, and until it goes through a heavy pitching process and gets hard-earned approval, it won't be there because the language has worked well enough without it up to now.
Having the formatting forced into the source code is genius too. Whether or not I agree with the prettiness of every formatting decision, I'm just happy it's there, because it's less decisions I have to make, and no matter whose code I'm reading, I know it'll be formatted in the same way as everyone else's.
I think there must be more to it than that. Rather, I'm sure it's necessary but I'm not sure it's sufficient. C# has all of that built-in, and actually even more, but I don't see that it's enough by itself to become broadly popular for web development.
Someone said Go isn't really a programing language so much as a DSL for writing web services. I think they meant it as an insult to Go, but I actually think it's Go's big strength. That plus having native concurrency explains a lot of Go's success. Being backed by Google doesn't hurt either.
I don't have to waste time evaluating web frameworks I can just start coding a website with net/http right away. Oh its production ready!? Amazing!
I do wish Go had more things built-in like email and other protocols.
If I were maintaining or creating a systems language, I'd invest in the standard library being powerful out of the box. I really secretly wish Rust / D had a web server baked in sometimes.
All things said, this is the first I've heard of Hare, and it looks nice to me from what little I've looked at.