'Why I Prefer Go Over Python or Java' (yourbasic.org) 230
Stefan Nilsson, a computer science professor at the KTH Royal Institute of Technology, recently explained "why I prefer Go to Java or Python," arguing that Go "makes it much easier for me to write good code."
Go is a minimalist language, and that's (mostly) a blessing. The formal Go language specification is only 50 pages, has plenty of examples, and is fairly easy to read. A skilled programmer could probably learn Go from the specification alone. The core language consists of a few simple, orthogonal features that can be combined in a relatively small number of ways. This makes it easier to learn the language, and to read and write programs. When you add new features to a language, the complexity doesn't just add up, it often multiplies: language features can interact in many ways. This is a significant problem -- language complexity affects all developers (not just the ones writing the spec and implementing the compiler).
Here are some core Go features:
- The built-in frameworks for testing and profiling are small and easy to learn, but still fully functional. There are plenty of third-party add-ons, but chances are you won't need them.
- It's possible to debug and profile an optimized binary running in production through an HTTP server.
- Go has automatically generated documentation with testable examples. Once again, the interface is minimal, and there is very little to learn.
- Go is strongly and statically typed with no implicit conversions, but the syntactic overhead is still surprisingly small. This is achieved by simple type inference in assignments together with untyped numeric constants. This gives Go stronger type safety than Java (which has implicit conversions), but the code reads more like Python (which has untyped variables).
- Programs are constructed from packages that offer clear code separation and allow efficient management of dependencies. The package mechanism is perhaps the single most well-designed feature of the language, and certainly one of the most overlooked.
- Structurally typed interfaces provide runtime polymorphism through dynamic dispatch.
- Concurrency is an integral part of Go, supported by goroutines, channels and the select statement.
The professor points out that the Java® Language Specification is 750 pages, and blames much of its complexity on feature creep (for example, inner classes, generics, and enum). And he also applauds the strict compatibility guarantees of Go 1 for the core language and standard packages, as well as its open source, BSD-style license, and Go's code transparency.
"There is one standard code format, automatically generated by the fmt tool," he writes, arguing that "Your project is doomed if you can't read and understand your code."
Here are some core Go features:
- The built-in frameworks for testing and profiling are small and easy to learn, but still fully functional. There are plenty of third-party add-ons, but chances are you won't need them.
- It's possible to debug and profile an optimized binary running in production through an HTTP server.
- Go has automatically generated documentation with testable examples. Once again, the interface is minimal, and there is very little to learn.
- Go is strongly and statically typed with no implicit conversions, but the syntactic overhead is still surprisingly small. This is achieved by simple type inference in assignments together with untyped numeric constants. This gives Go stronger type safety than Java (which has implicit conversions), but the code reads more like Python (which has untyped variables).
- Programs are constructed from packages that offer clear code separation and allow efficient management of dependencies. The package mechanism is perhaps the single most well-designed feature of the language, and certainly one of the most overlooked.
- Structurally typed interfaces provide runtime polymorphism through dynamic dispatch.
- Concurrency is an integral part of Go, supported by goroutines, channels and the select statement.
The professor points out that the Java® Language Specification is 750 pages, and blames much of its complexity on feature creep (for example, inner classes, generics, and enum). And he also applauds the strict compatibility guarantees of Go 1 for the core language and standard packages, as well as its open source, BSD-style license, and Go's code transparency.
"There is one standard code format, automatically generated by the fmt tool," he writes, arguing that "Your project is doomed if you can't read and understand your code."
Go over (Score:3)
Why I prefer go over python or java (Score:5, Insightful)
- no crap whitespace delimiters like in python
- no crap JVM like in java
- none of this 'com.java.sun.fuck.off.with.my.library' interface importing
- no 'i learned this in AI boot camp' crap like you see with some python devs during interviews
- java has such an overhead when it comes to building.
- if you're lucky you can get a python interpreter for your version that is fast, by probably not using the python executable included with your distribution
- feature creep of java, oh my god, every year a new set of features i don't have to use but some damn kid will probably try to introduce and say 'we should update to java 11 since this feature i just learned about isn't supported in our production java 8 environment'
- 'just install the dependencies on production' for some shit python library they installed and think is great, along with about 200 other modules, none of which is reviewed or even that performant
Quite frankly #1 above is the only reason I shy away from python. I like good clean code, but not at the expense of doing a quick copy/paste of an experiment without having to fix any fscking formatting just to get the damn thing to execute.
Node.js seems to hit the sweet spot for quick prototyping but go produces fast binaries for the 'performance required' microservices that require node.js to scale with additional servers. Plus you don't have to deal with JS programmers, who think their code is somehow readable since they learned using jquery and think the whole world knows that crap.
Re:Why I prefer go over python or java (Score:5, Interesting)
Go still makes the mistake of doing away with semicolon statement terminators for the sake of "cleanness". It's nice to be able to write a statement over multiple lines IMHO. Go is far too prescriptive with coding style.
Re:Why I prefer go over python or java (Score:5, Interesting)
Go very easily supports splitting a statement across lines; the spec is very clear about when an implicit semicolon is or is not inserted by the lexer.
Unfortunately, this usually means a binary operator is at the end of the line, rather than the start of the next, which makes it a bit harder for a human reading the code to spot that operator.
umlats (Score:4, Interesting)
When someone says "the spec is very clear" they mean there are archane language rules like when to use an Umlat that no one can either remember or even remember if they remember if it's been a year since they last used the language.
Re: (Score:2)
Maybe you would mean that. I mean that the spec is very clear [golang.org] about when semicolons are implicitly added or not. Those rules are also mostly common-sense: for example, a semicolon is implicitly added after ) or ] or } or ++, but not after ( or [ or { or +.
Comment removed (Score:5, Interesting)
Re: (Score:2)
Go does not have a ternary operator, so it would generate even more errors than you probably expected, but yes. It's one of the most unfortunate choices in the language design.
Re: (Score:2)
Re: (Score:2)
It's a necessary evil. Putting the operator at the beginning of a line is the only way to allow adding/removing items without changing extra lines of source code for additions/removals, assuming it's a true infix operator (you can't just end every line with the operator).
(Yes, strictly speaking, the above isn't true, if you end the operation with an identity, like "item1 + \n item2 + \n 0", but most people don't write code that way, and not every operation has an identity.)
Re: (Score:3)
>Unfortunately, this usually means a binary operator is at the end of the line, rather than the start of the next, which makes it a bit harder for a human reading the code to spot that operator.
Agreed, that does indeed seem like an odd choice, and one that only very minimally simplifies the the compiler: insert implied semicolon at newline if previous token expects a right-hand term, but not if the next token expects a left-hand term.
But then I've seen a lot of coding style guides for C++ etc. that advoc
Comment removed (Score:5, Insightful)
Re: (Score:2)
Says the guy who uses an american keyboard.
I guess a big deal of programmers, except for smalltalk, never really got what this semicolon nightmare is about. Hint: in most assemblers, the semicolon indicates the start of a comment. (Oh, and for non english/US keyboards the semicolon needs a shift/upercase key combo)
Re:Why I prefer go over python or java (Score:4, Insightful)
Semicolons are much better.
Ah the classic simple early-language trap (Score:5, Interesting)
This article shows real inexperience with the historic evolution of language. When it starts out every lagnuage is simple and there's a beautiful economomy that arrises from self consistency. When I switched to java it was in it's infancy. the books where all really thin. The foundational principles of java could be written down in about ten statements all of which were subtractive. That is the inspiration for java was in large part to look at all the problems C had and remove them. Like no pointers. No explicit memory management. runtime binding. compile once run everywhere. ... then to do that they removed things and unified many others to get a simple self consistent syntax.
Then they started adding libraries. Then standard libraries were deprecated and replaced. None of my AWT code would work right. and slowly libraries became new language features. ANd now it's a stinky teenager eating everything in your fridge.
it was so cute as a puppy.
I fell in love with python for the same reasons. there was only one idiom to do anything. Everyone could read everyone elses program. There was no longer a holy war over if a brlock brace goes on the end of the previous line or is indented on next line. I was momentatily taken aback by white space delimeters but two things really pesauded me;
1. the first was that I could easily follow and read other people's code. When was the last time you could say that about any language? Python really stood out for that, and it's a combination of the white space and the idiom simplicity. But now in python 3.0 the idiom simplicity is gone but the white space still helps a lot for readable code.
2. YAML. I always wretch when have to dig into XML. It's a dogs dinner of visually unreadable open and close tags. It can hide data in either the tag itself or between tags. So the tags themselves need their own manuals. Then you look at YAML, and there's nothing XML can do that YAML can't do, yet yaml is easy to real. Easy to emit. and there's no damn meta data overloading tags. I'm baffled why people even bother with XML when YAML is so superior. XML was the dachshund --great dane child of HTML. And it makes sense for HTML because the only thing you can put between the tags was text. So text was payload data and deserved a different class. Once you say text isnt' special then whats' the diffrence between tag data and between tag data? it's just unreadable.
If we want to judge a language by simplicity then the only useful measure is the thickness of the o-reily nutshell small books. By that criteria only two languages, excluding fortran, win: C and Perl. And of the three c, fortran and perl, the most sophisticated language is Perl. Food for thought.
When Go grows up, version 3.0 will be called Go-dawful.
Re: (Score:2)
Part of the appeal of Go is that its language designers do not lightly make the changes that you complain about. For example, about half of Go releases do not make any changes to the language specification, and almost half of the changes to the specification are to resolve ambiguities so that the written specification matches the implementation.
Go 1 was released in March 2012. Essentially every program written then will run the same today. (The exceptions are mostly ones that use libraries that have chan
Re: (Score:3)
Incompatible changes are bundled into editions, so you have to specifically opt in to 2018 edition in order to use those features in your code.
Re: (Score:2)
Swift 1 was released in September 2014. Almost no program written then will run the same today.
That's really annoying.
Re: (Score:3)
Swift 1 was released in September 2014. Almost no program written then will run the same today.
That's really annoying.
Yes, but keep in mind that, from what I understand, early Swift changed based on user feedback from real-world use. It was a good time to change the language, when it was still in its infancy and not that much legacy code was around. It was distinctly different than, say, breaking Python between 2 and 3, because it didn't cause a huge language schism.
I'm a huge proponent of backwards compatibility in many cases, particularly in well-established languages like C++, but dogged adherence to backwards compati
Re: (Score:2)
Re: (Score:2)
Far less confidence than C++ of course, but I think at this point I'd be willing to start a big project in Swift. Apple fully acknowledged that changes could occur early in the language development, so it's not like people were not aware of this. At this point, I'd imagine the language has mostly stabilized, and any incompatible changes to the language would be minor at worst.
Keep in mind that Apple has good reasons not to break their own language too badly at this point, as it would only undercut both th
Re: (Score:2)
1. the first was that I could easily follow and read other people's code. When was the last time you could say that about any language?
This is more about overall program organization than it is about particular lines of code. Unless you're reading C++.
Re: (Score:2)
Then you look at YAML, and there's nothing XML can do that YAML can't do, yet yaml is easy to real. Easy to emit. and there's no damn meta data overloading tags. I'm baffled why people even bother with XML when YAML is so superior.
The XML language allows for documents to self-describe what they contain by pointing to schemas. This means that schema-valid XML documents can be built programmatically and then serialized for transmission, or vice-versa to parse validated serialized documents into programmatic objects. This is especially useful when there's a need for transmitting sensitive material such as encrypted elements and digital signatures, for which there are approved specifications such as XML Encryption [wikipedia.org] and XML Signature [wikipedia.org], to a
Re: (Score:2)
Since you can encode _any_ xml document in yaml, you are making a distinction that does not exist.
Re: (Score:2)
I'm genuinely curious how you would go about doing that. Of course any XML can be encoded into YAML just by Base64-encoding it, but that's probably not what you meant. Take a simplified example such as <csig:SignMessage> from the XML schema EidCentralSigDssExt-1.1.xsd [swedenconnect.se]:
<csig:SignMessage xmlns:csig="http://id.elegnamnden.se/csig/1.1/dss-ext/ns">
..................xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
..<csig:EncryptedMessage>
....<xenc:EncryptedData>
......<xenc:Encr
Re: (Score:2)
It eas implied that you encode ALL in YAML. That includes attributes and namespace prefixes. What stops you from doing that?
The YAML example could be expanded to include bindings of the pseudo-namespaces to YAML schemas. The problem with this is that there's no official support for doing this in the language, so it would be up to each YAML implementation to invent their own syntax rules. There would be fragmentation and interoperability galore.
Oh, and thanks for giving me eye cancer with that XML example. It proved the unreadability argumenr quite nicely though.
Then I suspect you must be fuming at the guy below in the comment tree who suggested ASN.1 encoding.
Re: (Score:2)
This is what most of the YAML/JSON flavor-of-the-month crowd don't understand. The reason why XML is so much more useful is because of its supporting toolset (W3C XML Schema, RelaxNG, XPath, XSLT, namespaces, etc.) If you're just looking for a readable format for storing configuration variables or passing simple tokens on a socket connection, you're barking up the wrong tool tree with XML.
Re: (Score:2)
Pythons older than Java , Javascript, Ruby (barely, but it is slightly older), anda whole host of other languages. But it remains relatively simple in its syntax because guido van rossen has always resisted the impulse for major changes. v3 was the last major change to the language and introduction of that took a good decade , on purpose, and it *simplified* the language and took out a lot of accumulated cruft
Age does not make feature creep innevitable. Theres always a choice.
Re: (Score:2)
Quite frankly #1 above is the only reason I shy away from python. I like good clean code, but not at the expense of doing a quick copy/paste of an experiment without having to fix any fscking formatting just to get the damn thing to execute.
I suggest you either learn to configure your editor or move to a sane one if that does not do it.
Re: (Score:2)
I think the issue with python cut and paste is that when you cut and paste code from a website you never know what the indentation scheme is. And so you end up having to fix it. It's not the tab resolutions settings. It's the moving code that someone else wrote into your code where the indentation headaches happen.
That said, this only bites you the first few times, then you learn to watch for it and know how to quickly fix it if needed. So it's just a major problem only when you are new to the language.
Re: (Score:2)
I generally only spend a couple hours a week programming, sometimes less. It's not my primary job responsibility. But I'm at a loss to understand who this copy/paste issue affects.
Do you WANT your code to have some bizarre indent structure that doesn't match the logical structure? Does your editor lack the ability to select and move entire blocks in and out? Are you copying from websites that randomize whitespace?
I tend not to copy and paste a lot of code and generally think people who do are going to be lo
Re: (Score:2)
There are no advantages to "white space delimiters".
There are, however, serious problems. Lambdas in Python, for example, are broken because of the languages syntax rules.
Re: (Score:2)
Or, you could push one button and have all the code formatted automatically, in whatever style you'd like. We've had the ability to automatically "pretty print" for 40+ years.
Re: (Score:2)
Or, you could push one button and have all the code formatted automatically, in whatever style you'd like.
And how many buttons do you have to push to type all those curly braces and semicolons?
The information needs to be provided to the computer one way or another. Save here, lose out elsewhere.
I prefer many languages over Python or Java (Score:4, Insightful)
but I'm the only one to write anything in them, so it makes my target audience rather small. So, being pragmatic, I stick to lesser but more ubiquitous alternatives that pay my bills.
Now there's a good forumlated justification ... (Score:2)
... for using a PL. Go is on my list of things to dive into and this meta-article just moved it into the top 5 again. Interesting.
Isn't it nice when you get the sense that it's not just a cargo cult but someone actually knows what he is talking about?
Re: (Score:2)
Don't forget to learn about Rust and Containers. Then you can learn their replacements in about 1 to 2 years.
Re: (Score:2)
... for using a PL. Go is on my list of things to dive into and this meta-article just moved it into the top 5 again. Interesting. Isn't it nice when you get the sense that it's not just a cargo cult but someone actually knows what he is talking about?
That was a good justification. I hate it when a language proponent uses high complexity and perl-like syntax to justify why it is better (Rust, anyone?) - I want something simple like Lisp or C where I can basically keep the entire language spec in my head while programming, not something like C++ or Java where there's a whole bunch of interactions between different language features that change each other's behaviours in surprising ways.
Too little specification also makes things hard - Python maintenance,
Re: (Score:3)
Re: (Score:2)
I want something simple like Lisp or C where I can basically keep the entire language spec in my head while programming
This is hugely underrated in language design. You're not going to like typescript, though.
Re: (Score:3)
C where I can basically keep the entire language spec in my head while programming, not something like C++ or Java where there's a whole bunch of interactions between different language features that change each other's behaviours in surprising ways.
I can't speak for Java, but I think many C++ programmers work around this issue by picking a subset of the language they're comfortable with, establishing practical patterns that work for them, and then using those patterns within that language subset. This is essentially what "modern C++" is, to some degree, although many programmers use even a more narrow subset.
It's certainly not ideal, but it works reasonably well, given enough language training and experience. The big problem, of course, comes when s
Re: (Score:2)
the only way to know if you're passing the correct type or using a return value as the correct type is to read the sources of whatever you're interacting with.
Type annotations [python.org] have been added to Python, so that problem will go away in the future, assuming you have good coding practices.
Interesting point... (Score:3)
Re: (Score:2)
Why I prefer wrenches to screwdrivers. (Score:5, Insightful)
Re: (Score:3)
Re: (Score:3)
There's an emacs command that handles all of these cases.
They call it "slashvertisement"... (Score:2)
Counting pages (Score:3)
The first edition of the Java Language Specification [oracle.com], before "feature creep", was 852 pages long. Maybe making these kinds of comparisons is a bit unscientific?
Re: Counting pages (Score:2)
Maybe they used a bigger font?
Re: (Score:3)
Although constantly adding shit like generics and decorators did turn the language from simple, powerful and maintainable to complex, powerful and fucking impossible to maintain.
Letting people enthused by language cleverness take control from the engineers fucked it forever. If I wanted a complex interesting challenging language I'd use Ruby, not break the only language I can trust average programmers not to fuck up too badly.
Re: Counting pages (Score:2)
Re: (Score:2)
The first Java Language Specification included 300+ pages of specification for standard packages. The two specifications that Nilsson compared didn't. He compared apples to apples.
Re: (Score:2)
What sold me (Score:2, Interesting)
The dnscrypt-proxy v1.x was old, buggy, unmaintainable, and written in C.
Some new guy came along, rewrote dnscrypt-proxy from scratch in go. And now dnscrypt-proxy 2.x is sweet, sweet, sweet. Building it from go source is is even easier than using some distribution's package manager. And most distribution dnscrypt-proxy packages are woefully out of date anyway. This is a great real world case study of go vs C..
See dnscrypt-proxy 2 - A flexible DNS proxy, with support for encrypted DNS protocols. [github.com]
Re: (Score:2)
It is not. It is a case study of old guy vs. new guy. Extremely obviously so.
No power steering but a good car considering price (Score:5, Insightful)
Be mindful how Golang proponents hardly ever say that Go is a good language.
It is always good only relative to its simplicity. Think of:
This Tata car may not have power steering or air condition, but it is a lot of a car for the money.
Similarly:
This Go language does not have generics, error handling, union types, pattern matching, but you can get a lot of work done considering how simple the language is.
Now: would you prefer to drive Tata or Mercedes?
Re: (Score:2)
Re: (Score:2)
Interfaces are your union types in languages like Go or Oberon
// assuming long has 8 bytes
... they overlap. Two different names and types for the same address space, hence you easily can write code that access the individual bytes of the integer.
No they are not. You don't know what a union type is:
union Tricky {
long num;
char bytes[8];
} myVariable;
"num" and "bytes" start at the same address
How exactly do you want to do that with an "interface"??? Or do you want to tells us an interface in Go is a wierd th
Re: (Score:2)
Why should pattern matching be embedded within the language itself? I call that bloat and feature creep. By "error handling" you must specifically mean exception throwing and catching, as I'm sure it is trivial to write code that passes errors via function return codes like in the days of yore.
Re: No power steering but a good car considering p (Score:3)
I think you might be confused about what the GP means by pattern matching. This is not regular expressions: those are fine as libraries. There is another form of pattern matching, which is over parameters, including their values and types. An early example can be found inErlang, and another (quite different as it has a very different type system) in Scala.
This kind of pattern matching is something you either have to add to a language directly, or support macros powerful enough you are in Common Lisp territo
Re: (Score:2)
Hey! I had meant to ask you about your thoughts on Go. After being immersed in Scala for so long, how do you think I'd like it?
Re:No power steering but a good car considering pr (Score:4, Insightful)
Now: would you prefer to drive Tata or Mercedes?
That depends. What kind of Mercedes? If it's a W123 or W126, I'll take the Mercedes. After that, Mercedes stopped overbuilding cars, and about the same time, Bosch QA and design began to slip badly. They had problems with basic things like bonding wires to connectors inside of modules. All German cars are made out of Bosch electronics. And frankly, I totally want a Tata Nano if they power them with the MDI air engine. That would be a great RV toad. I bet you could configure it to "charge" while being towed, just by leaving it "on" and in high gear.
The small, cheap car is a delight all its own. Flogging such a beast and just barely keeping up with a lesser driver in a greater car is a positively palpable joy, in spite of the fact that you're not beating anyone. That's why even people with money love hot hatches. Why wouldn't a small, light language be similar, so long as it has all the necessary functions? Especially if you don't have a bunch of cruft to get in your way.
Re: (Score:2)
Be mindful of how this guy never claims his argument is good.
Re: (Score:3)
In certain situations I'm a fan of unions wrapped within a type-safe object that only allows you to access them as the proper type.
Typically the situation involves storing a variety of different kinds of data in a dense array, so that you gain the often-substantial performance benefits of traversing memory in a linear fashion, rather than jumping around randomly, which can deliver an order of magnitude or more performance improvement.
Package management is *not* a feature (Score:2)
Please, let the distro handle packages. That PM crutch may be practical for coders, but when it comes to long-term maintenance, every snowflake PM becomes another point of failure.
Re: (Score:3)
And because the Go package manager (like most language specific package managers) is developer-centric, you have to rely on the developer to keep an eye out for CVE announcements for all the libraries they use. The number of developers that actually do this consistently is very small.
Re: (Score:2)
The term "package" has many different meanings in computer science ... you picked the wrong one.
I have found Go to be very difficult to read (Score:5, Interesting)
He wrote, "Your project is doomed if you can't read and understand your code."
Hmmm. I have found Go code to be among the most difficult to read. Some of the reasons are, (1) the duck typing: try figuring out what type something is - you have to search and search to see which methods it implements; (2) the Go communities culture of short variable names (try searching for all occurrences of "con" in a project"); (3) the fact that something that is null might not be null once you do a type assertion on it; (4) the fact that method call targets get bound differently than method parameters; (5) the broken import system, which almost mandates that you use a certain file structure in your project; and (6) many other weird and unexpected things that will trip up someone new to Go.
Is this really a fair comparison? (Score:2)
The formal Go language specification is only 50 pages, has plenty of examples, and is fairly easy to read. A skilled programmer could probably learn Go from the specification alone.
The professor points out that the Java® Language Specification is 750 pages, and blames much of its complexity on feature creep (for example, inner classes, generics, and enum).
Go is not even 10 years old yet. Java on the other hand will be 23 years old in a few weeks.
Java is one of the most widely-used programming languages, both presently and historically...it is up there with the likes of C and C++. Go on the other hand has been deployed in a much, much more limited way thus far.
Java has been used for a wide variety of applications, and people keep finding new ones...I'm not a fan of its feature creep (e.g. lambda expressions being my current pet-peeve) but isn't that kind of i
Re: (Score:2)
Yes, it is a fair comparison. Java was eight years old when Java 5 was released, which introduced generics, annotations, automatic type boxing and unboxing, and a lot more. Java and Go have both had six-month release cycles for their last four significant (non-bug-fix) releases, and Go has changed fewer parts of the language over that time.
The first version of the Java language specification was 852 pages long, although that includes specifications for the java.lang, java.util and java.io packages (which
If only everyone just stuck with Perl (Score:2)
We wouldn't have to learn 10 languages to get anything done. Learning one duct tape language to do it all is better than learning 10 new languages.
Re: (Score:2)
Scala with GraalVM over Go (Score:2)
Personally, I don't see a lot of value in Go.
For me, it looked like Google created Go and Dart to reduce their dependency on Java and the law suits.
The initial draw was about fast compilation and the language was kept simple.
I don't care for Go's minimalism, it is a bit too spartan for my tastes. Scala type system is admittedly complex. I have never abused it, but I can see how things can get out of hand in a team. There is certainly Scala code that I am not eager to unpack.
Go creates self-contained binarie
Re: (Score:2)
That said, Go does have the best high-level library repo for a native compiled language - easy as a scripting language.
D, Rust and Scala communities can learn from it.
Re: (Score:2)
Go does have the best high-level library repo for a native compiled language - easy as a scripting language
A statement like that is substance less. Unless you give examples of "good examples" in Golang point out the equivalent bad examples in D/Rust/Scala.
Re: (Score:2)
Let's stick with substance less opinion.
I feel too lazy to make this a rigorous position.
Re: (Score:2)
For me, it looked like Google created Go and Dart to reduce their dependency on Java and the law suits.
Nah, it was Rob Pike and Ken Thompson deciding there was no good language for server programming, and C++ sucks, so they decided to make their own.
Not coincidentally, Golang use seems to be most popular in devops, because it's really good for server programming.
Re: (Score:2)
No, I would like to write code in a native high-level language that has both OOP and functional features, a solid type system, a polyglot ecosystem and great IDE support - none of which are Go's strong suites.
GraalVM runs on SubstrateVM, not JVM. It is just compatible with the JVM.
No, I don't much care for the Java API either, but being able to hook into some already mature ecosystem, when your language may not have everything covered does help.
I like Go's libraries, just not the language. If someone create
Go is simple NOW (Score:2)
Sure, Go, being a relative new language is simple now, with just 50 pages of docs to get going.
You know Python 1.x releases, they were very simple as well, even more so than today.
My first O'Reilly book about python was very small, the same book now, with many revisions to version 3.x is at least 3 times as big.
Give Go some time, it won't be 50 pages of spec any longer.
Re: (Score:2)
My Go annoyances (so far) (Score:2)
When assigning a pointer changes your type [dev.to]
monastic selection bias (Score:2)
When you pick a standard format, you'll always attract those who would have employed that format in the first place, and you'll always repel those who would not employed that format in the first place. Some monasteries encourage vigorous discussion, other monasteries discourage much use of speech at all. Some private schools demand an abso
My favorite toy language (Score:2)
I just stopped by to see the "favorite toy language" jokes. Slashdot, you've disappointed me again.
https://books.google.co.jp/boo... [google.co.jp]
Re: (Score:3)
Yes, THE Stefan Nilsson. Easy, guys, he puts his pants on just like the rest of you -- one leg at a time. Except, once his pants are on, he makes level- and path-compressed tree data structures.
Re: (Score:2)
And that is the main problem. Google massively sucks at continuity. Without that, a language is worthless, no matter how well designed.
Re: (Score:2)
I've always believed C++ was the "latest and greatest" C, developed primarily to make sure compiler and library nerds kept their twitchy fingers away from C itself. Hence, why C is still comprehensible decades later.
Your other point, though, is exactly why I shy away from Go. Other than the Google search bar itself, is there anything Google has created that it hasn't eventually dumped like last week's lover once the thrill is gone? When Google stops supporting Go, is there any real chance it will have enoug
Re: Full circle (Score:2)
Yeah, my first thought was, "Those who can, do. Those who can't, teach."
If I want recommendations, I will be asking the people in the trenches, not the people in the classroom.
Re: (Score:2)
I'm reminded of a time someone I know was taking a course in Computer Science in university. It wasn't their major, but they learned enough to be vaguely able to understand the technology I was working with and what I was building.
They asked their teacher when they would be learning about what I was doing, and the teacher told them that what I was working with was on the cutting edge of technology, and that perhaps in three or four years time they might have a course about it, but that it was too new.
But f
Re: (Score:2)
The point is not to get the most up-to-date information. That's constantly changing anyways and you're better off learning it on the job.
Instead, you get a very comprehensive set that's new enough to be useful. Nobody in the industry is going to be working on the bleeding edge of computer security, machine learning and quantum computing all at the same time. But you can get 3-4 years old knowledge from all of those fields from a university.
And then there's areas where the university is ahead of the industry
Re:No Generics? No, thanks! (Score:5, Interesting)
Generics are not absolutely vital for creating abstractions in a statically typed language.
Generics may be vital for creating abstractions with almost zero runtime overhead, but they have very real costs in complexity of source code, and they have definite costs in binary size that may impact execution time.
Go compromises by using interface types -- including "interface {}", which can hold any type -- with additional execution time cost, but much less complexity in the source code and smaller binaries. Using interfaces is simplified because they have compile-time duck typing: type X does not have to declare that it implements interface Y, it just has to implement the methods defined by interface Y, and the compiler generates the glue when it is necessary.
Go's inner circle do want to add generics to the language, but they are still debating over the best way to fit it into the rest of the language and meet Go's other objectives about how programs should behave.
Re: (Score:2)
Interfaces and generics have nothing to do with each other.
Generics as a late hack add on to Java are poor man's pseudo-equivalent to C++'s templates.
and they have definite costs in binary size that may impact execution time.
No they have not, neither in Java nor in C++, depending how you roll them out in C++.
Bottom line you can only use less space and write more obscure, less maintainable code by eiher using "objects" in Java or "void *" in C++ ... If you would write maintainable code, you either write by h
Re: (Score:2)
Generics are absolutely vital for creating abstractions in a statically typed language.
I know, right? We didn't have abstractions in any of the statically typed languages until metprogramming became a thing.
Absolutely no software of any complexity and levels of abstraction was produced before the world got generics, because there is simply no way to do abstraction unless you use generics!!!
/s
Idiot.
Re: (Score:2)
We didn't have abstractions in any of the statically typed languages until metprogramming became a thing.
Metaprogramming became a thing in LISP (if not earlier?) and C has generics in the pre-processor.
Re: (Score:3)
I agree.
If length of specification were important, we'd all be using brainfuck.
Re: (Score:2)
Generics are absolutely vital for creating abstractions in a statically typed language.
Nah. You're just pointing out your own hole in your knowledge about programming. If you figure out how to do it without generics, your code will be a lot cleaner, even when you do use languages with generics (because it is 99% certain you are using generics in many places where they are not appropriate).
If the only tool you have is a hammer, then everything looks like a nail.
Re: (Score:2)
I use Python. There was a knock on my door the other day.
When I looked outside, the sidewalk was empty.
Re: (Score:2)
He's comparing it to languages that were designed in the late 1980s (Python) and early 1990s (Java). Compare it instead to well designed modern languages like Rust, Kotlin, and Swift. I can't imagine any project for which I'd choose Go instead of one of them.
Given that practically nobody currently uses Rust, Kotlin and Swift for web development, perhaps that would be a reason? They are all interesting languages, but the overlap between their use is limited. Rust may have some overlap with Go in command line utilities and systems programming, but even there they both have pretty clear advantages and disadvantages - if you see no advantages for Go you may simply lack some knowledge there.
Re: (Score:2)
Who said anything about web development? The article is from a computer science professor talking about intrinsic features and specifications of the languages. He isn't limiting it to any one type of application. None of the features he touts are specific to web development. And are you suggesting Go is solely for web development? It's not. It's supposed to be a general purpose language, just like all of them.
Re: (Score:2)
You say you don't see any project to use go, I mention two areas where Go is strong, then you say you didn't mention one of those areas. If you disagree, it would be more interesting to say which of those languages you'd pick for web over Go and why. You can pretend all languages should be strong in all areas, but that's no quite the reality. Either way, Go is effectively a 70s or 80s language. For computer science academics, they use a lot of Java and python so it makes sense to compare with those.