Sure, I’ve used a variety of other languages (C#, Java, Swift, C, even Scheme etc) and like Go, and even chose it for a solo project.
To me it feels like C with some extra features, kind of like Objective-C. If you need to do some C-like things but can afford the small latency etc overhead introduced by Go, what Go provides (GC, large standard library, green threads, package management, etc) feels like absolute luxury compared to using C. C# is another GC language with the ability to go lower level, but the syntax can also be pretty verbose.
If you’re in the market for an ergo keyboard, I’ve used and liked the Kinesis Freestyle for years now. It’s a fully split keyboard with a staggered layout - I use it in a tented setup, and the ergonomics have been good while it’s similar enough to regular keyboards to not make switching back and forth too difficult.
I’ve tried the mechanical (red switch) version, but actually prefer their membrane version because it’s quieter and I like the tactile feedback better (I haven’t tried the brown/blue switch models though).
I’m not going to defend what random internet commenters may have said, but in my view the core team has been fairly consistent and their design decisions (to me) make sense.
The first thing to understand is that Go occupies a space lower level than Java but higher level than C. It includes things like explicit pointers and more control of memory layout.
Many of the design decisions make no sense without that context. Go can’t simply copy generics from Java or memory sharing from Erlang, since the design decisions made by those languages would introduce too much overhead in a language intended to be lower level. In a lower level language more aspects of how a program executes are specified explicitly, rather than accepting more overhead or guessing what a complex optimizer will do.
On generics, I think the team’s position has mostly been that it’s a big project and there’s been other priorities like rewriting the compiler in Go, improving the GC, etc. And that in the spectrum of trade-offs for generics systems they didn’t want to go all the way to Java or C++.
I feel like a lot of HN commenters compare Go to higher level languages and find it lacking, which may be a fair assessment for certain problems but isn’t really understanding the niche it tries to occupy.
> On generics, I think the team’s position has mostly been that it’s a big project and there’s been other priorities like rewriting the compiler in Go, improving the GC, etc. And that in the spectrum of trade-offs for generics systems they didn’t want to go all the way to Java or C++.
That was not the initial team position. Their initial position was "why would you even need generics? Please provide us a usecase". They actively denied there was a need for generics.
>Their initial position was "why would you even need generics? Please provide us a usecase"
Do you have a source for this? It doesn't match my recollection. As I recall, the Go team always said that they may add generics in the future, but also that they would also like to see compelling use cases for it. That is not an unreasonable request.
They have mentioned that you don't really need it as an explanation after they already said for a long time that they do consider it, from the start. They never strayed from that POV.
I think C# might be the closest mainstream language, but I’d say explicit pointers, interior pointers, and slices as the default list type might be things that make Go programming a little lower level.
There are also other differences that would prevent using C#’s system as is - Go doesn’t have the reference/value type dichotomy or inheritance. I think they also wanted to be able to abstract across float/doubles etc (unless C# added that recently).
Anyway I like both languages and I’m not trying claim one is better than the other, just trying to explain the design space Go seems to occupy.
> I'm not sure what the difference is with regards to pointers.
In C# most objects are 'class' objects, which are implicitly passed by pointer, although some are 'struct' objects passed by value. In Go rather than making the decision once at the type level, the decision to pass by value or pointer is made explicitly every time an object is used.
> I'm not sure that Go really had anything to figure out or invent
If you look at the discussions for Go (which started as early as 2009 [1]) [2] [3] [4] [5] generics seems as big or a bigger project as the other improvements made to the language over the last decade. My impression is there being a broad spectrum of potential trade-offs across compile speed, execution speed, convenience, etc.
The totality of the prior art here is above my pay grade, but I can quote the Haskell people they roped in [4]:
> We believe we are the first to formalise computation of instance sets and determination of whether they are finite. The bookkeeping required to formalise monomorphisation of instances and methods is not trivial ... While the method for monomorphisation described here is specialised to Go, we expect it to be of wider interest, since similar
issues arise for other languages and compilers such as C++, .Net, MLton, or Rust
I think C# occupies a fairly nice design spot also (and takes advantage of its class/struct system to get fast compiles but also performance when needed). But it's not like the C# design couldn't be improved on. As far as I know you still can't write math code that works across 32 and 64 bit floats. And array covariance is implemented in a way that isn't type-safe and relies on run-time checks and exceptions. [6]
It is not the same thing at all if you care to compare the details. C# pointers come with a long list of caveats which does not apply in Go. They feel like a bolted on escape hatch rather than a real part of the language.
We use go in an embedded Linux environment. I do C#for web stuff and it would never cross my mind to do c# in an armv7 Raspberry. Also what about cross compilation? The c# runtime is not easily available to use in embedded devices at least that i know of. With go you just set it to compile statically and set the arch target. I can deploy it as a single binary. Love it after years of maintaining cross tool chains.
Wow impressed indeed. Especially the esp targeting. Is there some intermediate compilation from c# to c or a compiler backend was created from scratch?
I think this is a red herring - compiling to native code is orthogonal to low-levelness. Haskell compiles to native code, but is exceedingly high-level. Forth is traditionally bytecoded, or threaded-coded, but is excruciatingly low-level.
Java was originally bytecoded, but at some point gained various ahead-of-time native compilers. Did it become lower level when that happened? It did not.
C# also supports AOT compilation. It's definitely not a low-level / high-level language differentiator. The term generally means the abstraction level you can reach.. I'd be tempted to define it as the distance to simple lambda-calculus in the lambda-cube
C# ahead-of-time compilation has for many years come with all sorts of caveats. Early versions requires runtime system because not everything got compiled on parts. Later versions have all sorts restrictions which do no apply for Go.
I think when C# and Java people compare with other languages they treat it as a checkbox exercise without caring about how good that feature actually is.
Oh, AOT compilation, great memories. How many year of CPU work and downtime it took from exchange servers, when you wait every update to “compile” for hours, just because it is awesome. Or when you getting laptop heating and you know - it is dotnet compiles and optimising something for you, another great update.
Yes, C# also supports ahead of time compatibility - it is portable for whole 20 years between windows computers. How cool is that?
Another advantage is speed - calculator or photo viewer only takes 1-3 seconds to open on 5 ghz 8 core cpu. Yet another advantage is size - only 3-5 gigabytes of different version libraries in your system and you are golden for a month (next you need to install preview updates, and then just updates and thats all you good, secure and protected by Windows Defender). In all these aspects C# is clearly superior language.
I agree, it seems like an editor based on direct AST manipulation could work pretty well with existing languages (I actually prototyped one a long time ago in university). Some languages like C with text-based preprocessors might cause some headaches but there are others that probably wouldn't be too bad.
There's pretty far you can go with text-based formats since you aren't obligated to display the file exactly as it's stored on disk (and many current IDEs do minor code folding things). For example embedded images can be displayed inline in the source code, but be stored as some loadImage() function on disk. You could even have some comments with base64 binary data if you really needed - at that point binary vs text is mostly a performance issue, but parsing is usually pretty fast so being text-based might still have an advantage because of better interoperability with source control etc.
> The second part looks to be more interesting: I’d like to see some arguments for why a LVT wouldn’t just be passed along to the renters like every other expense is currently.
I think the general idea goes something like: a new apartment can collect $10k/mo rent, and so after construction expenses a developer can pay say $5k/mo for the land. These numbers don't change with a LVT or not.
Without the LVT, the $5k/mo that they can afford translates to say a $500k mortgage, which roughly determines the land price (as multiple developers bid for the same land).
With a LVT, there's say a $2k/mo tax, so they only have $3k/mo to pay the mortgage, which translates to a $300k land price using the same logic.
So by working backwards in this simple thought experiment the LVT is just reducing the value of the land without changing much else about the housing market. Intuitively it also sounds reasonable that taxing land values might reduce land values as a result.
I'd be interested to see the upcoming detailed analysis though.
I agree that people have experiences, but I don't understand why they must be magical or non-existent in the physical world. Why can't the word "experience" simply be referring to the physical processes that happen when our mind/body is in some particular environment?
Certainly physically ingesting a small amount of certain psychedelic chemicals can have profound effects on subjective experience, so it can't be too disconnected from physical processes.
The whole issue of qualia / experiences seems like it is an extension of the dualist/materialist perspectives rather than something that sheds light on it one way or another - dualists will view qualia as something non-material and so something that materialism can't explain, and materialists will view qualia as something material along with consciousness itself.
There are a lot of levels of "thinking" across the animal / insect / even plant kingdoms. The simplest levels of stimulus response (like a venus fly trap closing its mouth) don't seem to require a metaphysical explanation. But insect behavior is more complex and mammal and human behavior even more so.
At which level do the existing rules of the material world start to seem less plausible to you than a second unseen world with different rules, that interacts with this one under specific circumstances (if that's what you mean by dualism)?
As we can presently see with computers and machine learning, pretty complex behavior is possible through systems that operate via known physical processes.
To add to adgjlsfhk1’s answer, if you are writing Android games you are probably using a cross-platform game engine that doesn’t use Java (like Unity) which solves the issue but more importantly also allows you to sell your game on iOS without a re-write.
For memory layout C# actually has an important difference in that it supports value types (so you can have an array of vertices without individually allocating each one, which has a lot of overhead and drastically reduces cache efficiency). They’ve been working on adding support for that to Java for some time but it’s not in yet.
The only advantage I can think of to having a single GC is with using 3rd party packages. If the trade off is always low latency and throughput then libraries know to target that when optimizing, otherwise it’s less clear what to benchmark with.
To me it feels like C with some extra features, kind of like Objective-C. If you need to do some C-like things but can afford the small latency etc overhead introduced by Go, what Go provides (GC, large standard library, green threads, package management, etc) feels like absolute luxury compared to using C. C# is another GC language with the ability to go lower level, but the syntax can also be pretty verbose.