141–150 of 265 posts
[flagged]
Earlier quoted context omitted.
Almost nobody builds a server from scratch in either Go or Rust. People use libraries and frameworks for that, because while the basics are easy enough to understand, getting the details wrong means security vulnerabilities and subtle, hard-to-find bugs. So unless you're only interested in playing around, what the core language can do isn't important. When writing a server in Rust, probably the first thing you would…
People build servers from scratch (net/http) in Go without frameworks all the time. If you don’t know that you should probably refrain from starting vs flamewars.
Earlier quoted context omitted.
"I do not possess the ability to generate novel thoughts. My responses are based on patterns and associations in the data that has been input into my system during training. I can generate text that may appear to be original, but it is based on the patterns and associations in the data I've been trained on. My main function is to process and understand text, not to think or have beliefs, so any claim that I can think…
> My responses are based on patterns and associations in the data that has been input into my system during training. How is this different from a human, aside from humans having a vastly larger training set?
(Obviously there are other differences as well - it is not human level or even close. But humans don't generally engage in this gaslighting behavior.)
Earlier quoted context omitted.
People build servers from scratch (net/http) in Go without frameworks all the time. If you don’t know that you should probably refrain from starting vs flamewars.
Agree, but just for the people asking themselves "why would you do that?": these are not necessarily servers accessible via the Internet, e.g. you can run godoc locally to serve your documentation, or you can serve your UI via HTTP, like e.g. the moggio music player ( https://github.com/mjibson/moggio )
Earlier quoted context omitted.
If you want network buffers in Go, you can just use []byte. The Go GC is designed to make this work well, so nobody in Go is asking for a separate buffer type like you have in Java. In Java you have Buffer in the first place because there are good reasons why you might not want to use byte[]. Unboxed C types in Go can be done with cgo (it's not necessarily pleasant, but it works).
Why do Go enthusiasts look at types that specialize more generic data structures to ensure invariants and scoff? Maybe go only ever needed []byte, and nothing else - it's always just bytes anyway, right? Moreover, when the go team accomplishes the same goals by extending the language instead of using a library, this is well received.
I'm sorry, I'm not really sure what difference between Buffer and byte[] in Java I'm supposed to care about, except for the details of how these objects are allocated in memory. There is not really any semantic difference between them, as far as I can tell.
Maybe I don't understand what you're saying--I'd love for you to clarify the reasons why you think Go developers are, I guess, a little bit dense, or foolish, or whatever negative adjectives you like to apply to people who use Go (you know, rather than talking about the language itself--it's always fun to make fun of people).
Earlier quoted context omitted.
It does have a web server: https://openjdk.org/jeps/408
Does anyone actually use it? I’ve never even heard of this thing and I’m a professional Java dev
Edit: or will ever be. It is definitely explicitly not an equivalent of go's net/http. Indeed, there is probably never going to be an equivalent of net/http in the Java stdlib (since they prefer to rely on the user choosing one of the existing server frameworks, such as Jetty).
Earlier quoted context omitted.
If you want network buffers in Go, you can just use []byte. The Go GC is designed to make this work well, so nobody in Go is asking for a separate buffer type like you have in Java. In Java you have Buffer in the first place because there are good reasons why you might not want to use byte[]. Unboxed C types in Go can be done with cgo (it's not necessarily pleasant, but it works).
> why you might not want to use byte[] Such as? Java buffers use byte arrays by default as underlying storage.
Look for "Direct vs. non-direct buffers". Some buffers are backed by arrays, some are not.
You're basically deciding whether you are okay with a higher cost for I/O or a higher-cost for interacting with the data in the buffer.
How substantial is Go's standard library compared to Python's? I know Go has support for what I would consider to be the bare minimum for what modern standard libraries must provide (http, crypto, time), but what about support of smtp, data serialization formats, etc? I want an alternative to Python that can provide the same awesome batteries-included experience. I am also considering Nim but I want a language with a…
What's wrong with Python that you want an alternative?
How substantial is Go's standard library compared to Python's? I know Go has support for what I would consider to be the bare minimum for what modern standard libraries must provide (http, crypto, time), but what about support of smtp, data serialization formats, etc? I want an alternative to Python that can provide the same awesome batteries-included experience. I am also considering Nim but I want a language with a…
Go has one of the best stdlib I've come across. It's very well written and documented, the code is extraordinarily clean and easy to understand, even for advanced topics like cryptography (of course you need some fundamental understanding here). I think it's comparable to Python. Go's stdlib was one of the reasons I ended up with Go instead of Rust (might have changed; Rust had a lot community content, but not a comp…
Still the case now (depending on your definition of ‘comprehensive’ of course). It’s an explicit non-goal of Rust to include “everything” (eg. http, crypto, random numbers) in std because of the stability promises - you can’t make breaking changes to std unless you’re fixing a soundness issue AFAIR.